Commit 5dfa8607 authored by Nicolas Saenz Julienne's avatar Nicolas Saenz Julienne Committed by Zheng Zengkai
Browse files

mm: mmap_lock: use local locks instead of disabling preemption

mainline inclusion
from mainline-5.14-rc1
commit 832b5072
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RL0T
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=832b50725373e8c46781b7d4db104ec9cf564a6b

-------------------------------------------------

mmap_lock will explicitly disable/enable preemption upon manipulating its
local CPU variables.  This is to be expected, but in this case, it doesn't
play well with PREEMPT_RT.  The preemption disabled code section also
takes a spin-lock.  Spin-locks in RT systems will try to schedule, which
is exactly what we're trying to avoid.

To mitigate this, convert the explicit preemption handling to local_locks.
Which are RT aware, and will disable migration instead of preemption when
PREEMPT_RT=y.

The faulty call trace looks like the following:
    __mmap_lock_do_trace_*()
      preempt_disable()
      get_mm_memcg_path()
        cgroup_path()
          kernfs_path_from_node()
            spin_lock_irqsave() /* Scheduling while atomic! */

Link: https://lkml.kernel.org/r/20210604163506.2103900-1-nsaenzju@redhat.com


Fixes: 2b5067a8 ("mm: mmap_lock: add tracepoints around lock acquisition ")
Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzju@redhat.com>
Tested-by: default avatarAxel Rasmussen <axelrasmussen@google.com>
Reviewed-by: default avatarAxel Rasmussen <axelrasmussen@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 832b5072)
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: default avatarKefeng <Wang&lt;wangkefeng.wang@huawei.com>
Signed-off-by: default avatarZheng Zengkai <zhengzengkai@huawei.com>
parent 4936f620
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment