On Tue 25-08-15 23:37:27, Tetsuo Handa wrote:

Michal Hocko wrote:

quoted

quoted

quoted

The code would be easier then and the race window much smaller. If we
really needed to prevent from preemption then preempt_{enable,disable}
aournd the whole task_lock region + do_send_sig_info would be still
easier to follow than re-taking task_lock.

What's wrong with re-taking task_lock? It seems to me that re-taking
task_lock is more straightforward and easier to follow.

I dunno it looks more awkward to me. You have to re-check the victim->mm
after retaking the lock because situation might have changed while the
lock was dropped. If the mark_oom_victim & do_send_sig_info are in the
same preempt region then nothing like that is needed. But this is
probably a matter of taste. I find the above more readable but let's see
what others think.

Disabling preemption does not guarantee that the race window is small enough.

If we set TIF_MEMDIE before sending SIGKILL, long interrupts (an extreme
example is SysRq-t from keyboard which would last many seconds) can step
between. We will spend some percent (the worst case is 100 percent) of memory
reserves for allocations which are not needed for termination.

I wouldn't be worried about sysrq+t because that requires the
administrator. And IRQs shouldn't take too long normally. But I guess
you are right that this will be inherently less fragile long term. All
other callers of mark_oom_victim except for lowmem_scan are safe. Could
you update the lmk as well please?

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>