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 <nbori...@suse.com>
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.l...@gmail.com
Cc: mi...@redhat.com
Acked-by: Michal Hocko <mho...@suse.cz>
Signed-off-by: Nikolay Borisov <nbori...@suse.com>
Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Link:
http://lkml.kernel.org/r/1488367797-27278-1-git-send-email-nbori...@suse.com
---
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)
