mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Daniel Lezcano <dlezcano@fr.ibm.com>,
	Sukadev Bhattiprolu <sukadev@us.ibm.com>,
	Linux Containers <containers@lists.osdl.org>,
	roland@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] signals: SEND_SIG_NOINFO should be considered as SI_FROMUSER()
Date: Mon, 5 Oct 2009 10:58:55 -0700	[thread overview]
Message-ID: <20091005175855.GB30442@us.ibm.com> (raw)
In-Reply-To: <20091004021918.GB21006@redhat.com>

Oleg Nesterov [oleg@redhat.com] wrote:
| No changes in compiled code. The patch adds the new helper, si_fromuser()
| and changes check_kill_permission() to use this helper.
| 
| The real effect of this patch is that from now we "officially" consider
| SEND_SIG_NOINFO signal as "from user-space" signals. This is already true
| if we look at the code which uses SEND_SIG_NOINFO, except __send_signal()
| has another opinion - see the next patch.
| 
| The naming of these special SEND_SIG_XXX siginfo's is really bad imho.

I agree :-)

| >From __send_signal()'s pov they mean
| 
| 	SEND_SIG_NOINFO		from user

Just to complicate further, all 'SEND_SIG_NOINFO' signals are from user,
but not all 'from user' signals are SEND_SIG_NOINFO.

| 	SEND_SIG_PRIV		from kernel

SEND_SIG_PRIV also means there is no real info, just that sender is
privileged.

| 	SEND_SIG_FORCED		no info

Are 'forced' signals considered 'from kernel' too ?

Separate from this patch, but would be good if we could fix the naming.

| 
| Signed-off-by: Oleg Nesterov <oleg@redhat.com>
| ---
| 
|  include/linux/sched.h |    5 -----
|  kernel/signal.c       |   16 +++++++++++++---
|  2 files changed, 13 insertions(+), 8 deletions(-)
| 
| --- TTT_32/include/linux/sched.h~FU_1_HELPER	2009-09-24 21:38:54.000000000 +0200
| +++ TTT_32/include/linux/sched.h	2009-10-04 02:21:49.000000000 +0200
| @@ -2081,11 +2081,6 @@ static inline int kill_cad_pid(int sig, 
|  #define SEND_SIG_PRIV	((struct siginfo *) 1)
|  #define SEND_SIG_FORCED	((struct siginfo *) 2)
| 
| -static inline int is_si_special(const struct siginfo *info)
| -{
| -	return info <= SEND_SIG_FORCED;
| -}
| -
|  /* True if we are on the alternate signal stack.  */
| 
|  static inline int on_sig_stack(unsigned long sp)
| --- TTT_32/kernel/signal.c~FU_1_HELPER	2009-09-24 21:38:54.000000000 +0200
| +++ TTT_32/kernel/signal.c	2009-10-04 02:21:55.000000000 +0200
| @@ -584,6 +584,17 @@ static int rm_from_queue(unsigned long m
|  	return 1;
|  }
| 
| +static inline int is_si_special(const struct siginfo *info)
| +{
| +	return info <= SEND_SIG_FORCED;
| +}
| +
| +static inline bool si_fromuser(const struct siginfo *info)
| +{
| +	return info == SEND_SIG_NOINFO ||
| +		(!is_si_special(info) && SI_FROMUSER(info));
| +}
| +

This change makes sense, but can we even drop the SEND_SIG_NOINFO
altogether and simply check for NULL:

	return (!info || (is_si_special(info)) && SI_FROMUSER(info))

Sukadev

  parent reply	other threads:[~2009-10-05 17:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4AC608BE.9020805@fr.ibm.com>
2009-10-03 17:10 ` pidns : PR_SET_PDEATHSIG + SIGKILL regression Sukadev Bhattiprolu
2009-10-04  2:18   ` [PATCH 0/4] Was: " Oleg Nesterov
2009-10-04  2:19     ` [PATCH 1/4] signals: SEND_SIG_NOINFO should be considered as SI_FROMUSER() Oleg Nesterov
2009-10-04  2:25       ` Oleg Nesterov
2009-10-05 17:58       ` Sukadev Bhattiprolu [this message]
2009-10-05 18:39         ` Oleg Nesterov
2009-10-06  0:09       ` Sukadev Bhattiprolu
2009-10-06  7:31       ` Roland McGrath
2009-10-06 13:37         ` Oleg Nesterov
2009-10-06 17:57           ` Roland McGrath
2009-10-07 11:30             ` Oleg Nesterov
2009-10-08  1:57               ` Roland McGrath
2009-10-04  2:19     ` [PATCH 2/4] signals: send_signal: use si_fromuser() to detect from_ancestor_ns Oleg Nesterov
2009-10-05 18:12       ` Sukadev Bhattiprolu
2009-10-05 18:25         ` Oleg Nesterov
2009-10-05 19:37           ` Sukadev Bhattiprolu
2009-10-05 19:44             ` Oleg Nesterov
2009-10-05 19:55               ` Oleg Nesterov
2009-10-06  0:06               ` Sukadev Bhattiprolu
2009-10-06  1:09                 ` Oleg Nesterov
2009-10-06  2:34                   ` Sukadev Bhattiprolu
2009-10-06 13:18                     ` Oleg Nesterov
2009-10-06 18:01                       ` Roland McGrath
2009-10-06  0:16       ` Sukadev Bhattiprolu
2009-10-04  2:20     ` [PATCH 3/4] signals: cosmetic, collect_signal: use SI_USER Oleg Nesterov
2009-10-05 18:03       ` Sukadev Bhattiprolu
2009-10-04  2:20     ` [PATCH 4/4] signals: kill force_sig_specific() Oleg Nesterov
2009-10-05 18:04       ` Sukadev Bhattiprolu

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=20091005175855.GB30442@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=dlezcano@fr.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=sukadev@us.ibm.com \
    /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