Re: [PATCH v3] lockdep: Teach lockdep about memalloc_noio_save

[Peter Zijlstra]

On Wed, Mar 01, 2017 at 01:29:57PM +0200, Nikolay Borisov wrote:
> Commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O
> during memory allocation") added the memalloc_noio_(save|restore) functions
> to enable people to modify the MM behavior by disbaling I/O during memory
> allocation. This was further extended in Fixes: 934f3072c17c ("mm: clear 
> __GFP_FS when PF_MEMALLOC_NOIO is set"). memalloc_noio_* functions prevent 
> allocation paths recursing back into the filesystem without explicitly 
> changing the flags for every allocation site. However, lockdep hasn't been 
> keeping up with the changes and it entirely misses handling the memalloc_noio
> adjustments. Instead, it is left to the callers of __lockdep_trace_alloc to 
> call the functino after they have shaven the respective GFP flags. 
> 
> Let's fix this by making lockdep explicitly do the shaving of respective
> GFP flags. 

I edited that to look like the below, then my compiler said:

../kernel/locking/lockdep.c: In function âlockdep_set_current_reclaim_stateâ:
../kernel/locking/lockdep.c:3866:33: error: implicit declaration of function âmemalloc_noio_flagsâ [-Werror=implicit-function-declaration]
  current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);
                                 ^~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
../scripts/Makefile.build:294: recipe for target 'kernel/locking/lockdep.o' failed



---
Subject: lockdep: Teach lockdep about memalloc_noio_save
From: Nikolay Borisov <nborisov@xxxxxxxx>
Date: Wed, 1 Mar 2017 13:29:57 +0200

Commit 21caf2fc1931 ("mm: teach mm by current context info to not do
I/O during memory allocation") added the memalloc_noio_(save|restore)
functions to enable people to modify the MM behavior by disbaling I/O
during memory allocation.

This was further extended in commit: 934f3072c17c ("mm: clear __GFP_FS
when PF_MEMALLOC_NOIO is set"). memalloc_noio_* functions prevent
allocation paths recursing back into the filesystem without explicitly
changing the flags for every allocation site.

However, people forgot to update lockdep with the changes and it
entirely misses handling the memalloc_noio adjustments. Instead, it is
left to the callers of __lockdep_trace_alloc to call the function
after they have shaven the respective GFP flags.

Fixes: 934f3072c17c ("mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set")
Cc: vbabka.lkml@xxxxxxxxx
Cc: mingo@xxxxxxxxxx
Acked-by: Michal Hocko <mhocko@xxxxxxx>
Signed-off-by: Nikolay Borisov <nborisov@xxxxxxxx>
Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
Link: http://lkml.kernel.org/r/1488367797-27278-1-git-send-email-nborisov@xxxxxxxx
---
 kernel/locking/lockdep.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Changes since v2: 
	* Incorporate Michal's suggestion of using memalloc_noio_flags explicitly. 
	* Tune the commit message to make the problem statement a bit more
	descriptive. 

--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2861,6 +2861,8 @@ static void __lockdep_trace_alloc(gfp_t
 	if (unlikely(!debug_locks))
 		return;
 
+	gfp_mask = memalloc_noio_flags(gfp_mask);
+
 	/* no reclaim without waiting on it */
 	if (!(gfp_mask & __GFP_DIRECT_RECLAIM))
 		return;
@@ -3852,7 +3854,7 @@ EXPORT_SYMBOL_GPL(lock_unpin_lock);
 
 void lockdep_set_current_reclaim_state(gfp_t gfp_mask)
 {
-	current->lockdep_reclaim_gfp = gfp_mask;
+	current->lockdep_reclaim_gfp = memalloc_noio_flags(gfp_mask);
 }
 
 void lockdep_clear_current_reclaim_state(void)