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.GC22544@xxxxxxxxxxxxxx --- >From 1968c0a8ace4090a9deca8f4c1a206ee546e595a Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko@xxxxxxxx> Date: Wed, 27 Apr 2016 22:32:57 +0200 Subject: [PATCH] fold me "mm: introduce memalloc_nofs_{save,restore} API" Lockdep infrastructure is hooked into early hot paths of the allocator so __lockdep_trace_alloc has to check for PF_MEMALLOC_NOFS directly and do not rely on current_gfp_context Signed-off-by: Michal Hocko <mhocko@xxxxxxxx> --- kernel/locking/lockdep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 716547fdb873..f60124d0871c 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -2750,7 +2750,7 @@ static void __lockdep_trace_alloc(gfp_t gfp_mask, unsigned long flags) return; /* We're only interested __GFP_FS allocations for now */ - if (!(gfp_mask & __GFP_FS)) + if (!(gfp_mask & __GFP_FS) || (curr->flags & PF_MEMALLOC_NOFS)) return; /* -- 2.8.0.rc3 -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>