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

[Andrea Arcangeli]

On Wed, Aug 26, 2009 at 11:54:36PM +0300, Izik Eidus wrote:
> But before getting into this, why is it so important to break the ksm 
> pages when madvise(UNMERGEABLE) get called?

The moment ksm pages are swappable, there's no apparent reason why
anybody should ask the kernel to break any ksm page if the application
themselfs aren't writing to them in the first place (triggering
copy-on-write in app context which already handles TIF_MEMDIE just
fine).

In oom deadlock terms madvise(UNMERGEABLE) is the only place that is
100% fine at breaking KSM pages, because it runs with right tsk->mm
and page allocation will notice TIF_MEMDIE set on tsk.

If we remove "echo 2" only remaining "unsafe" spot is the break_cow in
kksmd context when memcmp fails and similar during the scan.

> 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)

For the app it will be tricky to know when the pages are merged
though, right now it could only wait a "while"... so I don't really
see madvise(UNMERGEABLE) as useful regardless how we implement
it... but then this goes beyond the scope of this bug because as said
madvise(UNMERGEABLE) is the only place that breaks ksm pages as safe
as regular write fault in oom context because of it running in the
process context (not echo 2 or kksmd context).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/