)]}'
{
  "log": [
    {
      "commit": "ff55fe2075e3901db4dbdc00e0b44a71bef97afd",
      "tree": "c6dfc8ba5d04fda4c5cb15cdebd5425ab674f8df",
      "parents": [
        "69ac59647e66c1b53fb98fe8b6d0f2099cffad60"
      ],
      "author": {
        "name": "Jason Baron",
        "email": "jbaron@redhat.com",
        "time": "Fri Sep 09 13:01:57 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Fri Sep 09 13:57:31 2005 -0700"
      },
      "message": "[PATCH] pty_chars_in_buffer oops fix\n\nThe idea of this patch is to lock both sides of a ptmx/pty pair during line\ndiscipline changing.  This is needed to ensure that say a poll on one side of\nthe pty doesn\u0027t occur while the line discipline is actively being changed.\nThis resulted in an oops reported on lkml, see:\n\n\thttp://marc.theaimsgroup.com/?l\u003dlinux-kernel\u0026m\u003d111342171410005\u0026w\u003d2\n\nA \u0027hacky\u0027 approach was previously implmemented which served to eliminate the\npoll vs.  line discipline changing race.  However, this patch takes a more\ngeneral approach to the issue.  The patch only adds locking on a less often\nused path, the line-discipline changing path, as opposed to locking the\nptmx/pty pair on read/write/poll paths.\n\nThe patch below, takes both ldisc locks in either order b/c the locks are both\ntaken under the same spinlock().  I thought about locking the ptmx/pty\nseparately, such as master always first but that introduces a 3 way deadlock.\nFor example, process 1 does a blocking read on the slave side.  Then, process\n2 does an ldisc change on the slave side, which acquires the master ldisc lock\nbut not the slave\u0027s.  Finally, process 3 does a write which blocks on the\nprocess 2\u0027s ldisc reference.\n\nThis patch does introduce some changes in semantics.  For example, a line\ndiscipline change on side \u0027a\u0027 of a ptmx/pty pair, will now wait for a\nread/write to complete on the other side, or side \u0027b\u0027.  The current behavior\nis to simply wait for any read/writes on only side \u0027a\u0027, not both sides \u0027a\u0027 and\n\u0027b\u0027.  I think this behavior makes sense, but I wanted to point it out.\n\nI\u0027ve tested the patch with a bunch of read/write/poll while changing the line\ndiscipline out from underneath.\n\nThis patch obviates the need for the above \"hide the problem\" patch.\n\nSigned-off-by: Jason Baron \u003cjbaron@redhat.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"
    }
  ]
}