public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: TASK_WAKEKILL && /sbin/init (was: [PATCH 1/2] schedule: fix TASK_WAKEKILL vs SIGKILL race)
Date: Thu, 5 Jun 2008 09:48:44 -0600	[thread overview]
Message-ID: <20080605154844.GN3549@parisc-linux.org> (raw)
In-Reply-To: <20080605152316.GA257@tv-sign.ru>

On Thu, Jun 05, 2008 at 07:23:16PM +0400, Oleg Nesterov wrote:
> Sorry Matthew, I left this part unanswered because I didn't have the
> time yesterday...

That's OK, thanks for picking it up again.

> On 06/04, Matthew Wilcox wrote:
> >
> > On Wed, Jun 04, 2008 at 09:09:05PM +0400, Oleg Nesterov wrote:
> > > Note also that with or without this patch TASK_WAKEKILL is not exactly right
> > > wrt /sbin/init, but this is another issue.
> >
> > That's certainly an interesting conversation to have.
> 
> If lock_page_killable() fails because the task was killed by SIGKILL or
> another fatal signal, do_generic_file_read() returns -EIO.
> 
> This seems to be OK, because in fact the userspace won't see this error, the
> task will dequeue SIGKILL and exit.
> 
> However, /sbin/init is different, it will dequeue SIGKILL, ignore it, and be
> confused by this bogus -EIO. Please note that while this bug is not likely,
> it is _not_ theoretical. It does happen that user-space sends the unhandled
> fatal signals to init.

Have you actually tested this?  I thought it was handled by:

                /*
                 * Global init gets no signals it doesn't want.
                 */
                if (unlikely(signal->flags & SIGNAL_UNKILLABLE) &&
                    !signal_group_exit(signal))
                        continue;

in get_signal_to_deliver().

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-06-05 15:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 17:09 [PATCH 1/2] schedule: fix TASK_WAKEKILL vs SIGKILL race Oleg Nesterov
2008-06-04 17:33 ` Matthew Wilcox
2008-06-04 18:01   ` Oleg Nesterov
2008-06-04 19:52     ` Matthew Wilcox
2008-06-05 15:23       ` Oleg Nesterov
2008-06-04 18:51   ` Peter Zijlstra
2008-06-05 15:23   ` TASK_WAKEKILL && /sbin/init (was: [PATCH 1/2] schedule: fix TASK_WAKEKILL vs SIGKILL race) Oleg Nesterov
2008-06-05 15:48     ` Matthew Wilcox [this message]
2008-06-05 16:04       ` Oleg Nesterov
2008-06-05 16:16     ` 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=20080605154844.GN3549@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dmitry.adamushko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox