public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
	ebiederm@xmission.com, mingo@elte.hu,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] coredump: zap_threads() must skip kernel threads
Date: Wed, 4 Jun 2008 00:57:43 -0700	[thread overview]
Message-ID: <20080604005743.29aed3a5.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080603214959.0208826FC96@magilla.localdomain>

On Tue,  3 Jun 2008 14:49:58 -0700 (PDT) Roland McGrath <roland@redhat.com> wrote:

> > This is a bugfix, yes?
> > 
> > How does it get triggered?
> 
> Yes, I think it fixes a bug.  The trigger would be an aio request doing
> some work (inside aio_kick_handler) simultaneous with some thread in the
> requester's mm doing a core dump (inside zap_threads).
> 
> > Do you think the bug is sufficiently serious to fix it in 2.6.26?  In
> > 2.6.25.x?  If so, it would be better if this patch were not dependent
> > upon the preceding ones, which do not appear to be 2.6.26 or -stable
> > material.
> 
> It has probably never been seen for real, but might be possible to produce
> with an exploit that works hard to hit the race.  I'm not sure off hand
> what all the bad effects would be, mainly those of SIGKILL'ing the
> workqueue thread (keventd I guess).  The core-dumping threads will be stuck
> in uninterruptible waits and never be killable.
> 
> Oleg's cleanups make the fix much nicer because there is an easy persistent
> flag to check without races.  Probably the most isolated fix for this is
> something like the bit below (wholly untested).  This is hairy enough that
> I think Oleg's 1/3 + 2/3 would be preferable even for -stable.

OK, thanks.

I'll tentatively queue these three for 2.6.26 and will leave 2.6.25.x
alone.  The bug seems sufficiently obscure?

(This required a bit of massaging of
coredump-zap_threads-must-skip-kernel-threads.patch in fs/exec.c due, I
assume, to dependencies on other things which we have queued for
2.6.27).



      reply	other threads:[~2008-06-04  7:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-01 15:30 [PATCH 3/3] coredump: zap_threads() must skip kernel threads Oleg Nesterov
2008-06-03 21:15 ` Andrew Morton
2008-06-03 21:49   ` Roland McGrath
2008-06-04  7:57     ` Andrew Morton [this message]

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=20080604005743.29aed3a5.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox