From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Michael Kerrisk <mtk-lkml@gmx.net>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] fix de_thread() vs do_coredump() deadlock
Date: Tue, 11 Apr 2006 02:49:37 -0700 (PDT) [thread overview]
Message-ID: <20060411094937.3D4541809BB@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of Tuesday, 11 April 2006 17:13:43 +0400 <20060411131343.GA113@oleg>
> I still think we are ok with no ptrace. If that (non-coredump) signal was
> delivered before de_thread sets SIGNAL_GROUP_EXIT, then this flag is set
> by __group_complete_signal(), so de_thread return -EAGAIN. If de_thread()
> wins, the signal will be dequeued later from ->shared_pending.
There is no guarantee that __group_complete_signal gets to that code path
when the signal is generated. There may be no thread that doesn't have it
blocked nor is already descheduled with pending signals. Then some thread
gets scheduled, or changes it signal mask, and then gets into
get_signal_to_deliver and takes the siglock either before an exec'ing
thread gets the lock, or while the exec'ing thread releases it to wait.
When the dequeuer thread releases the siglock, we have the race window.
(There is another similar case if the signal was handled at generation time
and the handler is reset to SIG_DFL later in a race with another thread
dequeuing the signal and a third doing an exec.)
Thanks,
Roland
prev parent reply other threads:[~2006-04-11 9:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-13 16:50 Oleg Nesterov
2006-04-10 1:36 ` Roland McGrath
2006-04-10 17:43 ` Oleg Nesterov
2006-04-11 7:27 ` Roland McGrath
2006-04-11 11:47 ` Oleg Nesterov
2006-04-11 9:10 ` Roland McGrath
2006-04-11 12:03 ` Oleg Nesterov
2006-04-10 21:40 ` Oleg Nesterov
2006-04-11 8:01 ` Roland McGrath
2006-04-11 13:13 ` Oleg Nesterov
2006-04-11 9:49 ` Roland McGrath [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=20060411094937.3D4541809BB@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtk-lkml@gmx.net \
--cc=oleg@tv-sign.ru \
--cc=torvalds@osdl.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
all inboxes | Powered by JetHome®