[PATCH] inline __fatal_signal_pending

[PATCH] inline __fatal_signal_pending

[Roland McGrath]

__fatal_signal_pending inlines to one instruction on x86, probably two
instructions on other machines.  It takes two longer x86 instructions
just to call it and test its return value, not to mention the function
itself.

On my random x86_64 config, this saved 70 bytes of text (59 of those
being __fatal_signal_pending itself).

Signed-off-by: Roland McGrath <roland@redhat.com>
---
 include/linux/sched.h |    5 ++++-
 kernel/signal.c       |    6 ------
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3ab08e4..fabe715 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2250,7 +2250,10 @@ static inline int signal_pending(struct task_struct *p)
 	return unlikely(test_tsk_thread_flag(p,TIF_SIGPENDING));
 }
 
-extern int __fatal_signal_pending(struct task_struct *p);
+static inline int __fatal_signal_pending(struct task_struct *p)
+{
+	return unlikely(sigismember(&p->pending.signal, SIGKILL));
+}
 
 static inline int fatal_signal_pending(struct task_struct *p)
 {
diff --git a/kernel/signal.c b/kernel/signal.c
index 64c5dee..d441e3d 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1036,12 +1036,6 @@ void zap_other_threads(struct task_struct *p)
 	}
 }
 
-int __fatal_signal_pending(struct task_struct *tsk)
-{
-	return sigismember(&tsk->pending.signal, SIGKILL);
-}
-EXPORT_SYMBOL(__fatal_signal_pending);
-
 struct sighand_struct *lock_task_sighand(struct task_struct *tsk, unsigned long *flags)
 {
 	struct sighand_struct *sighand;

Re: [PATCH] inline __fatal_signal_pending

[Oleg Nesterov]

On 08/14, Roland McGrath wrote:
>
> __fatal_signal_pending inlines to one instruction on x86, probably two
> instructions on other machines.  It takes two longer x86 instructions
> just to call it and test its return value, not to mention the function
> itself.
>
> On my random x86_64 config, this saved 70 bytes of text (59 of those
> being __fatal_signal_pending itself).

Agreed.


In fact, I think we do not need 2 helpers. I mean, fatal_signal_pending()
does not need the signal_pending() check, we can just rename
__fatal_signal_pending() to fatal_signal_pending(). Should be another
change of course.

Oleg.

> Signed-off-by: Roland McGrath <roland@redhat.com>
> ---
>  include/linux/sched.h |    5 ++++-
>  kernel/signal.c       |    6 ------
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 3ab08e4..fabe715 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2250,7 +2250,10 @@ static inline int signal_pending(struct task_struct *p)
>  	return unlikely(test_tsk_thread_flag(p,TIF_SIGPENDING));
>  }
>  
> -extern int __fatal_signal_pending(struct task_struct *p);
> +static inline int __fatal_signal_pending(struct task_struct *p)
> +{
> +	return unlikely(sigismember(&p->pending.signal, SIGKILL));
> +}
>  
>  static inline int fatal_signal_pending(struct task_struct *p)
>  {
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 64c5dee..d441e3d 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1036,12 +1036,6 @@ void zap_other_threads(struct task_struct *p)
>  	}
>  }
>  
> -int __fatal_signal_pending(struct task_struct *tsk)
> -{
> -	return sigismember(&tsk->pending.signal, SIGKILL);
> -}
> -EXPORT_SYMBOL(__fatal_signal_pending);
> -
>  struct sighand_struct *lock_task_sighand(struct task_struct *tsk, unsigned long *flags)
>  {
>  	struct sighand_struct *sighand;

Re: [PATCH] inline __fatal_signal_pending

[Roland McGrath]

> In fact, I think we do not need 2 helpers. I mean, fatal_signal_pending()
> does not need the signal_pending() check, we can just rename
> __fatal_signal_pending() to fatal_signal_pending(). Should be another
> change of course.

Right, I thought of that too.  I wasn't entirely sure that signal_pending()
vs test_tsk_thread_flag() doesn't have some important barrier-like ordering
effect that just the unlocked sigismember() check wouldn't have.  But if not,
fatal_signal_pending() indeed really only needs to be that one instruction.


Thanks,
Roland