aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/util/scripting-engines/trace-event-python.c
diff options
context:
space:
mode:
authorMiaohe Lin <[email protected]>2022-03-22 08:09:18 +0000
committerEric W. Biederman <[email protected]>2022-03-23 16:16:59 +0000
commite97824ff663ce3509fe040431c713182c2f058b1 (patch)
treee034a0a6eddcd8b5654efbe3f744949e73e2ff47 /tools/perf/util/scripting-engines/trace-event-python.c
parentLinux 5.17-rc7 (diff)
downloadkernel-e97824ff663ce3509fe040431c713182c2f058b1.tar.gz
kernel-e97824ff663ce3509fe040431c713182c2f058b1.zip
mm/mlock: fix two bugs in user_shm_lock()
user_shm_lock forgets to set allowed to 0 when get_ucounts fails. So the later user_shm_unlock might do the extra dec_rlimit_ucounts. Also in the RLIM_INFINITY case, user_shm_lock will success regardless of the value of memlock where memblock == LONG_MAX && !capable(CAP_IPC_LOCK) should fail. Fix all of these by changing the code to leave lock_limit at ULONG_MAX aka RLIM_INFINITY, leave "allowed" initialized to 0 and remove the special case of RLIM_INFINITY as nothing can be greater than ULONG_MAX. Credit goes to Eric W. Biederman for proposing simplifying the code and thus catching the later bug. Fixes: d7c9e99aee48 ("Reimplement RLIMIT_MEMLOCK on top of ucounts") Signed-off-by: Miaohe Lin <[email protected]> Cc: [email protected] v1: https://lkml.kernel.org/r/[email protected] v2: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric W. Biederman <[email protected]>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions