)]}'
{
  "log": [
    {
      "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": "38d6fd26ea7f291141039fe340a581dc6f770fc0",
      "tree": "3e8ef8ea8e72fab24c140be53b18c98f2cb6cc95",
      "parents": [
        "5c09d96b34ac9b95ab4606e51ddb34ed0f19faf1"
      ],
      "author": {
        "name": "Al Viro",
        "email": "viro@ftp.linux.org.uk",
        "time": "Mon Oct 09 20:27:30 2006 +0100"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Mon Oct 09 14:19:08 2006 -0700"
      },
      "message": "[PATCH] dlm gfp_t annotations\n\nSigned-off-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1c032c03117c014512195f2e33c3af999f132146",
      "tree": "2032d1965331fb1882fdb306c678cf4497b35c10",
      "parents": [
        "ae118962b9f8572b5ff00e85c053dbeede2314db"
      ],
      "author": {
        "name": "David Teigland",
        "email": "teigland@redhat.com",
        "time": "Fri Apr 28 10:50:41 2006 -0400"
      },
      "committer": {
        "name": "Steven Whitehouse",
        "email": "swhiteho@redhat.com",
        "time": "Fri Apr 28 10:50:41 2006 -0400"
      },
      "message": "[DLM] PATCH 2/3 dlm: lowcomms close\n\nWhen a node is removed from a lockspace configuration, close our\nconnection to it, clearing any remaining messages for it.\n\nSigned-off-by: David Teigland \u003cteigland@redhat.com\u003e\nSigned-off-by: Patrick Caulfield \u003cpcaulfie@redhat.com\u003e\nSigned-off-by: Steven Whitehouse \u003cswhiteho@redhat.com\u003e\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"
    }
  ]
}