linux-kernel - Re: [PATCH] copy over oom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090715104920.39A4.A69D9226@jp.fujitsu.com>
Date:	Wed, 15 Jul 2009 11:01:59 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Paul Menage <menage@...gle.com>
Cc:	kosaki.motohiro@...fujitsu.com, Rik van Riel <riel@...hat.com>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	rientjes@...gle.com, mel@....ul.ie, npiggin@...e.de
Subject: Re: [PATCH] copy over oom_adj value at fork time

> On Tue, Jul 14, 2009 at 6:05 PM, Rik van Riel<riel@...hat.com> wrote:
> > After moving the oom_adj value from the task struct to the
> > mm_struct, the oom_adj value was no longer properly inherited
> > by child processes.
> >
> > Copying over the oom_adj value at fork time fixes that bug.
> >
> > Signed-off-by: Rik van Riel <riel@...hat.com>
> > Reported-by: Paul Menage <manage@...gle.com>
> > ---
> > Paul, does this fix your bug?
> 
> It fixes that specific problem. (Although the patch title should
> probably be "copy over oom_adj value at execve time")

AFAIK mm_init() is called from both fork() and execve().


> But ironically, with this fix applied the main part of the original
> change (force all threads in a process to share a single oom_adj
> value) will start to break my code - it's no longer possible to have
> the regular threads in a process be oom-immune, then vfork() and set a
> non-disabled oom_adj in the child, since this will set it for the
> entire process. (Our job scheduler does something like this, in order
> to have the launcher be OOM immune and the running jobs be at various
> oom_adj levels depending on their priority).

Fair point.
Nobody want per-thread oom_adj, but your vfork() issue seems real regression.

David, can we make more clever implementation?

> 
> It's probably something that I can work around, but it seems like the
> kind of API change that could break unsuspecting users.
> 
> Paul
> 
> >
> >  kernel/fork.c |    1 +
> >  1 file changed, 1 insertion(+)
> >
> > Index: mmotm/kernel/fork.c
> > ===================================================================
> > --- mmotm.orig/kernel/fork.c    2009-07-14 20:58:01.000000000 -0400
> > +++ mmotm/kernel/fork.c 2009-07-14 21:00:40.000000000 -0400
> > @@ -435,6 +435,7 @@ static struct mm_struct * mm_init(struct
> >        init_rwsem(&mm->mmap_sem);
> >        INIT_LIST_HEAD(&mm->mmlist);
> >        mm->flags = (current->mm) ? current->mm->flags : default_dump_filter;
> > +       mm->oom_adj = current->mm->oom_adj;
> >        mm->core_state = NULL;
> >        mm->nr_ptes = 0;
> >        set_mm_counter(mm, file_rss, 0);
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/