)]}'
{
  "log": [
    {
      "commit": "e028398da7615dd3a795505ddf7942506bbb49bd",
      "tree": "fde1547e7113147ff7594e9c15ff71473af63201",
      "parents": [
        "6bd8fedaa16da1e24f38712ee759950d8c5f4f09"
      ],
      "author": {
        "name": "Adrian Bunk",
        "email": "bunk@kernel.org",
        "time": "Sat Nov 03 01:04:30 2007 +0100"
      },
      "committer": {
        "name": "David Teigland",
        "email": "teigland@redhat.com",
        "time": "Tue Jan 29 17:16:52 2008 -0600"
      },
      "message": "dlm: proper prototypes\n\nThis patch adds a proper prototype for some functions in\nfs/dlm/dlm_internal.h\n\nSigned-off-by: Adrian Bunk \u003cbunk@kernel.org\u003e\nSigned-off-by: David Teigland \u003cteigland@redhat.com\u003e\n"
    },
    {
      "commit": "3ae1acf93a21512512f8a78430fcde5992dd208e",
      "tree": "878ed3c619530c6acf862ecf663063f66fc47a06",
      "parents": [
        "85e86edf951a8a39954c0ba1edbe4a58827dcd5c"
      ],
      "author": {
        "name": "David Teigland",
        "email": "teigland@redhat.com",
        "time": "Fri May 18 08:59:31 2007 -0500"
      },
      "committer": {
        "name": "Steven Whitehouse",
        "email": "swhiteho@redhat.com",
        "time": "Mon Jul 09 08:22:33 2007 +0100"
      },
      "message": "[DLM] add lock timeouts and warnings [2/6]\n\nNew features: lock timeouts and time warnings.  If the DLM_LKF_TIMEOUT\nflag is set, then the request/conversion will be canceled after waiting\nthe specified number of centiseconds (specified per lock).  This feature\nis only available for locks requested through libdlm (can be enabled for\nkernel dlm users if there\u0027s a use for it.)\n\nIf the new DLM_LSFL_TIMEWARN flag is set when creating the lockspace, then\na warning message will be sent to userspace (using genetlink) after a\nrequest/conversion has been waiting for a given number of centiseconds\n(configurable per node).  The time warnings will be used in the future\nto do deadlock detection in userspace.\n\nSigned-off-by: David Teigland \u003cteigland@redhat.com\u003e\nSigned-off-by: Steven Whitehouse \u003cswhiteho@redhat.com\u003e\n"
    },
    {
      "commit": "ac33d0710595579e3cfca42dde2257eb0b123f6d",
      "tree": "ebb3050be68aa49666ee03f51ffe2667f5b18c74",
      "parents": [
        "34126f9f41901ca9d7d0031c2b11fc0d6c07b72d"
      ],
      "author": {
        "name": "Patrick Caulfield",
        "email": "pcaulfie@redhat.com",
        "time": "Wed Dec 06 15:10:37 2006 +0000"
      },
      "committer": {
        "name": "Steven Whitehouse",
        "email": "swhiteho@redhat.com",
        "time": "Thu Dec 07 09:25:13 2006 -0500"
      },
      "message": "[DLM] Clean up lowcomms\n\nThis fixes up most of the things pointed out by akpm and Pavel Machek\nwith comments below indicating why some things have been left:\n\nAndrew Morton wrote:\n\u003e\n\u003e\u003e +static struct nodeinfo *nodeid2nodeinfo(int nodeid, gfp_t alloc)\n\u003e\u003e +{\n\u003e\u003e +\tstruct nodeinfo *ni;\n\u003e\u003e +\tint r;\n\u003e\u003e +\tint n;\n\u003e\u003e +\n\u003e\u003e +\tdown_read(\u0026nodeinfo_lock);\n\u003e\n\u003e Given that this function can sleep, I wonder if `alloc\u0027 is useful.\n\u003e\n\u003e I see lots of callers passing in a literal \"0\" for `alloc\u0027.  That\u0027s in fact\n\u003e a secret (GFP_ATOMIC \u0026 ~__GFP_HIGH).  I doubt if that\u0027s what you really\n\u003e meant.  Particularly as the code could at least have used __GFP_WAIT (aka\n\u003e GFP_NOIO) which is much, much more reliable than \"0\".  In fact \"0\" is the\n\u003e least reliable mode possible.\n\u003e\n\u003e IOW, this is all bollixed up.\n\nWhen 0 is passed into nodeid2nodeinfo the function does not try to allocate a\nnew structure at all. it\u0027s an indication that the caller only wants the nodeinfo\nstruct for that nodeid if there actually is one in existance.\nI\u0027ve tidied the function itself so it\u0027s more obvious, (and tidier!)\n\n\u003e\u003e +/* Data received from remote end */\n\u003e\u003e +static int receive_from_sock(void)\n\u003e\u003e +{\n\u003e\u003e +\tint ret \u003d 0;\n\u003e\u003e +\tstruct msghdr msg;\n\u003e\u003e +\tstruct kvec iov[2];\n\u003e\u003e +\tunsigned len;\n\u003e\u003e +\tint r;\n\u003e\u003e +\tstruct sctp_sndrcvinfo *sinfo;\n\u003e\u003e +\tstruct cmsghdr *cmsg;\n\u003e\u003e +\tstruct nodeinfo *ni;\n\u003e\u003e +\n\u003e\u003e +\t/* These two are marginally too big for stack allocation, but this\n\u003e\u003e +\t * function is (currently) only called by dlm_recvd so static should be\n\u003e\u003e +\t * OK.\n\u003e\u003e +\t */\n\u003e\u003e +\tstatic struct sockaddr_storage msgname;\n\u003e\u003e +\tstatic char incmsg[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];\n\u003e\n\u003e whoa.  This is globally singly-threaded code??\n\nYes. it is only ever run in the context of dlm_recvd.\n\u003e\u003e\n\u003e\u003e +static void initiate_association(int nodeid)\n\u003e\u003e +{\n\u003e\u003e +\tstruct sockaddr_storage rem_addr;\n\u003e\u003e +\tstatic char outcmsg[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];\n\u003e\n\u003e Another static buffer to worry about.  Globally singly-threaded code?\n\nYes. Only ever called by dlm_sendd.\n\n\u003e\u003e +\n\u003e\u003e +/* Send a message */\n\u003e\u003e +static int send_to_sock(struct nodeinfo *ni)\n\u003e\u003e +{\n\u003e\u003e +\tint ret \u003d 0;\n\u003e\u003e +\tstruct writequeue_entry *e;\n\u003e\u003e +\tint len, offset;\n\u003e\u003e +\tstruct msghdr outmsg;\n\u003e\u003e +\tstatic char outcmsg[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];\n\u003e\n\u003e Singly-threaded?\n\nYep.\n\n\u003e\u003e\n\u003e\u003e +static void dealloc_nodeinfo(void)\n\u003e\u003e +{\n\u003e\u003e +\tint i;\n\u003e\u003e +\n\u003e\u003e +\tfor (i\u003d1; i\u003c\u003dmax_nodeid; i++) {\n\u003e\u003e +\t\tstruct nodeinfo *ni \u003d nodeid2nodeinfo(i, 0);\n\u003e\u003e +\t\tif (ni) {\n\u003e\u003e +\t\t\tidr_remove(\u0026nodeinfo_idr, i);\n\u003e\n\u003e Didn\u0027t that need locking?\n\nNot. it\u0027s only ever called at DLM shutdown after all the other threads\nhave been stopped.\n\n\u003e\u003e\n\u003e\u003e +static int write_list_empty(void)\n\u003e\u003e +{\n\u003e\u003e +\tint status;\n\u003e\u003e +\n\u003e\u003e +\tspin_lock_bh(\u0026write_nodes_lock);\n\u003e\u003e +\tstatus \u003d list_empty(\u0026write_nodes);\n\u003e\u003e +\tspin_unlock_bh(\u0026write_nodes_lock);\n\u003e\u003e +\n\u003e\u003e +\treturn status;\n\u003e\u003e +}\n\u003e\n\u003e This function\u0027s return value is meaningless.  As soon as the lock gets\n\u003e dropped, the return value can get out of sync with reality.\n\u003e\n\u003e Looking at the caller, this _might_ happen to be OK, but it\u0027s a nasty and\n\u003e dangerous thing.  Really the locking should be moved into the caller.\n\nIt\u0027s just an optimisation to allow the caller to schedule if there is no work\nto do. if something arrives immediately afterwards then it will get picked up\nwhen the process re-awakes (and it will be woken by that arrival).\n\nThe \u0027accepting\u0027 atomic has gone completely. as Andrew pointed out it didn\u0027t\nreally achieve much anyway. I suspect it was a plaster over some other\nstartup or shutdown bug to be honest.\n\n\nSigned-off-by: Patrick Caulfield \u003cpcaulfie@redhat.com\u003e\nSigned-off-by: Steven Whitehouse \u003cswhiteho@redhat.com\u003e\nCc: Andrew Morton \u003cakpm@osdl.org\u003e\nCc: Pavel Machek \u003cpavel@ucw.cz\u003e\n\n"
    },
    {
      "commit": "597d0cae0f99f62501e229bed50e8149604015bb",
      "tree": "b6cab09ff6fe2246740848164c0a52d5c03136a0",
      "parents": [
        "2eb168ca94aba3bcae350ad9b31870955174a218"
      ],
      "author": {
        "name": "David Teigland",
        "email": "teigland@redhat.com",
        "time": "Wed Jul 12 16:44:04 2006 -0500"
      },
      "committer": {
        "name": "Steven Whitehouse",
        "email": "swhiteho@redhat.com",
        "time": "Thu Jul 13 09:25:34 2006 -0400"
      },
      "message": "[DLM] dlm: user locks\n\nThis changes the way the dlm handles user locks.  The core dlm is now\naware of user locks so they can be dealt with more efficiently.  There is\nno more dlm_device module which previously managed its own duplicate copy\nof every user lock.\n\nSigned-off-by: Patrick Caulfield \u003cpcaulfie@redhat.com\u003e\nSigned-off-by: David Teigland \u003cteigland@redhat.com\u003e\nSigned-off-by: Steven Whitehouse \u003cswhiteho@redhat.com\u003e\n\n"
    },
    {
      "commit": "e7fd41792fc0ee52a05fcaac87511f118328d147",
      "tree": "eee5227088ba97daef795e385b7548d2a1cc4cb6",
      "parents": [
        "e47314207032cfd1157b8c377df162839b32ea6f"
      ],
      "author": {
        "name": "David Teigland",
        "email": "teigland@redhat.com",
        "time": "Wed Jan 18 09:30:29 2006 +0000"
      },
      "committer": {
        "name": "Steven Whitehouse",
        "email": "swhiteho@redhat.com",
        "time": "Wed Jan 18 09:30:29 2006 +0000"
      },
      "message": "[DLM] The core of the DLM for GFS2/CLVM\n\nThis is the core of the distributed lock manager which is required\nto use GFS2 as a cluster filesystem. It is also used by CLVM and\ncan be used as a standalone lock manager independantly of either\nof these two projects.\n\nIt implements VAX-style locking modes.\n\nSigned-off-by: David Teigland \u003cteigland@redhat.com\u003e\nSigned-off-by: Steve Whitehouse \u003cswhiteho@redhat.com\u003e\n"
    }
  ]
}