um: Silence lockdep complaint about mmap_sem [Linux 4.9.187]

This Linux kernel change "um: Silence lockdep complaint about mmap_sem" is included in the Linux 4.9.187 release. This change is authored by Johannes Berg <johannes.berg [at]> on Fri May 24 21:54:14 2019 +0200. The commit for this change in Linux stable tree is 20756b7 (patch) which is from upstream commit 80bf6ce. The same Linux upstream change may have been applied to various maintained Linux releases and you can find all Linux releases containing changes from upstream 80bf6ce.

um: Silence lockdep complaint about mmap_sem

[ Upstream commit 80bf6ceaf9310b3f61934c69b382d4912deee049 ]

When we get into activate_mm(), lockdep complains that we're doing
something strange:

    WARNING: possible circular locking dependency detected
    5.1.0-10252-gb00152307319-dirty #121 Not tainted
    ------------------------------------------------------ is trying to acquire lock:
    (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7

    but task is already holding lock:
    (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&mm->mmap_sem){++++}:

    -> #0 (&(&p->alloc_lock)->rlock){+.+.}:

    other info that might help us debug this:

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----

     *** DEADLOCK ***

    2 locks held by
     #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869
     #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7

    stack backtrace:
    CPU: 0 PID: 366 Comm: Not tainted 5.1.0-10252-gb00152307319-dirty #121
    Call Trace:
     [<600420de>] show_stack+0x13b/0x155
     [<6048906b>] dump_stack+0x2a/0x2c
     [<6009ae64>] print_circular_bug+0x332/0x343
     [<6009c5c6>] check_prev_add+0x669/0xdad
     [<600a06b4>] __lock_acquire+0x12ab/0x139f
     [<6009f3d0>] lock_acquire+0x155/0x18e
     [<604a07e0>] _raw_spin_lock+0x30/0x83
     [<60151e6a>] flush_old_exec+0x703/0x8d7
     [<601a8eb8>] load_elf_binary+0x2ca/0xddb

I think it's because in exec_mmap() we have

    activate_mm(active_mm, mm);
    (which does down_write(&mm->mmap_sem))

I'm not really sure why lockdep throws in the whole knowledge
about the task lock, but it seems that old_mm and mm shouldn't
ever be the same (and it doesn't deadlock) so tell lockdep that
they're different.

Signed-off-by: Johannes Berg <>
Signed-off-by: Richard Weinberger <>
Signed-off-by: Sasha Levin <>

There are 2 lines of Linux source code added/deleted in this change. Code changes to Linux kernel are as follows.

 arch/um/include/asm/mmu_context.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
index 1a60e13..6aca4c9 100644
--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -56,7 +56,7 @@ static inline void activate_mm(struct mm_struct *old, struct mm_struct *new)
     * when the new ->mm is used for the first time.
-   down_write(&new->mmap_sem);
+   down_write_nested(&new->mmap_sem, 1);

Leave a Reply

Your email address will not be published. Required fields are marked *