Mel Gorman <mgorman@xxxxxxx> writes: > On Wed, Jan 11, 2012 at 09:11:27AM -0800, Eric W. Biederman wrote: >> > In Miklos's case, the problem is with the bonding driver but during >> > CPU online or offline, a number of dentries are being created and >> > deleted and this deadlock is also being hit. Looking at sysfs, there >> > is a global sysfs_mutex that protects the sysfs directory tree from >> > concurrent reclaims. Almost all operations involving directory inodes >> > and dentries take place under the sysfs_mutex - linking, unlinking, >> > patch searching lookup, renames and readdir. d_invalidate is slightly >> > different. It is mostly under the mutex but if the dentry has to be >> > removed from the dcache, the mutex is dropped. >> >> The sysfs_mutex protects the sysfs data structures not the vfs. >> > > Ok. > >> > Where as Miklos' patch changes dcache, this patch changes sysfs to >> > consistently hold the mutex for dentry-related operations. Once >> > applied, this particular bug with CPU hotadd/hotremove no longer >> > occurs. >> >> After taking a quick skim over the code to reacquaint myself with >> it appears that the usage in sysfs is idiomatic. That is sysfs >> uses shrink_dcache_parent without a lock and in a context where >> the right race could trigger this deadlock. >> > > Yes. > >> And in particular I expect you could trigger the same deadlock in >> proc, nfs, and gfs2 with if you can get the timing right. >> > > Agreed. When the dcache-specific fix was being discussed on an external > bugzilla, this came up. It's probably easiest to race in sysfs because > it's possible to create/delete directories faster than is possible > for proc, nfs or gfs2. I expect we see the race in sysfs because of uevents that get triggered on hotplug. So a lot is occurring around the time of the race. You can get to shrink_dcache_parent with fork/exit in proc which is a lot easier to trigger. But usually in fork/exec you don't have the dentries cached... > Since I wrote this patch, the dcache specific fix was finished, merged > and I expect it'll make it to stable. Assuming that happens, this patch > will no longer be required. Sounds good. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
