Re: [rfc] lockdep: check fs reclaim recursion

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <npiggin@suse.de> wrote:

> Hi,
> 
> After yesterday noticing some code in mm/filemap.c accidentally perform 
> a __GFP_FS allocation when it should not have been, I thought it might 
> be a good idea to try to catch this kind of thing with lockdep.
> 
> I coded up a little idea that seems to work. Unfortunately the system 
> has to actually be in __GFP_FS page reclaim, then take the lock, before 
> it will mark it. But at least that might still be some orders of 
> magnitude more common (and more debuggable) than an actual deadlock 
> condition, so we have some improvement I hope.
> 
> I guess we could do the same thing with __GFP_IO and even GFP_NOIO 
> locks too, but I don't know how expensive it is to add these 
> annotations to lockdep. [...]

Same cost as normal locking, i.e. as cheap and local as it gets. Lockdep 
is only expensive computationally when new rules are discovered and have 
to be validated - but that is rare.

Nice feature - and we want more of this type of preventive dependency 
tracking - so feel free to add it whenever you run into an example like 
this.

What merge route would you prefer? tip/core/locking would be the natural 
home of it (we already have a fair bit of lockdep stuff queued up there 
for v2.6.29) - it also touches a few FS bits.

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>