bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=17752 > > > Maciej Rutecki <maciej.rutecki@xxxxxxxxx> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Blocks| |16444 This is probably not a regression. See this earlier discussion: http://lkml.org/lkml/2010/1/15/76 And another report, coincidentally at the same time: http://lkml.org/lkml/2010/1/18/108 As I understand Christoph's post on January 19, several code paths are independently affected: http://lkml.org/lkml/2010/1/19/267 (Maybe some of those have been fixed in the meantime.) I don't see in my trace from September 1 which filesystem caused the particular lockdep report. I may have unmounted ext4, vfat, or fuse prior to that. Dave wrote on September 2: >> Any memory allocation that enters reclaim in the unmount path will >> generate this warning. The problem is that the normal memory reclaim >> path is: >> >> alloc -> reclaim -> shrink_slab -> shrink_icache_memory -> iprune_sem -> s_umount >> >> while unmmount does: >> >> unmount -> s_umount -> alloc -> lockdep goes boom! >> or >> unmount -> iprune_sem -> alloc -> lockdep goes boom! >> >> I never got a straight answer on this, but it the warnings are >> indicating that you must use GFP_NOFS allocations for every >> allocation in the unmount path, which is kind of hard to know >> about given the code is not unomunt path specific.... Is it feasible to add a gfp_flag argument to all call chains that could lead to allocations in unmount? -- Stefan Richter -=====-==-=- =--= ---== http://arcgraph.de/sr/ -- 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
