Here is another version, with the incremental patch rolled up, andadded reclaim context annotation to kswapd, and allocation tracingto slab allocators (which may only ever reach the page allocatorin rare cases, so it is good to put annotations here too).

Haven't tested this version as such, but it should be getting closerto merge worthy ;)

--After noticing some code in mm/filemap.c accidentally perform a __GFP_FSallocation when it should not have been, I thought it might be a good idea totry to catch this kind of thing with lockdep.

I coded up a little idea that seems to work. Unfortunately the system has toactually be in __GFP_FS page reclaim, then take the lock, before it will markit. But at least that might still be some orders of magnitude more common(and more debuggable) than an actual deadlock condition, so we have someimprovement I hope (the concept is no less complete than discovery of a lock'sinterrupt contexts).

I guess we could even do the same thing with __GFP_IO (normal reclaim), andeven GFP_NOIO locks too... but filesystems will have the most locks and fiddlycode paths, so let's start there and see how it goes.

+ /*+ * Prove that the new dependency does not connect a reclaim-fs-safe+ * lock with a reclaim-fs-unsafe lock - to achieve this we search+ * the backwards-subgraph starting at <prev>, and the+ * forwards-subgraph starting at <next>:+ */+ if (!check_usage(curr, prev, next, LOCK_USED_IN_RECLAIM_FS,+ LOCK_HELD_OVER_RECLAIM_FS, "reclaim-fs"))+ return 0;++ /*+ * Prove that the new dependency does not connect a reclaim-fs-safe-read+ * lock with a reclaim-fs-unsafe lock - to achieve this we search+ * the backwards-subgraph starting at <prev>, and the+ * forwards-subgraph starting at <next>:+ */+ if (!check_usage(curr, prev, next, LOCK_USED_IN_RECLAIM_FS_READ,+ LOCK_HELD_OVER_RECLAIM_FS, "reclaim-fs-read"))+ return 0;+ return 1; }