Re: [PATCH 13/12] ksm: fix munlock during exit_mmap deadlock

From: Izik Eidus
Date: Wed Aug 26 2009 - 16:47:55 EST

Hugh Dickins wrote:
On Wed, 26 Aug 2009, Andrea Arcangeli wrote:
All is left to address is to teach page_alloc.c that the mm is going
away in a second patch. That might also help when it's aio triggering
gup page allocations or other kernel threads with use_mm just like ksm
and the oom killer selected those "mm" for release.

Having ksm using use_mm before triggering the handle_mm_fault (so
tsk->mm points to the mm of the task) and adding a MMF_MEMDIE to
mm->flags checked by page_alloc would work just fine and should solve
the double task killed... but then I'm unsure.. this is just the first
idea I had.

Yes, I began to have thoughts along those lines too as I was writing
my reply. It is a different angle on the problem, I hadn't looked at
it that way before, and it does seem worth pursuing. MMF_MEMDIE, yes,
that might be useful. But KSM_RUN_UNMERGE wouldn't be able to use_mm
since it's coming from a normal user process - perhaps it should be a
kill-me-first like swapoff via PF_SWAPOFF.

About the KSM case:
The oom should work on problomatic processes, such that allocate big amount of memory.
But then as we now plane it to be, what might be a just fine application that used ksm and told it to stop merge it pages, might be what considered "bad application that need to be killed"

Is this what we really want?

But before getting into this, why is it so important to break the ksm pages when madvise(UNMERGEABLE) get called?

When thinking about it, lets say I want to use ksm to scan 2 applications and merged their STATIC identical data, and then i want to stop scanning them after i know ksm merged the pages, as soon as i will try to unregister this 2 applications ksm will unmerge the pages, so we dont allow such thing for the user (we can tell him ofcurse for such case to use normal way of sharing, so this isnt a really strong case for this)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at