All of lore.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 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.