Subject : 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory) Submitter : Stefan Richter <stefanr@s5r6.in-berlin.de> Date : 2010-09-01 6:37 Message-ID : tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de References : http://marc.info/?l=linux-kernel&m=128332308528119&w=2 This entry is being used for tracking a regression from 2.6.35. Please don't close it until the problem is fixed in the mainline.
bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=17752 > > > Maciej Rutecki <maciej.rutecki@gmail.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?
On Monday, September 20, 2010, Stefan Richter wrote: > Rafael J. Wysocki wrote: > > This message has been generated automatically as a part of a summary report > > of recent regressions. > > > > The following bug entry is on the current list of known regressions > > from 2.6.35. Please verify if it still should be listed and let the > tracking team > > know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17752 > > Subject : 2.6.36-rc3: inconsistent lock state (iprune_sem, > shrink_icache_memory) > > Submitter : Stefan Richter <stefanr@s5r6.in-berlin.de> > > Date : 2010-09-01 6:37 (20 days old) > > Message-ID : <tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de> > > References : http://marc.info/?l=linux-kernel&m=128332308528119&w=2 > > I think this should not be marked as a regression. See the older reports of > very similar issues (in my LKML mail from September 3, logged in bugzilla in > comment #1) > http://lkml.org/lkml/2010/1/15/76 (2.6.33-rc, xfs involved) > http://lkml.org/lkml/2010/1/18/108 (2.6.32.y, ntfs involved) > and hch's analysis in the first of these two threads > http://lkml.org/lkml/2010/1/19/267 (several filesystems and > other code paths) > So, unless my trace was a code path that only newly acquired that oldproblem > of other code paths, this is an older issue. Alas this is not obvious to me > at least from the log that I got. > > I did not have lockdep enabled on the machine which delivered the log during > the last few months or so; I just remembered to re-enable it at the occasion > of switching to 2.6.36-rc.
Dropping from the list of recent regressions.