)]}'
{
  "log": [
    {
      "commit": "6e5882cfa24e1456702e463f6920fc0ca3c3d2b8",
      "tree": "636800c0619ec3551f9a8a7da707d913937cf43d",
      "parents": [
        "2be4d50295e2b6f62c07b614e1b103e280dddb84"
      ],
      "author": {
        "name": "Zachary Amsden",
        "email": "zach@vmware.com",
        "time": "Thu Apr 27 11:32:29 2006 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Thu Apr 27 12:00:59 2006 -0700"
      },
      "message": "[PATCH] x86/PAE: Fix pte_clear for the \u003e4GB RAM case\n\nProposed fix for ptep_get_and_clear_full PAE bug.  Pte_clear had the same bug,\nso use the same fix for both.  Turns out pmd_clear had it as well, but pgds\nare not affected.\n\nThe problem is rather intricate.  Page table entries in PAE mode are 64-bits\nwide, but the only atomic 8-byte write operation available in 32-bit mode is\ncmpxchg8b, which is expensive (at least on P4), and thus avoided.  But it can\nhappen that the processor may prefetch entries into the TLB in the middle of an\noperation which clears a page table entry.  So one must always clear the P-bit\nin the low word of the page table entry first when clearing it.\n\nSince the sequence *ptep \u003d __pte(0) leaves the order of the write dependent on\nthe compiler, it must be coded explicitly as a clear of the low word followed\nby a clear of the high word.  Further, there must be a write memory barrier\nhere to enforce proper ordering by the compiler (and, in the future, by the\nprocessor as well).\n\nOn \u003e 4GB memory machines, the implementation of pte_clear for PAE was clearly\ndeficient, as it could leave virtual mappings of physical memory above 4GB\naliased to memory below 4GB in the TLB.  The implementation of\nptep_get_and_clear_full has a similar bug, although not nearly as likely to\noccur, since the mappings being cleared are in the process of being destroyed,\nand should never be dereferenced again.\n\nBut, as luck would have it, it is possible to trigger bugs even without ever\ndereferencing these bogus TLB mappings, even if the clear is followed fairly\nsoon after with a TLB flush or invalidation.  The problem is that memory above\n4GB may now be aliased into the first 4GB of memory, and in fact, may hit a\nregion of memory with non-memory semantics.  These regions include AGP and PCI\nspace.  As such, these memory regions are not cached by the processor.  This\nintroduces the bug.\n\nThe processor can speculate memory operations, including memory writes, as long\nas they are committed with the proper ordering.  Speculating a memory write to\na linear address that has a bogus TLB mapping is possible.  Normally, the\nspeculation is harmless.  But for cached memory, it does leave the falsely\nspeculated cacheline unmodified, but in a dirty state.  This cache line will be\neventually written back.  If this cacheline happens to intersect a region of\nmemory that is not protected by the cache coherency protocol, it can corrupt\ndata in I/O memory, which is generally a very bad thing to do, and can cause\ntotal system failure or just plain undefined behavior.\n\nThese bugs are extremely unlikely, but the severity is of such magnitude, and\nthe fix so simple that I think fixing them immediately is justified.  Also,\nthey are nearly impossible to debug.\n\nSigned-off-by: Zachary Amsden \u003czach@vmware.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "101f12af16fb12f8da8100899a13ee1b1b576a0a",
      "tree": "0bea73d2702ba438e8e82bc8000b498aa50aee6e",
      "parents": [
        "44fd22992cb76dc51c52cf4b8aff1bc7899bb23c"
      ],
      "author": {
        "name": "Jan Beulich",
        "email": "jbeulich@novell.com",
        "time": "Thu Mar 23 02:59:45 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Thu Mar 23 07:38:05 2006 -0800"
      },
      "message": "[PATCH] i386: actively synchronize vmalloc area when registering certain callbacks\n\nRegistering a callback handler through register_die_notifier() is obviously\nprimarily intended for use by modules.  However, the way these currently\nget called it is basically impossible for them to actually be used by\nmodules, as there is, on non-PAE configurationes, a good chance (the larger\nthe module, the better) for the system to crash as a result.\n\nThis is because the callback gets invoked\n\n(a) in the page fault path before the top level page table propagation\n    gets carried out (hence a fault to propagate the top level page table\n    entry/entries mapping to module\u0027s code/data would nest infinitly) and\n\n(b) in the NMI path, where nested faults must absolutely not happen,\n    since otherwise the IRET from the nested fault re-enables NMIs,\n    potentially resulting in nested NMI occurences.\n\nBesides the modular aspect, similar problems would even arise for in-\nkernel consumers of the API if they touched ioremap()ed or vmalloc()ed\nmemory inside their handlers.\n\nSigned-off-by: Jan Beulich \u003cjbeulich@novell.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "ca140fdadbe4c031a20a970f46163908d09a116b",
      "tree": "5dff340fd0bb88751604d7d7ffdcb0fe55144005",
      "parents": [
        "d16aafff2570abb557a5cb18c98027aabd602e22"
      ],
      "author": {
        "name": "Paolo \u0027Blaisorblade\u0027 Giarrusso",
        "email": "blaisorblade@yahoo.it",
        "time": "Sun Oct 30 14:59:31 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Oct 30 17:37:12 2005 -0800"
      },
      "message": "[PATCH] i386: little pgtable.h consolidation vs 2/3level\n\nJoin together some common functions (pmd_page{,_kernel}) over 2level and\n3level pages.\n\nSigned-off-by: Paolo \u0027Blaisorblade\u0027 Giarrusso \u003cblaisorblade@yahoo.it\u003e\nAcked-by: Hugh Dickins \u003chugh@veritas.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}