)]}' { "log": [ { "commit": "528da3e9e237059a84a2625e942811cf824a6efd", "tree": "7d3de6d5468d6835a4d81bfa1e717100dc7b71bf", "parents": [ "0732f87761dbe417cb6e084b712d07e879e876ef" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Fri Jun 12 16:04:26 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Fri Jun 19 12:42:48 2009 -0400" }, "message": "inotify: inotify_destroy_mark_entry could get called twice\n\ninotify_destroy_mark_entry could get called twice for the same mark since it\nis called directly in inotify_rm_watch and when the mark is being destroyed for\nanother reason. As an example assume that the file being watched was just\ndeleted so inotify_destroy_mark_entry would get called from the path\nfsnotify_inoderemove() -\u003e fsnotify_destroy_marks_by_inode() -\u003e\nfsnotify_destroy_mark_entry() -\u003e inotify_destroy_mark_entry(). If this\nhappened at the same time as userspace tried to remove a watch via\ninotify_rm_watch we could attempt to remove the mark from the idr twice and\ncould thus double dec the ref cnt and potentially could be in a use after\nfree/double free situation. The fix is to have inotify_rm_watch use the\ngeneric recursive safe fsnotify_destroy_mark_by_entry() so we are sure the\ninotify_destroy_mark_entry() function can only be called one.\n\nThis patch also renames the function to inotify_ingored_remove_idr() so it is\nclear what is actually going on in the function.\n\nHopefully this fixes:\n[ 20.342058] idr_remove called for id\u003d20 which is not allocated.\n[ 20.348000] Pid: 1860, comm: udevd Not tainted 2.6.30-tip #1077\n[ 20.353933] Call Trace:\n[ 20.356410] [\u003cffffffff811a82b7\u003e] idr_remove+0x115/0x18f\n[ 20.361737] [\u003cffffffff8134259d\u003e] ? _spin_lock+0x6d/0x75\n[ 20.367061] [\u003cffffffff8111640a\u003e] ? inotify_destroy_mark_entry+0xa3/0xcf\n[ 20.373771] [\u003cffffffff8111641e\u003e] inotify_destroy_mark_entry+0xb7/0xcf\n[ 20.380306] [\u003cffffffff81115913\u003e] inotify_freeing_mark+0xe/0x10\n[ 20.386238] [\u003cffffffff8111410d\u003e] fsnotify_destroy_mark_by_entry+0x143/0x170\n[ 20.393293] [\u003cffffffff811163a3\u003e] inotify_destroy_mark_entry+0x3c/0xcf\n[ 20.399829] [\u003cffffffff811164d1\u003e] sys_inotify_rm_watch+0x9b/0xc6\n[ 20.405850] [\u003cffffffff8100bcdb\u003e] system_call_fastpath+0x16/0x1b\n\nReported-by: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nTested-by: Peter Ziljlstra \u003cpeterz@infradead.org\u003e\n" }, { "commit": "a092ee20fd33d2df0990dcbf2235afc181612818", "tree": "c172839ce60bcc55e770e6707694842301e3ed6b", "parents": [ "e42e27736de80045f925564ea27a1d32957219e7" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 11:09:48 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:55 2009 -0400" }, "message": "fsnotify: allow groups to set freeing_mark to null\n\nMost fsnotify listeners (all but inotify) do not care about marks being\nfreed. Allow groups to set freeing_mark to null and do not call any\nfunction if it is set that way.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\n" }, { "commit": "e42e27736de80045f925564ea27a1d32957219e7", "tree": "cae8a5bc81f02c7563625e30f5f0d05357dc3701", "parents": [ "ce61856bd2aadb064f595e5c0444376a2b117c41" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 11:09:47 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "inotify/dnotify: should_send_event shouldn\u0027t match on FS_EVENT_ON_CHILD\n\ninotify and dnotify will both indicate that they want any event which came\nfrom a child inode. The fix is to mask off FS_EVENT_ON_CHILD when deciding\nif inotify or dnotify is interested in a given event.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\n" }, { "commit": "ce61856bd2aadb064f595e5c0444376a2b117c41", "tree": "4a438d07fbce1acbb3970b631211aaf445f2e41b", "parents": [ "5ac697b793a3c45005c568df692518da6e690390" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 11:09:47 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "dnotify: do not bother to lock entry-\u003elock when reading mask\n\nentry-\u003elock is needed to make sure entry-\u003emask does not change while\nmanipulating it. In dnotify_should_send_event() we don\u0027t care if we get an\nold or a new mask value out of this entry so there is no point it taking\nthe lock.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\n" }, { "commit": "5ac697b793a3c45005c568df692518da6e690390", "tree": "9481b421be4a67f91eb4a6f790e02cb555035cc9", "parents": [ "ff52cc2158b32b3b979ca7802b1fd7c70f36e13c" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 11:09:47 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "dnotify: do not use ?true:false when assigning to a bool\n\ndnotify_should send event assigned a bool using ?true:false when computing\na bit operation. This is poitless and the bool type does this for us.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\n" }, { "commit": "63c882a05416e18de6fb59f7dd6da48f3bbe8273", "tree": "b09cca0e3a996690c8965d9281cb1f386edd657b", "parents": [ "164bc6195139047faaf5ada1278332e99494803b" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:02:01 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "inotify: reimplement inotify using fsnotify\n\nReimplement inotify_user using fsnotify. This should be feature for feature\nexactly the same as the original inotify_user. This does not make any changes\nto the in kernel inotify feature used by audit. Those patches (and the eventual\nremoval of in kernel inotify) will come after the new inotify_user proves to be\nworking correctly.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "164bc6195139047faaf5ada1278332e99494803b", "tree": "fdc0e31f9dc15796a4777ed917533091797b8b69", "parents": [ "1ef5f13c6c8acd3fd10db9f1743f3b4cf30a4abb" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:58 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "fsnotify: handle filesystem unmounts with fsnotify marks\n\nWhen an fs is unmounted with an fsnotify mark entry attached to one of its\ninodes we need to destroy that mark entry and we also (like inotify) send\nan unmount event.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "1ef5f13c6c8acd3fd10db9f1743f3b4cf30a4abb", "tree": "b42f8aa8f74e598e47c114fc5141a8566a92d859", "parents": [ "e4aff117368cfdd3567ee41844d216d079b55173" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:54 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "fsnotify: fsnotify marks on inodes pin them in core\n\nThis patch pins any inodes with an fsnotify mark in core. The idea is that\nas soon as the mark is removed from the inode-\u003efsnotify_mark_entries list\nthe inode will be iput. In reality is doesn\u0027t quite work exactly this way.\nThe igrab will happen when the mark is added to an inode, but the iput will\nhappen when the inode pointer is NULL\u0027d inside the mark.\n\nIt\u0027s possible that 2 racing things will try to remove the mark from\ndifferent directions. One may try to remove the mark because of an\nexplicit request and one might try to remove it because the inode was\ndeleted. It\u0027s possible that the removal because of inode deletion will\nremove the mark from the inode\u0027s list, but the removal by explicit request\nwill actually set entry-\u003einode \u003d\u003d NULL; and call the iput. This is safe.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "e4aff117368cfdd3567ee41844d216d079b55173", "tree": "c467bc38edc7ba3154bbf6875dca635b855e1c8c", "parents": [ "47882c6f51e8ef41fbbe2bbb746a1ea3228dd7ca" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:50 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "fsnotify: allow groups to add private data to events\n\ninotify needs per group information attached to events. This patch allows\ngroups to attach private information and implements a callback so that\ninformation can be freed when an event is being destroyed.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "47882c6f51e8ef41fbbe2bbb746a1ea3228dd7ca", "tree": "d3dd3e8d0e4d3e3793f32107077839f787e35fcd", "parents": [ "62ffe5dfba056f7ba81d710fee9f28c58a42fdd6" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:47 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:54 2009 -0400" }, "message": "fsnotify: add correlations between events\n\nAs part of the standard inotify events it includes a correlation cookie\nbetween two dentry move operations. This patch includes the same behaviour\nin fsnotify events. It is needed so that inotify userspace can be\nimplemented on top of fsnotify.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "62ffe5dfba056f7ba81d710fee9f28c58a42fdd6", "tree": "ac0d4afc641bdc8ff76779545fde9c6ae539bdaf", "parents": [ "a2d8bc6cb4a3024661baf877242f123787d0c054" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:43 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:53 2009 -0400" }, "message": "fsnotify: include pathnames with entries when possible\n\nWhen inotify wants to send events to a directory about a child it includes\nthe name of the original file. This patch collects that filename and makes\nit available for notification.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "a2d8bc6cb4a3024661baf877242f123787d0c054", "tree": "4ff3f93877a8992d5383c14fb6012ab9b1954660", "parents": [ "3c5119c05d624f95f4967d16b38c9624b816bdb9" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:37 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:53 2009 -0400" }, "message": "fsnotify: generic notification queue and waitq\n\ninotify needs to do asyc notification in which event information is stored\non a queue until the listener is ready to receive it. This patch\nimplements a generic notification queue for inotify (and later fanotify) to\nstore events to be sent at a later time.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "3c5119c05d624f95f4967d16b38c9624b816bdb9", "tree": "0b5f66106aea38e52adf62958762b0a975607322", "parents": [ "c28f7e56e9d95fb531dc3be8df2e7f52bee76d21" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:33 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:53 2009 -0400" }, "message": "dnotify: reimplement dnotify using fsnotify\n\nReimplement dnotify using fsnotify.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "c28f7e56e9d95fb531dc3be8df2e7f52bee76d21", "tree": "efce13ed8c4f5b312ef0b77950489d52ef5a039a", "parents": [ "3be25f49b9d6a97eae9bcb96d3292072b7658bd8" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:29 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:53 2009 -0400" }, "message": "fsnotify: parent event notification\n\ninotify and dnotify both use a similar parent notification mechanism. We\nadd a generic parent notification mechanism to fsnotify for both of these\nto use. This new machanism also adds the dentry flag optimization which\nexists for inotify to dnotify.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "3be25f49b9d6a97eae9bcb96d3292072b7658bd8", "tree": "36f7d96481a47a6bde3c2f961346e940698111e0", "parents": [ "90586523eb4b349806887c62ee70685a49415124" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:26 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:53 2009 -0400" }, "message": "fsnotify: add marks to inodes so groups can interpret how to handle those inodes\n\nThis patch creates a way for fsnotify groups to attach marks to inodes.\nThese marks have little meaning to the generic fsnotify infrastructure\nand thus their meaning should be interpreted by the group that attached\nthem to the inode\u0027s list.\n\ndnotify and inotify will make use of these markings to indicate which\ninodes are of interest to their respective groups. But this implementation\nhas the useful property that in the future other listeners could actually\nuse the marks for the exact opposite reason, aka to indicate which inodes\nit had NO interest in.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "90586523eb4b349806887c62ee70685a49415124", "tree": "2ba6da637f897bbb2309b141b81801e4151d87b0", "parents": [ "c9059598ea8981d02356eead3188bf7fa4d717b8" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu May 21 17:01:20 2009 -0400" }, "committer": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Thu Jun 11 14:57:52 2009 -0400" }, "message": "fsnotify: unified filesystem notification backend\n\nfsnotify is a backend for filesystem notification. fsnotify does\nnot provide any userspace interface but does provide the basis\nneeded for other notification schemes such as dnotify. fsnotify\ncan be extended to be the backend for inotify or the upcoming\nfanotify. fsnotify provides a mechanism for \"groups\" to register for\nsome set of filesystem events and to then deliver those events to\nthose groups for processing.\n\nfsnotify has a number of benefits, the first being actually shrinking the size\nof an inode. Before fsnotify to support both dnotify and inotify an inode had\n\n unsigned long i_dnotify_mask; /* Directory notify events */\n struct dnotify_struct *i_dnotify; /* for directory notifications */\n struct list_head inotify_watches; /* watches on this inode */\n struct mutex inotify_mutex; /* protects the watches list\n\nBut with fsnotify this same functionallity (and more) is done with just\n\n __u32 i_fsnotify_mask; /* all events for this inode */\n struct hlist_head i_fsnotify_mark_entries; /* marks on this inode */\n\nThat\u0027s right, inotify, dnotify, and fanotify all in 64 bits. We used that\nmuch space just in inotify_watches alone, before this patch set.\n\nfsnotify object lifetime and locking is MUCH better than what we have today.\ninotify locking is incredibly complex. See 8f7b0ba1c8539 as an example of\nwhat\u0027s been busted since inception. inotify needs to know internal semantics\nof superblock destruction and unmounting to function. The inode pinning and\nvfs contortions are horrible.\n\nno fsnotify implementers do allocation under locks. This means things like\nf04b30de3 which (due to an overabundance of caution) changes GFP_KERNEL to\nGFP_NOFS can be reverted. There are no longer any allocation rules when using\nor implementing your own fsnotify listener.\n\nfsnotify paves the way for fanotify. In brief fanotify is a notification\nmechanism that delivers the lisener both an \u0027event\u0027 and an open file descriptor\nto the object in question. This means that fanotify is pathname agnostic.\nSome on lkml may not care for the original companies or users that pushed for\nTALPA, but fanotify was designed with flexibility and input for other users in\nmind. The readahead group expressed interest in fanotify as it could be used\nto profile disk access on boot without breaking the audit system. The desktop\nsearch groups have also expressed interest in fanotify as it solves a number\nof the race conditions and problems present with managing inotify when more\nthan a limited number of specific files are of interest. fanotify can provide\nfor a userspace access control system which makes it a clean interface for AV\nvendors to hook without trying to do binary patching on the syscall table,\nLSM, and everywhere else they do their things today. With this patch series\nfanotify can be implemented in less than 1200 lines of easy to review code.\nAlmost all of which is the socket based user interface.\n\nThis patch series builds fsnotify to the point that it can implement\ndnotify and inotify_user. Patches exist and will be sent soon after\nacceptance to finish the in kernel inotify conversion (audit) and implement\nfanotify.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nAcked-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Christoph Hellwig \u003chch@lst.de\u003e\n" }, { "commit": "381a80e6df396eaabef2c00f85974a4579ac1c70", "tree": "431f7f11302c3e41e1c93c76afd4e116d2464bfd", "parents": [ "fd1e6c1df5c396961509daac2b456852edf982df" ], "author": { "name": "Wu Fengguang", "email": "fengguang.wu@intel.com", "time": "Wed May 06 16:02:50 2009 -0700" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Wed May 06 16:36:09 2009 -0700" }, "message": "inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive\n\nThere is what we believe to be a false positive reported by lockdep.\n\ninotify_inode_queue_event() \u003d\u003e take inotify_mutex \u003d\u003e kernel_event() \u003d\u003e\nkmalloc() \u003d\u003e SLOB \u003d\u003e alloc_pages_node() \u003d\u003e page reclaim \u003d\u003e slab reclaim \u003d\u003e\ndcache reclaim \u003d\u003e inotify_inode_is_dead \u003d\u003e take inotify_mutex \u003d\u003e deadlock\n\nThe plan is to fix this via lockdep annotation, but that is proving to be\nquite involved.\n\nThe patch flips the allocation over to GFP_NFS to shut the warning up, for\nthe 2.6.30 release.\n\nHopefully we will fix this for real in 2.6.31. I\u0027ll queue a patch in -mm\nto switch it back to GFP_KERNEL so we don\u0027t forget.\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n [ INFO: inconsistent lock state ]\n 2.6.30-rc2-next-20090417 #203\n ---------------------------------\n inconsistent {RECLAIM_FS-ON-W} -\u003e {IN-RECLAIM_FS-W} usage.\n kswapd0/380 [HC0[0]:SC0[0]:HE1:SE1] takes:\n (\u0026inode-\u003einotify_mutex){+.+.?.}, at: [\u003cffffffff8112f1b5\u003e] inotify_inode_is_dead+0x35/0xb0\n {RECLAIM_FS-ON-W} state was registered at:\n [\u003cffffffff81079188\u003e] mark_held_locks+0x68/0x90\n [\u003cffffffff810792a5\u003e] lockdep_trace_alloc+0xf5/0x100\n [\u003cffffffff810f5261\u003e] __kmalloc_node+0x31/0x1e0\n [\u003cffffffff81130652\u003e] kernel_event+0xe2/0x190\n [\u003cffffffff81130826\u003e] inotify_dev_queue_event+0x126/0x230\n [\u003cffffffff8112f096\u003e] inotify_inode_queue_event+0xc6/0x110\n [\u003cffffffff8110444d\u003e] vfs_create+0xcd/0x140\n [\u003cffffffff8110825d\u003e] do_filp_open+0x88d/0xa20\n [\u003cffffffff810f6b68\u003e] do_sys_open+0x98/0x140\n [\u003cffffffff810f6c50\u003e] sys_open+0x20/0x30\n [\u003cffffffff8100c272\u003e] system_call_fastpath+0x16/0x1b\n [\u003cffffffffffffffff\u003e] 0xffffffffffffffff\n irq event stamp: 690455\n hardirqs last enabled at (690455): [\u003cffffffff81564fe4\u003e] _spin_unlock_irqrestore+0x44/0x80\n hardirqs last disabled at (690454): [\u003cffffffff81565372\u003e] _spin_lock_irqsave+0x32/0xa0\n softirqs last enabled at (690178): [\u003cffffffff81052282\u003e] __do_softirq+0x202/0x220\n softirqs last disabled at (690157): [\u003cffffffff8100d50c\u003e] call_softirq+0x1c/0x50\n\n other info that might help us debug this:\n 2 locks held by kswapd0/380:\n #0: (shrinker_rwsem){++++..}, at: [\u003cffffffff810d0bd7\u003e] shrink_slab+0x37/0x180\n #1: (\u0026type-\u003es_umount_key#17){++++..}, at: [\u003cffffffff8110cfbf\u003e] shrink_dcache_memory+0x11f/0x1e0\n\n stack backtrace:\n Pid: 380, comm: kswapd0 Not tainted 2.6.30-rc2-next-20090417 #203\n Call Trace:\n [\u003cffffffff810789ef\u003e] print_usage_bug+0x19f/0x200\n [\u003cffffffff81018bff\u003e] ? save_stack_trace+0x2f/0x50\n [\u003cffffffff81078f0b\u003e] mark_lock+0x4bb/0x6d0\n [\u003cffffffff810799e0\u003e] ? check_usage_forwards+0x0/0xc0\n [\u003cffffffff8107b142\u003e] __lock_acquire+0xc62/0x1ae0\n [\u003cffffffff810f478c\u003e] ? slob_free+0x10c/0x370\n [\u003cffffffff8107c0a1\u003e] lock_acquire+0xe1/0x120\n [\u003cffffffff8112f1b5\u003e] ? inotify_inode_is_dead+0x35/0xb0\n [\u003cffffffff81562d43\u003e] mutex_lock_nested+0x63/0x420\n [\u003cffffffff8112f1b5\u003e] ? inotify_inode_is_dead+0x35/0xb0\n [\u003cffffffff8112f1b5\u003e] ? inotify_inode_is_dead+0x35/0xb0\n [\u003cffffffff81012fe9\u003e] ? sched_clock+0x9/0x10\n [\u003cffffffff81077165\u003e] ? lock_release_holdtime+0x35/0x1c0\n [\u003cffffffff8112f1b5\u003e] inotify_inode_is_dead+0x35/0xb0\n [\u003cffffffff8110c9dc\u003e] dentry_iput+0xbc/0xe0\n [\u003cffffffff8110cb23\u003e] d_kill+0x33/0x60\n [\u003cffffffff8110ce23\u003e] __shrink_dcache_sb+0x2d3/0x350\n [\u003cffffffff8110cffa\u003e] shrink_dcache_memory+0x15a/0x1e0\n [\u003cffffffff810d0cc5\u003e] shrink_slab+0x125/0x180\n [\u003cffffffff810d1540\u003e] kswapd+0x560/0x7a0\n [\u003cffffffff810ce160\u003e] ? isolate_pages_global+0x0/0x2c0\n [\u003cffffffff81065a30\u003e] ? autoremove_wake_function+0x0/0x40\n [\u003cffffffff8107953d\u003e] ? trace_hardirqs_on+0xd/0x10\n [\u003cffffffff810d0fe0\u003e] ? kswapd+0x0/0x7a0\n [\u003cffffffff8106555b\u003e] kthread+0x5b/0xa0\n [\u003cffffffff8100d40a\u003e] child_rip+0xa/0x20\n [\u003cffffffff8100cdd0\u003e] ? restore_args+0x0/0x30\n [\u003cffffffff81065500\u003e] ? kthread+0x0/0xa0\n [\u003cffffffff8100d400\u003e] ? child_rip+0x0/0x20\n\n[eparis@redhat.com: fix audit too]\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nCc: Matt Mackall \u003cmpm@selenic.com\u003e\nCc: Christoph Lameter \u003cclameter@sgi.com\u003e\nSigned-off-by: Wu Fengguang \u003cfengguang.wu@intel.com\u003e\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "aabb8fdb41128705fd1627f56fdd571e45fdbcdb", "tree": "bae6e9abf167cf20b9a2d3e5c38520d3f17b777d", "parents": [ "1bd7903560f1f713e85188a5aaf4d2428b6c8b50" ], "author": { "name": "Nick Piggin", "email": "npiggin@suse.de", "time": "Wed Mar 11 13:17:36 2009 -0700" }, "committer": { "name": "Al Viro", "email": "viro@zeniv.linux.org.uk", "time": "Fri Mar 27 14:44:05 2009 -0400" }, "message": "fs: avoid I_NEW inodes\n\nTo be on the safe side, it should be less fragile to exclude I_NEW inodes\nfrom inode list scans by default (unless there is an important reason to\nhave them).\n\nNormally they will get excluded (eg. by zero refcount or writecount etc),\nhowever it is a bit fragile for list walkers to know exactly what parts of\nthe inode state is set up and valid to test when in I_NEW. So along these\nlines, move I_NEW checks upward as well (sometimes taking I_FREEING etc\nchecks with them too -- this shouldn\u0027t be a problem should it?)\n\nSigned-off-by: Nick Piggin \u003cnpiggin@suse.de\u003e\nAcked-by: Jan Kara \u003cjack@suse.cz\u003e\nCc: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\n" }, { "commit": "f04b30de3c82528f1ab4c58b3dd4c975f5341901", "tree": "1d3410190d93a72c0a98961704086ba17c21d326", "parents": [ "be50344e604f956891fc0013f1ba78823a758124" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Wed Feb 18 14:48:43 2009 -0800" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Wed Feb 18 15:37:56 2009 -0800" }, "message": "inotify: fix GFP_KERNEL related deadlock\n\nEnhanced lockdep coverage of __GFP_NOFS turned up this new lockdep\nassert:\n\n[ 1093.677775]\n[ 1093.677781] \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n[ 1093.680031] [ INFO: inconsistent lock state ]\n[ 1093.680031] 2.6.29-rc5-tip-01504-gb49eca1-dirty #1\n[ 1093.680031] ---------------------------------\n[ 1093.680031] inconsistent {RECLAIM_FS-ON-W} -\u003e {IN-RECLAIM_FS-W} usage.\n[ 1093.680031] kswapd0/308 [HC0[0]:SC0[0]:HE1:SE1] takes:\n[ 1093.680031] (\u0026inode-\u003einotify_mutex){+.+.?.}, at: [\u003cc0205942\u003e] inotify_inode_is_dead+0x20/0x80\n[ 1093.680031] {RECLAIM_FS-ON-W} state was registered at:\n[ 1093.680031] [\u003cc01696b9\u003e] mark_held_locks+0x43/0x5b\n[ 1093.680031] [\u003cc016baa4\u003e] lockdep_trace_alloc+0x6c/0x6e\n[ 1093.680031] [\u003cc01cf8b0\u003e] kmem_cache_alloc+0x20/0x150\n[ 1093.680031] [\u003cc040d0ec\u003e] idr_pre_get+0x27/0x6c\n[ 1093.680031] [\u003cc02056e3\u003e] inotify_handle_get_wd+0x25/0xad\n[ 1093.680031] [\u003cc0205f43\u003e] inotify_add_watch+0x7a/0x129\n[ 1093.680031] [\u003cc020679e\u003e] sys_inotify_add_watch+0x20f/0x250\n[ 1093.680031] [\u003cc010389e\u003e] sysenter_do_call+0x12/0x35\n[ 1093.680031] [\u003cffffffff\u003e] 0xffffffff\n[ 1093.680031] irq event stamp: 60417\n[ 1093.680031] hardirqs last enabled at (60417): [\u003cc018d5f5\u003e] call_rcu+0x53/0x59\n[ 1093.680031] hardirqs last disabled at (60416): [\u003cc018d5b9\u003e] call_rcu+0x17/0x59\n[ 1093.680031] softirqs last enabled at (59656): [\u003cc0146229\u003e] __do_softirq+0x157/0x16b\n[ 1093.680031] softirqs last disabled at (59651): [\u003cc0106293\u003e] do_softirq+0x74/0x15d\n[ 1093.680031]\n[ 1093.680031] other info that might help us debug this:\n[ 1093.680031] 2 locks held by kswapd0/308:\n[ 1093.680031] #0: (shrinker_rwsem){++++..}, at: [\u003cc01b0502\u003e] shrink_slab+0x36/0x189\n[ 1093.680031] #1: (\u0026type-\u003es_umount_key#4){+++++.}, at: [\u003cc01e6d77\u003e] shrink_dcache_memory+0x110/0x1fb\n[ 1093.680031]\n[ 1093.680031] stack backtrace:\n[ 1093.680031] Pid: 308, comm: kswapd0 Not tainted 2.6.29-rc5-tip-01504-gb49eca1-dirty #1\n[ 1093.680031] Call Trace:\n[ 1093.680031] [\u003cc016947a\u003e] valid_state+0x12a/0x13d\n[ 1093.680031] [\u003cc016954e\u003e] mark_lock+0xc1/0x1e9\n[ 1093.680031] [\u003cc016a5b4\u003e] ? check_usage_forwards+0x0/0x3f\n[ 1093.680031] [\u003cc016ab74\u003e] __lock_acquire+0x2c6/0xac8\n[ 1093.680031] [\u003cc01688d9\u003e] ? register_lock_class+0x17/0x228\n[ 1093.680031] [\u003cc016b3d3\u003e] lock_acquire+0x5d/0x7a\n[ 1093.680031] [\u003cc0205942\u003e] ? inotify_inode_is_dead+0x20/0x80\n[ 1093.680031] [\u003cc08824c4\u003e] __mutex_lock_common+0x3a/0x4cb\n[ 1093.680031] [\u003cc0205942\u003e] ? inotify_inode_is_dead+0x20/0x80\n[ 1093.680031] [\u003cc08829ed\u003e] mutex_lock_nested+0x2e/0x36\n[ 1093.680031] [\u003cc0205942\u003e] ? inotify_inode_is_dead+0x20/0x80\n[ 1093.680031] [\u003cc0205942\u003e] inotify_inode_is_dead+0x20/0x80\n[ 1093.680031] [\u003cc01e6672\u003e] dentry_iput+0x90/0xc2\n[ 1093.680031] [\u003cc01e67a3\u003e] d_kill+0x21/0x45\n[ 1093.680031] [\u003cc01e6a46\u003e] __shrink_dcache_sb+0x27f/0x355\n[ 1093.680031] [\u003cc01e6dc5\u003e] shrink_dcache_memory+0x15e/0x1fb\n[ 1093.680031] [\u003cc01b05ed\u003e] shrink_slab+0x121/0x189\n[ 1093.680031] [\u003cc01b0d12\u003e] kswapd+0x39f/0x561\n[ 1093.680031] [\u003cc01ae499\u003e] ? isolate_pages_global+0x0/0x233\n[ 1093.680031] [\u003cc0157eae\u003e] ? autoremove_wake_function+0x0/0x43\n[ 1093.680031] [\u003cc01b0973\u003e] ? kswapd+0x0/0x561\n[ 1093.680031] [\u003cc0157daf\u003e] kthread+0x41/0x82\n[ 1093.680031] [\u003cc0157d6e\u003e] ? kthread+0x0/0x82\n[ 1093.680031] [\u003cc01043ab\u003e] kernel_thread_helper+0x7/0x10\n\ninotify_handle_get_wd() does idr_pre_get() which does a\nkmem_cache_alloc() without __GFP_FS - and is hence deadlockable under\nextreme MM pressure.\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nAcked-by: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: MinChan Kim \u003cminchan.kim@gmail.com\u003e\nCc: Nick Piggin \u003cnickpiggin@yahoo.com.au\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "3632dee2f8b8a9720329f29eeaa4ec4669a3aff8", "tree": "602fc5cc96145472210a4254680d539c81cb02e7", "parents": [ "aeb565dfc3ac4c8b47c5049085b4c7bfb2c7d5d7" ], "author": { "name": "Vegard Nossum", "email": "vegard.nossum@gmail.com", "time": "Thu Jan 22 15:29:45 2009 +0100" }, "committer": { "name": "Linus Torvalds", "email": "torvalds@linux-foundation.org", "time": "Mon Jan 26 10:08:05 2009 -0800" }, "message": "inotify: clean up inotify_read and fix locking problems\n\nIf userspace supplies an invalid pointer to a read() of an inotify\ninstance, the inotify device\u0027s event list mutex is unlocked twice.\nThis causes an unbalance which effectively leaves the data structure\nunprotected, and we can trigger oopses by accessing the inotify\ninstance from different tasks concurrently.\n\nThe best fix (contributed largely by Linus) is a total rewrite\nof the function in question:\n\nOn Thu, Jan 22, 2009 at 7:05 AM, Linus Torvalds wrote:\n\u003e The thing to notice is that:\n\u003e\n\u003e - locking is done in just one place, and there is no question about it\n\u003e not having an unlock.\n\u003e\n\u003e - that whole double-while(1)-loop thing is gone.\n\u003e\n\u003e - use multiple functions to make nesting and error handling sane\n\u003e\n\u003e - do error testing after doing the things you always need to do, ie do\n\u003e this:\n\u003e\n\u003e mutex_lock(..)\n\u003e ret \u003d function_call();\n\u003e mutex_unlock(..)\n\u003e\n\u003e .. test ret here ..\n\u003e\n\u003e instead of doing conditional exits with unlocking or freeing.\n\u003e\n\u003e So if the code is written in this way, it may still be buggy, but at least\n\u003e it\u0027s not buggy because of subtle \"forgot to unlock\" or \"forgot to free\"\n\u003e issues.\n\u003e\n\u003e This _always_ unlocks if it locked, and it always frees if it got a\n\u003e non-error kevent.\n\nCc: John McCutchan \u003cttb@tentacle.dhs.org\u003e\nCc: Robert Love \u003crlove@google.com\u003e\nCc: \u003cstable@kernel.org\u003e\nSigned-off-by: Vegard Nossum \u003cvegard.nossum@gmail.com\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n" }, { "commit": "2e4d0924eb0c403ce4014fa139d1d61bf2c44fee", "tree": "58249b615c3a7a77154d4c9d006ea9acd04bbef9", "parents": [ "938bb9f5e840eddbf54e4f62f6c5ba9b3ae12c9d" ], "author": { "name": "Heiko Carstens", "email": "heiko.carstens@de.ibm.com", "time": "Wed Jan 14 14:14:31 2009 +0100" }, "committer": { "name": "Heiko Carstens", "email": "heiko.carstens@de.ibm.com", "time": "Wed Jan 14 14:15:30 2009 +0100" }, "message": "[CVE-2009-0029] System call wrappers part 29\n\nSigned-off-by: Heiko Carstens \u003cheiko.carstens@de.ibm.com\u003e\n" }, { "commit": "938bb9f5e840eddbf54e4f62f6c5ba9b3ae12c9d", "tree": "a25324159ed8cc96b97a4d39aaf228bbd07e3824", "parents": [ "1e7bfb2134dfec37ce04fb3a4ca89299e892d10c" ], "author": { "name": "Heiko Carstens", "email": "heiko.carstens@de.ibm.com", "time": "Wed Jan 14 14:14:30 2009 +0100" }, "committer": { "name": "Heiko Carstens", "email": "heiko.carstens@de.ibm.com", "time": "Wed Jan 14 14:15:30 2009 +0100" }, "message": "[CVE-2009-0029] System call wrappers part 28\n\nSigned-off-by: Heiko Carstens \u003cheiko.carstens@de.ibm.com\u003e\n" }, { "commit": "4ae8978cf92a96257cd8998a49e781be83571d64", "tree": "5c5e2719c17093309b4e22bfbf4deb7bd3e91ac8", "parents": [ "2f1169e2dc0c70e213f79ada88a10912cc2fbe94" ], "author": { "name": "Michael Kerrisk", "email": "mtk.manpages@googlemail.com", "time": "Mon Jan 05 07:19:16 2009 -0500" }, "committer": { "name": "Al Viro", "email": "viro@zeniv.linux.org.uk", "time": "Mon Jan 05 11:54:29 2009 -0500" }, "message": "inotify: fix type errors in interfaces\n\nThe problems lie in the types used for some inotify interfaces, both at the kernel level and at the glibc level. This mail addresses the kernel problem. I will follow up with some suggestions for glibc changes.\n\nFor the sys_inotify_rm_watch() interface, the type of the \u0027wd\u0027 argument is\ncurrently \u0027u32\u0027, it should be \u0027__s32\u0027 . That is Robert\u0027s suggestion, and\nis consistent with the other declarations of watch descriptors in the\nkernel source, in particular, the inotify_event structure in\ninclude/linux/inotify.h:\n\nstruct inotify_event {\n __s32 wd; /* watch descriptor */\n __u32 mask; /* watch mask */\n __u32 cookie; /* cookie to synchronize two events */\n __u32 len; /* length (including nulls) of name */\n char name[0]; /* stub for possible name */\n};\n\nThe patch makes the changes needed for inotify_rm_watch().\n\nSigned-off-by: Michael Kerrisk \u003cmtk.manpages@googlemail.com\u003e\nCc: Robert Love \u003crlove@google.com\u003e\nCc: Vegard Nossum \u003cvegard.nossum@gmail.com\u003e\nCc: Ulrich Drepper \u003cdrepper@redhat.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\n" }, { "commit": "272eb01485dda98e3b8910c7c1a53d597616b0a0", "tree": "6a1dcd34c1dd668b465c166c2d6d2596924eff5f", "parents": [ "c2acf7b90821785fe812cc0aa05148e5a1f84204" ], "author": { "name": "Eric Paris", "email": "eparis@redhat.com", "time": "Wed Dec 17 13:59:41 2008 -0500" }, "committer": { "name": "Al Viro", "email": "viro@zeniv.linux.org.uk", "time": "Wed Dec 31 18:07:43 2008 -0500" }, "message": "filesystem notification: create fs/notify to contain all fs notification\n\nCreating a generic filesystem notification interface, fsnotify, which will be\nused by inotify, dnotify, and eventually fanotify is really starting to\nclutter the fs directory. This patch simply moves inotify and dnotify into\nfs/notify/inotify and fs/notify/dnotify respectively to make both current fs/\nand future notification tidier.\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\nSigned-off-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\n" } ] }