* Nick Piggin <npiggin@xxxxxxx> 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 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
