在 2024/3/22 17:02, David Hildenbrand 写道:
On 22.03.24 07:09, Jinjiang Tu wrote:
commit 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") inherits
MMF_VM_MERGE_ANY flag when a task calls execve(). Howerver, it doesn't
create the mm_slot, so ksmd will not try to scan this task.
To fix it, allocate and add the mm_slot to ksm_mm_head in
__bprm_mm_init()
when the mm has MMF_VM_MERGE_ANY flag.
Fixes: 3c6f33b7273a ("mm/ksm: support fork/exec for prctl")
Signed-off-by: Jinjiang Tu <tujinjiang@xxxxxxxxxx>
---
fs/exec.c | 10 ++++++++++
include/linux/ksm.h | 13 +++++++++++++
2 files changed, 23 insertions(+)
diff --git a/fs/exec.c b/fs/exec.c
index ff6f26671cfc..66202d016a0a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -67,6 +67,7 @@
#include <linux/time_namespace.h>
#include <linux/user_events.h>
#include <linux/rseq.h>
+#include <linux/ksm.h>
#include <linux/uaccess.h>
#include <asm/mmu_context.h>
@@ -267,6 +268,13 @@ static int __bprm_mm_init(struct linux_binprm
*bprm)
goto err_free;
}
+ /*
+ * Need to be called with mmap write lock
+ * held, to avoid race with ksmd.
+ */
+ if (ksm_execve(mm))
+ goto err_ksm;
+
But now, would we revert what insert_vm_struct() did?
We're freeing the VMA later, but we might have accounted memory.
What would be cleaner is doing the ksm_execve() before the
insert_vm_struct(), and then cleaning up in case insert_vm_struct()
failed.
In fact, ksm_execve() has been called before the insert_vm_struct() in
this patch.
