Hi Lorenzo, I tested the exact v2 from this Message-ID on its stated base with an x86_64 KASAN kernel. The supplied memfd_secret selftest passed 6/6 in three boots, and my accounting-boundary suite also passed in three boots. I saw no patch-attributable KASAN report, warning, Oops, or panic.
A v1/v2 differential also confirms that v2 fixes the CAP_IPC_LOCK creator delegation issue Mike identified: v1: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=2 v2: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=1 I have one policy question before adding Tested-by. With a one-page soft and hard RLIMIT_MEMLOCK, a non-root task whose only effective and permitted capability was CAP_IPC_LOCK produced this on v2: CAP_ONLY uid=2002 cap_ipc_lock=1 mlock_two_pages=1 faulted_pages=1 raise_hard_rc=-1 raise_hard_errno=1 Thus ordinary mlock() of two pages succeeded, while only one secretmem page could be faulted. Raising the hard limit failed with EPERM because that requires CAP_SYS_RESOURCE. Is this divergence from ordinary mlock() the intended consequence of removing the CAP_IPC_LOCK exemption for secretmem? I saw the planned selftest split and cleanup in the follow-up discussion. I will retest the revised patch before adding Tested-by. Thanks, Daehyeon
