From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pavel Emelyanov <xemul@openvz.org>,
"Serge E. Hallyn" <serue@us.ibm.com>,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] protect /sbin/init from unwanted signals more
Date: Thu, 20 Nov 2008 21:00:50 +0100 [thread overview]
Message-ID: <20081120200050.GA24467@redhat.com> (raw)
In-Reply-To: <m13ahm9slb.fsf@frodo.ebiederm.org>
On 11/20, Eric W. Biederman wrote:
>
> Oleg Nesterov <oleg@redhat.com> writes:
>
> > On 11/19, Eric W. Biederman wrote:
> >>
> >> Roland McGrath <roland@redhat.com> writes:
> >>
> >> > With that, I wonder if the SIGNAL_UNKILLABLE checks in get_signal_to_deliver
> >> > and complete_signal are needed at all. Hmm, I guess we do because this
> >> > doesn't affect blocked signals, so they might be unblocked and delivered.
> >> > (Note that since it doesn't affect blocked signals, this doesn't break init
> >> > using sigwait if it wanted to.)
> >>
> >> Ah. That answers the question I had bouncing in the back of my head.
> >
> > Even worse. The signal can be dequeued even before unblocked by the target.
> > complete_signal() can "redirect" this signal to another thread wich doesn't
> > block it.
>
> The signal handlers should still be the same.
Yes sure. and the handler can be SIG_DFL.
In short, if we have any reason (we do have) to check sig_kernel_ignore()
in get_signal_to_deliver(), then we have the same reason to check
SIGNAL_UNKILLABLE too.
> >> Which reminds me. I need to retest, but I had a case where I had a trivial
> > init
> >> that set all signal handlers to SIG_IGN so it could ignore SIGCHLD. And not
> >> all of it's children were getting reaped automagically. Do we have a bug in
> >> the reparenting/reaping logic?
> >
> > Ah... I thought this was already fixed... shouldn't reparent_thread()
> > check task_detached() after do_notify() ? like ptrace_exit() does.
>
> Like I said I need to retest. I was on a 2.6.26 fedora kernel base.
> So if there have been recent bug fixes things may have changed.
I bet the bug is still here.
The fix should be simple, except we can't trust ptrace_reparented().
I'll send the patch, but first I'd like to do another one. Since
I stopped my attempts to understand the orphaned pgrps a long
ago, I hope you can review ;)
Oleg.
next prev parent reply other threads:[~2008-11-20 19:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 17:59 [PATCH 1/2] protect /sbin/init from unwanted signals more Oleg Nesterov
2008-11-19 18:51 ` Roland McGrath
2008-11-20 2:00 ` Eric W. Biederman
2008-11-20 3:04 ` Roland McGrath
2008-11-20 14:52 ` Oleg Nesterov
2008-11-20 18:10 ` Eric W. Biederman
2008-11-20 20:00 ` Oleg Nesterov [this message]
2008-11-20 20:28 ` [PATCH] processes: reparent_thread: don't call kill_orphaned_pgrp() if task_detached() Oleg Nesterov
2008-11-26 20:21 ` Roland McGrath
2008-12-04 17:14 ` Oleg Nesterov
2008-12-04 1:06 ` Roland McGrath
2008-11-20 15:20 ` [PATCH 1/2] protect /sbin/init from unwanted signals more Oleg Nesterov
2008-11-20 21:24 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081120200050.GA24467@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=serue@us.ibm.com \
--cc=sukadev@linux.vnet.ibm.com \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.