From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Nikita V. Youshchenko" <nyoushchenko@mvista.com>,
Matt Fleming <matt@console-pimps.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] signal: sigprocmask() should do retarget_shared_pending()
Date: Thu, 14 Apr 2011 21:36:27 +0200 [thread overview]
Message-ID: <20110414193627.GA25828@redhat.com> (raw)
In-Reply-To: <BANLkTin6t7fSuyxw4Nipj1DGy8w9XE3+ug@mail.gmail.com>
On 04/12, Linus Torvalds wrote:
>
> On Mon, Apr 11, 2011 at 10:21 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > I am not sure this is bug, but at least this looks strange imho. T1 should
> > not sleep forever, there is a signal which should wake it up.
>
> Hmm. I worry about the overhead of this, and I'm not 100% convinced we need it.
Indeed. That is why RFC.
I simply do not know if this is buggy or not. I reported this oddity a long
ago, but I can't recall the result of discussion (or it was ignored ?).
And I do not like the fact we need a lot of changes, albeit trivial. We should
convert almost every code which changes current->blocked. Otoh, perhaps this
makes sense by itself...
> > --- sigprocmask/include/linux/signal.h~4_sigprocmask_retarget 2011-04-06 21:33:50.000000000 +0200
> > +++ sigprocmask/include/linux/signal.h 2011-04-11 18:16:51.000000000 +0200
> > @@ -2131,6 +2131,11 @@ int sigprocmask(int how, sigset_t *set,
> > }
> >
> > spin_lock_irq(&tsk->sighand->siglock);
> > + if (signal_pending(tsk) && !thread_group_empty(tsk)) {
> > + sigset_t not_newblocked;
> > + signorsets(¬_newblocked, ¤t->blocked, &newset);
> > + retarget_shared_pending(tsk, ¬_newblocked);
> > + }
> > tsk->blocked = newset;
> > recalc_sigpending();
> > spin_unlock_irq(&tsk->sighand->siglock);
>
> I absolutely detest how you made "sigprocmask()" the main interface to
> do this all, and then add new callers.
>
> It's a horrid interface with that crazy "how" argument, and comes out
> of the user-space system call interface. If we make kernel users do
> this, especially critical ones like the signal handling code, please
> just extract out just the actual "set new signal mask" part.
>
> So please just introduce a "sig_set_blocked()" or something, without
> the crazy "switch (how)" crud, and make sigprocmask() and everybody
> else use _that_ instead.
You know, initially I did exactly this. set_current_blocked() was its
name. But then I noticed that handle_signal() can naturally use SIG_BLOCK,
sigtimedwait() could use SIG_UNBLOCK...
Nevermind,
> That would make me much happier about the patch series, I suspect.
OK. I'll redo and resend.
Oleg.
next prev parent reply other threads:[~2011-04-14 19:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 17:19 [RFC PATCH 0/6] signal: sigprocmask fixes Oleg Nesterov
2011-04-11 17:20 ` [PATCH 1/6] signal: introduce retarget_shared_pending() Oleg Nesterov
2011-04-12 11:39 ` Matt Fleming
2011-04-11 17:20 ` [PATCH 2/6] signal: retarget_shared_pending: consider shared/unblocked signals only Oleg Nesterov
2011-04-12 11:40 ` Matt Fleming
2011-04-12 19:53 ` Oleg Nesterov
2011-04-11 17:21 ` [PATCH 3/6] signal: sigprocmask: narrow the scope of ->sigloc Oleg Nesterov
2011-04-12 11:38 ` Matt Fleming
2011-04-11 17:21 ` [PATCH 4/6] signal: sigprocmask() should do retarget_shared_pending() Oleg Nesterov
2011-04-12 12:07 ` Matt Fleming
2011-04-12 14:32 ` Linus Torvalds
2011-04-14 19:36 ` Oleg Nesterov [this message]
2011-04-12 18:33 ` Tejun Heo
2011-04-14 20:10 ` Oleg Nesterov
2011-04-14 20:33 ` Linus Torvalds
2011-04-11 17:22 ` [PATCH 5/6] x86: signal: handle_signal() should use sigprocmask() Oleg Nesterov
2011-04-12 12:15 ` Matt Fleming
2011-04-11 17:22 ` [PATCH 6/6] x86: signal: sys_rt_sigreturn() " Oleg Nesterov
2011-04-12 12:17 ` Matt Fleming
2011-04-14 20:15 ` 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=20110414193627.GA25828@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=nyoushchenko@mvista.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--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
Powered by JetHome