Re: [Bug 17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

Re: [Bug 17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Stefan Richter]

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?
-- 
Stefan Richter
-=====-==-=- =--= ---==
http://arcgraph.de/sr/

Re: [Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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.

Thanks a lot for the info, I've dropped this bug from the list of recent regressions.

Rafael

Re: [Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
> > Date		: 2010-09-01 6:37 (20 days old)
> > Message-ID	: <tkrat.ed8eda6bc8ffe64e-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
> > 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.

Thanks a lot for the info, I've dropped this bug from the list of recent regressions.

Rafael

Re: [Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Stefan Richter]

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.
-- 
Stefan Richter
-=====-==-=- =--= =-=--
http://arcgraph.de/sr/

Re: [Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Stefan Richter]

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-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
> Date		: 2010-09-01 6:37 (20 days old)
> Message-ID	: <tkrat.ed8eda6bc8ffe64e-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
> 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.
-- 
Stefan Richter
-=====-==-=- =--= =-=--
http://arcgraph.de/sr/

[Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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

[Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
Date		: 2010-09-01 6:37 (20 days old)
Message-ID	: <tkrat.ed8eda6bc8ffe64e-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
References	: http://marc.info/?l=linux-kernel&m=128332308528119&w=2

[Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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 (12 days old)
Message-ID	: <tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de>
References	: http://marc.info/?l=linux-kernel&m=128332308528119&w=2

[Bug #17752] 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)

[Rafael J. Wysocki]

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-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
Date		: 2010-09-01 6:37 (12 days old)
Message-ID	: <tkrat.ed8eda6bc8ffe64e-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
References	: http://marc.info/?l=linux-kernel&m=128332308528119&w=2