From: Tejun Heo <tj@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.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: Wed, 13 Apr 2011 03:33:14 +0900 [thread overview]
Message-ID: <20110412183314.GA16342@mtj.dyndns.org> (raw)
In-Reply-To: <20110411172137.GE32469@redhat.com>
Hello, Oleg.
On Mon, Apr 11, 2011 at 07:21:37PM +0200, Oleg Nesterov wrote:
> --- 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
> @@ -126,10 +126,14 @@ _SIG_SET_BINOP(sigandsets, _sig_and)
> #define _sig_nand(x,y) ((x) & ~(y))
> _SIG_SET_BINOP(signandsets, _sig_nand)
>
> +#define _sig_nor(x,y) ((x) | ~(y))
> +_SIG_SET_BINOP(signorsets, _sig_nor)
> +
> #undef _SIG_SET_BINOP
> #undef _sig_or
> #undef _sig_and
> #undef _sig_nand
> +#undef _sig_nor
I'm confused. Isn't nand ^(A&B) and nor ^(A|B)?
> #define _SIG_SET_OP(name, op) \
> static inline void name(sigset_t *set) \
> --- sigprocmask/kernel/signal.c~4_sigprocmask_retarget 2011-04-10 21:57:42.000000000 +0200
> +++ sigprocmask/kernel/signal.c 2011-04-11 18:02:22.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);
I think it would be much easier to follow the logic if
retarget_shared_pending() took target mask instead of blocked
(ie. negation of blocked) and there were more comments. Combined with
the confusing definition of nor, I had to spend quite some time trying
to wrap my head around it but the logic here isn't all that complex
and it should have been easier.
Other than that, I agree with the proposed changes, but I think we
really need to do retargeting (and the initial targeting too) more
efficiently as you noted in the earlier commit message. Altering
signal mask is far hotter path than actual signal delivery. Although
the thread walking code wouldn't get activated unless signal is
already pending, I still think we better avoid looping threads
unnecessarily.
Thanks.
--
tejun
next prev parent reply other threads:[~2011-04-12 18:33 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
2011-04-12 18:33 ` Tejun Heo [this message]
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=20110412183314.GA16342@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=nyoushchenko@mvista.com \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--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