| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 03 Sep 2010 23:34:56 +0200 From: Stefan Richter <stefanr@...6.in-berlin.de> To: linux-fsdevel@...r.kernel.org CC: bugzilla-daemon@...zilla.kernel.org, linux-kernel@...r.kernel.org, Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@...radead.org> Subject: Re: [Bug 17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory) bugzilla-daemon@...zilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=17752 > > > Maciej Rutecki <maciej.rutecki@...il.com> 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-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists