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

quoted text
> > 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).


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/