Re: [RFC] is_global_init() called on global init sub-thread

[Richard Guy Briggs]

On 16/01/01, Sergey Senozhatsky wrote:
> On (12/31/15 19:18), Serge E. Hallyn wrote:
> > On Fri, Jan 01, 2016 at 10:10:35AM +0900, Sergey Senozhatsky wrote:
> > > On (12/31/15 19:08), Serge E. Hallyn wrote:
> > > > > re-upping https://www.redhat.com/archives/linux-audit/2013-December/msg00086.html
> > > > > 
> > > > > Oleg Nesterov wrote:
> > > > > 
> > > > > :Because is_global_init() is only true for the main thread of /sbin/init.
> > > > > :
> > > > > :Just look at oom_unkillable_task(). It tries to not kill init. But, say,
> > > > > :select_bad_process() can happily find a sub-thread of is_global_init()
> > > > > :and still kill it.
> > > > > 
> > > > > this is still the case, isn't it? at least in some -stable kernels.
> > > > > is there (or was there) any reason this change has never been committed?
> > > > > (I'm particularly interested in is_global_init()).
> > > > 
> > > > ...  seems like it makes sense.  Can you remind us which init you're having
> > > > to deal with?
> > > > 
> > > 
> > > systemd
> > > 
> > > 	-ss
> > 
> > Well it makes sense to me.  The question is whether we are protecting the
> > thing running as init, or the 'physical' thread with pid 1.  I think it's
> > the former, so let's push on this.  Please resend the patch with a proper
> > signed-off-by, and feel free to add
> 
> thanks. a bit puzzled, would reported-by Oleg and suggested-by Richard
> be appropriate? (no objections if Oleg or Richard will submit it).

This works for me.  I have more patches related to it, but I'll
re-submit them later.

> > Acked-by: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>
> 
> 	-ss

- RGB

--
Richard Guy Briggs <rbriggs@xxxxxxxxxx>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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/