OK, so the lockdep splats I was seeing [1] were much easier to fix than
I originally thought. So the following should be folded into the
original patch. I will send the full patch later on.
[1] http://lkml.kernel.org/r/20160427200927.gc22...@dhcp22.suse.cz
---
>From 1968c0a8ace4090a9deca8f4c1a206e
On Wed 27-04-16 22:09:27, Michal Hocko wrote:
[...]
> [ 53.993480] [] mark_held_locks+0x5e/0x74
> [ 53.993480] [] lockdep_trace_alloc+0xb2/0xb5
> [ 53.993480] [] kmem_cache_alloc+0x36/0x2b0
Scratch that. I got it. It is the lockdep annotation which I got wrong
with my patch. I thought
Hi Dave,
On Wed 27-04-16 13:54:35, Michal Hocko wrote:
[...]
> diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h
> index 0d83f332e5c2..b35688a54c9a 100644
> --- a/fs/xfs/kmem.h
> +++ b/fs/xfs/kmem.h
> @@ -50,7 +50,7 @@ kmem_flags_convert(xfs_km_flags_t flags)
> lflags = GFP_ATOMIC | __GFP_N
On Wed 27-04-16 13:54:35, Michal Hocko wrote:
> From: Michal Hocko
>
Ups missed Dave's note about:
> GFP_NOFS context is used for the following 4 reasons currently
> - to prevent from deadlocks when the lock held by the allocation
> context would be needed during the memory reclai
