[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160627103625.GF31799@dhcp22.suse.cz>
Date: Mon, 27 Jun 2016 12:36:25 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...capital.net>,
Andy Lutomirski <luto@...nel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Nadav Amit <nadav.amit@...il.com>,
Kees Cook <keescook@...omium.org>,
Brian Gerst <brgerst@...il.com>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Jann Horn <jann@...jh.net>,
Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86,
core)
On Fri 24-06-16 22:22:55, Oleg Nesterov wrote:
> On 06/24, Michal Hocko wrote:
> >
> > On Fri 24-06-16 16:05:58, Michal Hocko wrote:
> > > On Thu 23-06-16 20:52:21, Oleg Nesterov wrote:
> > > >
> > > > But I agree, this is fixable (and in fact I still hope TIF_MEMDIE will die,
> > > > at least in its current form).
> > >
> > > We can move the flag to the task_struct.
>
> Well, I actually meant that to me its usage doesn't look really
> right and we need to change this logic. But this is off-topic.
>
> > Here is the patch.
>
> Can't comment, but note that it was decided to move ti->flags into
> task_struct, so the patch is "off-topic" too ;)
OK, my original understanding was that we want to get rid of all the
current thread flags.
>
> > @@ -1856,6 +1856,8 @@ struct task_struct {
> > unsigned long task_state_change;
> > #endif
> > int pagefault_disabled;
> > + /* oom victim - give it access to memory reserves */
> > + atomic_t memdie;
>
> Yet another oom member. And these atomic_add_unless's look a bit
> strange, it seems that you could add "bool memdie" and use xchg()
> with the same effect?
That would work as well of course.
Thanks!
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists