On Tue 25-08-15 23:37:27, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > > > 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>