Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1690296 > unrolled thread

[PATCH v2 0/7] signal: Fix sending signals with siginfo

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 0/7] signal: Fix sending signals with siginfo ebiederm@xmission.com (Eric W. Biederman) - 2017-07-18 16:20 +0200
    [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes "Eric W. Biederman" <ebiederm@xmission.com> - 2017-07-18 16:20 +0200
      Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes Oleg Nesterov <oleg@redhat.com> - 2017-07-20 18:20 +0200
        Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes ebiederm@xmission.com (Eric W. Biederman) - 2017-07-21 04:50 +0200
    [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE "Eric W. Biederman" <ebiederm@xmission.com> - 2017-07-18 16:20 +0200
      Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with  SIGFPE "Maciej W. Rozycki" <macro@imgtec.com> - 2017-08-07 18:20 +0200
        Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-07 19:50 +0200
          Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with  SIGFPE Ralf Baechle <ralf@linux-mips.org> - 2017-08-07 22:00 +0200
        Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE ebiederm@xmission.com (Eric W. Biederman) - 2017-08-08 17:40 +0200
          Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with  SIGFPE "Maciej W. Rozycki" <macro@imgtec.com> - 2017-08-09 01:20 +0200
    [PATCH 3/7] signal/sparc: Document a conflict with SI_USER with SIGFPE "Eric W. Biederman" <ebiederm@xmission.com> - 2017-07-18 16:20 +0200
    [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP "Eric W. Biederman" <ebiederm@xmission.com> - 2017-07-18 16:20 +0200
      Re: [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for  SIGTRAP Richard Henderson <rth@twiddle.net> - 2017-07-18 20:30 +0200
    Re: [PATCH 7/7] signal: Remove kernel interal si_code magic Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-18 19:00 +0200
      Re: [PATCH 7/7] signal: Remove kernel interal si_code magic ebiederm@xmission.com (Eric W. Biederman) - 2017-07-18 19:40 +0200
        Simplfying copy_siginfo_to_user ebiederm@xmission.com (Eric W. Biederman) - 2017-07-22 22:40 +0200
          Re: Simplfying copy_siginfo_to_user Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-24 19:50 +0200
            Re: Simplfying copy_siginfo_to_user ebiederm@xmission.com (Eric W. Biederman) - 2017-07-24 21:20 +0200
            Re: Simplfying copy_siginfo_to_user Al Viro <viro@ZenIV.linux.org.uk> - 2017-07-25 03:40 +0200
              Re: Simplfying copy_siginfo_to_user ebiederm@xmission.com (Eric W. Biederman) - 2017-07-31 18:50 +0200

#1690296 — [PATCH v2 0/7] signal: Fix sending signals with siginfo

Today sending a signal with rt_sigqueueinfo and receving it on
a signalfd does not work reliably.  The issue is that reading
a signalfd instead of returning a siginfo returns a signalfd_siginfo and
the kernel must convert from one to the other.

The kernel does not currently have the code to deduce which union
members of struct siginfo are in use.

In this patchset I fix that by introducing a new function siginfo_layout
that can look at a siginfo and report which union member of struct
siginfo is in use.  Before that I clean up how we populate struct
siginfo.

The siginfo structure has two key members si_signo and si_code.  Some
si_codes are signal specific and for those it takes si_signo and si_code
to indicate the members of siginfo that are valid.  The rest of the
si_code values are signal independent like SI_USER, SI_KERNEL, SI_QUEUE,
and SI_TIMER and only si_code is needed to indicate which members of
siginfo are valid.

At least that is how POSIX documents them, and how common sense would
indicate they should function.  In practice we have been rather sloppy
about maintaining the ABI in linux and we have some exceptions.  We have
a couple of buggy architectures that make SI_USER mean something
different when combined with SIGFPE or SIGTRAP.  Worse we have
fcntl(F_SETSIG) which results in the si_codes POLL_IN, POLL_OUT,
POLL_MSG, POLL_ERR, POLL_PRI, POLL_HUP being sent with any arbitrary
signal, while the values are in a range that overlaps the signal
specific si_codes.

Thankfully the ambiguous cases with the POLL_NNN si_codes are for
things no sane persion would do that so we can rectify the situtation.
AKA no one cares so we won't cause a regression fixing it.

As part of fixing this I stop leaking the __SI_xxxx codes to userspace
and stop storing them in the high 16bits of si_code.  Making the kernel
code fundamentally simpler.  We have already confirmed that the one
application that would see this difference in kernel behavior CRIU won't
be affected by this change as it copies values verbatim from one kernel
interface to another.

v2:
   - Benchmarked the code to confirm no performance changes are visible.
   - Reworked the first couple of patches so that TRAP_FIXME and
     FPE_FIXME are not exported to userspace.
   - Rebased on top of the siginfo cleanup that came in v4.13-rc1
   - Updated alpha to use both TRAP_FIXME and FPE_FIXME

Eric W. Biederman (7):
      signal/alpha: Document a conflict with SI_USER for SIGTRAP
      signal/ia64: Document a conflict with SI_USER with SIGFPE
      signal/sparc: Document a conflict with SI_USER with SIGFPE
      signal/mips: Document a conflict with SI_USER with SIGFPE
      signal/testing: Don't look for __SI_FAULT in userspace
      fcntl: Don't use ambiguous SIG_POLL si_codes
      signal: Remove kernel interal si_code magic

 arch/alpha/include/uapi/asm/siginfo.h         |  14 ++++
 arch/alpha/kernel/traps.c                     |   6 +-
 arch/arm64/kernel/signal32.c                  |  23 ++----
 arch/blackfin/include/uapi/asm/siginfo.h      |  30 ++++---
 arch/frv/include/uapi/asm/siginfo.h           |   2 +-
 arch/ia64/include/uapi/asm/siginfo.h          |  21 +++--
 arch/ia64/kernel/signal.c                     |  17 ++--
 arch/ia64/kernel/traps.c                      |   4 +-
 arch/mips/include/uapi/asm/siginfo.h          |  11 ++-
 arch/mips/kernel/signal32.c                   |  19 ++---
 arch/mips/kernel/traps.c                      |   2 +-
 arch/parisc/kernel/signal32.c                 |  31 ++++---
 arch/powerpc/kernel/signal_32.c               |  20 ++---
 arch/s390/kernel/compat_signal.c              |  32 ++++---
 arch/sparc/include/uapi/asm/siginfo.h         |   9 +-
 arch/sparc/kernel/signal32.c                  |  16 ++--
 arch/sparc/kernel/traps_32.c                  |   2 +-
 arch/sparc/kernel/traps_64.c                  |   2 +-
 arch/tile/include/uapi/asm/siginfo.h          |   4 +-
 arch/tile/kernel/compat_signal.c              |  18 ++--
 arch/tile/kernel/traps.c                      |   2 +-
 arch/x86/kernel/signal_compat.c               |  21 ++---
 fs/fcntl.c                                    |  13 ++-
 fs/signalfd.c                                 |  22 ++---
 include/linux/signal.h                        |  22 +++++
 include/uapi/asm-generic/siginfo.h            | 115 +++++++++++---------------
 kernel/exit.c                                 |   4 +-
 kernel/ptrace.c                               |   6 +-
 kernel/signal.c                               |  72 ++++++++++++----
 tools/testing/selftests/x86/mpx-mini-test.c   |   3 +-
 tools/testing/selftests/x86/protection_keys.c |  13 ++-
 31 files changed, 318 insertions(+), 258 deletions(-)

[toc] | [next] | [standalone]

#1690297 — [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

We have a weird and problematic intersection of features that when
they all come together result in ambiguous siginfo values, that
we can not support properly.

- Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.

- Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
  that imply they are signal specific si_codes and using the
  aforementioned arbitrary signal to deliver them.

- Supporting injection of arbitrary siginfo values for debugging and
  checkpoint/restore.

The result is that just looking at siginfo si_codes of 1 to 6 are
ambigious.  It could either be a signal specific si_code or it could
be a generic si_code.

For most of the kernel this is a non-issue but for sending signals
with siginfo it is impossible to play back the kernel signals and
get the same result.

Strictly speaking when the si_code was changed from SI_SIGIO to
POLL_IN and friends between 2.2 and 2.4 this functionality was not
ambiguous, as only real time signals were supported.  Before 2.4 was
released the kernel began supporting siginfo with non realtime signals
so they could give details of why the signal was sent.

The result is that if F_SETSIG is set to one of the signals with signal
specific si_codes then user space can not know why the signal was sent.

I grepped through a bunch of userspace programs using debian code
search to get a feel for how often people choose a signal that results
in an ambiguous si_code.  I only found one program doing so and it was
using SIGCHLD to test the F_SETSIG functionality, and did not appear
to be a real world usage.

Therefore the ambiguity does not appears to be a real world problem in
practice.  Remove the ambiguity while introducing the smallest chance
of breakage by changing the si_code to SI_SIGIO when signals with
signal specific si_codes are targeted.

Fixes: v2.3.40 -- Added support for queueing non-rt signals
Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 fs/fcntl.c                         | 13 ++++++++++++-
 include/linux/signal.h             |  8 ++++++++
 include/uapi/asm-generic/siginfo.h |  4 ++--
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 3b01b646e528..cfee2e084dbb 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -741,10 +741,21 @@ static void send_sigio_to_task(struct task_struct *p,
 			si.si_signo = signum;
 			si.si_errno = 0;
 		        si.si_code  = reason;
+			/*
+			 * Posix definies POLL_IN and friends to be signal
+			 * specific si_codes for SIG_POLL.  Linux extended
+			 * these si_codes to other signals in a way that is
+			 * ambiguous if other signals also have signal
+			 * specific si_codes.  In that case use SI_SIGIO instead
+			 * to remove the ambiguity.
+			 */
+			if (sig_specific_sicodes(signum))
+				si.si_code = SI_SIGIO;
+
 			/* Make sure we are called with one of the POLL_*
 			   reasons, otherwise we could leak kernel stack into
 			   userspace.  */
-			BUG_ON((reason & __SI_MASK) != __SI_POLL);
+			BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL));
 			if (reason - POLL_IN >= NSIGPOLL)
 				si.si_band  = ~0L;
 			else
diff --git a/include/linux/signal.h b/include/linux/signal.h
index e2678b5dbb21..c97cc20369c0 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -380,10 +380,18 @@ int unhandled_signal(struct task_struct *tsk, int sig);
         rt_sigmask(SIGCONT)   |  rt_sigmask(SIGCHLD)   | \
 	rt_sigmask(SIGWINCH)  |  rt_sigmask(SIGURG)    )
 
+#define SIG_SPECIFIC_SICODES_MASK (\
+	rt_sigmask(SIGILL)    |  rt_sigmask(SIGFPE)    | \
+	rt_sigmask(SIGSEGV)   |  rt_sigmask(SIGBUS)    | \
+	rt_sigmask(SIGTRAP)   |  rt_sigmask(SIGCHLD)   | \
+	rt_sigmask(SIGPOLL)   |  rt_sigmask(SIGSYS)    | \
+	SIGEMT_MASK                                    )
+
 #define sig_kernel_only(sig)		siginmask(sig, SIG_KERNEL_ONLY_MASK)
 #define sig_kernel_coredump(sig)	siginmask(sig, SIG_KERNEL_COREDUMP_MASK)
 #define sig_kernel_ignore(sig)		siginmask(sig, SIG_KERNEL_IGNORE_MASK)
 #define sig_kernel_stop(sig)		siginmask(sig, SIG_KERNEL_STOP_MASK)
+#define sig_specific_sicodes(sig)	siginmask(sig, SIG_SPECIFIC_SICODES_MASK)
 
 #define sig_fatal(t, signr) \
 	(!siginmask(signr, SIG_KERNEL_IGNORE_MASK|SIG_KERNEL_STOP_MASK) && \
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index 9c4eca6b374a..9e956ea94d57 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -184,7 +184,7 @@ typedef struct siginfo {
 #define SI_TIMER __SI_CODE(__SI_TIMER,-2) /* sent by timer expiration */
 #define SI_MESGQ __SI_CODE(__SI_MESGQ,-3) /* sent by real time mesq state change */
 #define SI_ASYNCIO	-4		/* sent by AIO completion */
-#define SI_SIGIO	-5		/* sent by queued SIGIO */
+#define SI_SIGIO __SI_CODE(__SI_POLL,-5) /* sent by queued SIGIO */
 #define SI_TKILL	-6		/* sent by tkill system call */
 #define SI_DETHREAD	-7		/* sent by execve() killing subsidiary threads */
 
@@ -259,7 +259,7 @@ typedef struct siginfo {
 #define NSIGCHLD	6
 
 /*
- * SIGPOLL si_codes
+ * SIGPOLL (or any other signal without signal specific si_codes) si_codes
  */
 #define POLL_IN		(__SI_POLL|1)	/* data input available */
 #define POLL_OUT	(__SI_POLL|2)	/* output buffers available */
-- 
2.10.1

[toc] | [prev] | [next] | [standalone]

#1693076 — Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

On 07/18, Eric W. Biederman wrote:
>
> -			BUG_ON((reason & __SI_MASK) != __SI_POLL);
> +			BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL));
                                                      ^^^^^^^^^^^^^^^^^
looks obviously wrong? Say, POLL_IN is obviously > NSIGPOLL == 6.

Probably you meant

			BUG_ON((reason < POLL_IN) || (reason - POLL_IN > NSIGPOLL)

?

but this contradicts with the next line:

>  			if (reason - POLL_IN >= NSIGPOLL)
>  				si.si_band  = ~0L;

confused...

Oleg.

[toc] | [prev] | [next] | [standalone]

#1693354 — Re: [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes

Oleg Nesterov <oleg@redhat.com> writes:

> On 07/18, Eric W. Biederman wrote:
>>
>> -			BUG_ON((reason & __SI_MASK) != __SI_POLL);
>> +			BUG_ON((reason < POLL_IN) || (reason > NSIGPOLL));
>                                                       ^^^^^^^^^^^^^^^^^
> looks obviously wrong? Say, POLL_IN is obviously > NSIGPOLL == 6.

Strictly speaking that code is wrong until the next patch
when I remove __SI_POLL.  That is my mistake.

When the values are not their messed up internal kernel variants
the code works fine and makes sense.

#define POLL_IN		1	/* data input available */
#define POLL_OUT	2	/* output buffers available */
#define POLL_MSG	3	/* input message available */
#define POLL_ERR	4	/* i/o error */
#define POLL_PRI	5	/* high priority input available */
#define POLL_HUP	6	/* device disconnected */
#define NSIGPOLL	6

> Probably you meant
>
> 			BUG_ON((reason < POLL_IN) || (reason - POLL_IN > NSIGPOLL)
>
> ?
>
> but this contradicts with the next line:

>>  			if (reason - POLL_IN >= NSIGPOLL)
>>  				si.si_band  = ~0L;
>
> confused...

I am mystified why we test for a condition that we have been bugging on
for ages.

Eric

[toc] | [prev] | [next] | [standalone]

#1690298 — [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0.  This is the same si_code as SI_USER.  Posix
and common sense requires that SI_USER not be a signal specific
si_code.  As such this use of 0 for the si_code is a pretty
horribly broken ABI.

This use of of __SI_FAULT is only a decade old.  Which compared
to the other pieces of kernel code that has made this mistake
is almost yesterday.

This is probably worth fixing but I don't know mips well enough
to know what si_code to would be the proper one to use.

Cc: Ralf Baechle <ralf@linux-mips.org>
Ref: 948a34cf3988 ("[MIPS] Maintain si_code field properly for FP exceptions")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/mips/include/uapi/asm/siginfo.h | 7 +++++++
 arch/mips/kernel/traps.c             | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/uapi/asm/siginfo.h b/arch/mips/include/uapi/asm/siginfo.h
index 8069cf766603..9becfd102132 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -123,4 +123,11 @@ typedef struct siginfo {
 #define SI_TIMER __SI_CODE(__SI_TIMER, -3) /* sent by timer expiration */
 #define SI_MESGQ __SI_CODE(__SI_MESGQ, -4) /* sent by real time mesq state change */
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME	(__SI_FAULT|0)	/* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
 #endif /* _UAPI_ASM_SIGINFO_H */
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index b68b4d0726d3..6c9cca9c5341 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
 	else if (fcr31 & FPU_CSR_INE_X)
 		si.si_code = FPE_FLTRES;
 	else
-		si.si_code = __SI_FAULT;
+		si.si_code = FPE_FIXME;
 	force_sig_info(SIGFPE, &si, tsk);
 }
 
-- 
2.10.1

[toc] | [prev] | [next] | [standalone]

#1705689 — Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

On Tue, 18 Jul 2017, Eric W. Biederman wrote:

> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index b68b4d0726d3..6c9cca9c5341 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>  	else if (fcr31 & FPU_CSR_INE_X)
>  		si.si_code = FPE_FLTRES;
>  	else
> -		si.si_code = __SI_FAULT;
> +		si.si_code = FPE_FIXME;

 This is an "impossible" state to reach unless your hardware is on fire.  
One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
FPE exception would not have happened.

 Of course there could be a simulator bug, or we could have breakage 
somewhere causing `process_fpemu_return' to be called with SIGFPE and 
inconsistent `fcr31'.  So we need to handle it somehow.

 So what would be the right value of `si_code' to use here for such an 
unexpected exception condition?  I think `BUG()' would be too big a 
hammer here.  Or wouldn't it?

  Maciej

[toc] | [prev] | [next] | [standalone]

#1705744 — Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

On Mon, Aug 7, 2017 at 9:18 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
>
>  So what would be the right value of `si_code' to use here for such an
> unexpected exception condition?  I think `BUG()' would be too big a
> hammer here.  Or wouldn't it?

Hell no. NEVER EVER BUG().

The only case to use BUG() is if there is some core data structure
(say, kernel stack) that is so corrupted that you know you cannot
continue. That's the *only* valid use.

If this is a "this condition cannot happen" issue, then just remove
the damn conditional. It's pointless. Adding a BUG() to show "this
cannot happen" is not acceptable.

                        Linus

[toc] | [prev] | [next] | [standalone]

#1705824 — Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

On Mon, Aug 07, 2017 at 10:41:39AM -0700, Linus Torvalds wrote:

> On Mon, Aug 7, 2017 at 9:18 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> >
> >  So what would be the right value of `si_code' to use here for such an
> > unexpected exception condition?  I think `BUG()' would be too big a
> > hammer here.  Or wouldn't it?
> 
> Hell no. NEVER EVER BUG().
> 
> The only case to use BUG() is if there is some core data structure
> (say, kernel stack) that is so corrupted that you know you cannot
> continue. That's the *only* valid use.
> 
> If this is a "this condition cannot happen" issue, then just remove
> the damn conditional. It's pointless. Adding a BUG() to show "this
> cannot happen" is not acceptable.

I queued a patch to remove the code for 4.14.

  Ralf

[toc] | [prev] | [next] | [standalone]

#1706673 — Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

"Maciej W. Rozycki" <macro@imgtec.com> writes:

> On Tue, 18 Jul 2017, Eric W. Biederman wrote:
>
>> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
>> index b68b4d0726d3..6c9cca9c5341 100644
>> --- a/arch/mips/kernel/traps.c
>> +++ b/arch/mips/kernel/traps.c
>> @@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>>  	else if (fcr31 & FPU_CSR_INE_X)
>>  		si.si_code = FPE_FLTRES;
>>  	else
>> -		si.si_code = __SI_FAULT;
>> +		si.si_code = FPE_FIXME;
>
>  This is an "impossible" state to reach unless your hardware is on fire.  
> One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
> FPE exception would not have happened.
>
>  Of course there could be a simulator bug, or we could have breakage 
> somewhere causing `process_fpemu_return' to be called with SIGFPE and 
> inconsistent `fcr31'.  So we need to handle it somehow.
>
>  So what would be the right value of `si_code' to use here for such an 
> unexpected exception condition?  I think `BUG()' would be too big a 
> hammer here.  Or wouldn't it?

The possible solutions I can think of are:

WARN_ON_ONCE with a comment.

Add a new si_code to uapi/asm-generic/siginfo.h perhaps FPE_IMPOSSIBLE.
Like syscall numbers si_codes are cheap.

Call force_sig() instead of force_sig_info, using just a generic
si_code.

If this is truly impossible and the compiler doesn't complain just drop
the code.

Eric

[toc] | [prev] | [next] | [standalone]

#1706949 — Re: [PATCH 4/7] signal/mips: Document a conflict with SI_USER with SIGFPE

On Tue, 8 Aug 2017, Eric W. Biederman wrote:

> >  This is an "impossible" state to reach unless your hardware is on fire.  
> > One or more of the FCSR Cause bits will have been set (in `fcr31') or the 
> > FPE exception would not have happened.
> >
> >  Of course there could be a simulator bug, or we could have breakage 
> > somewhere causing `process_fpemu_return' to be called with SIGFPE and 
> > inconsistent `fcr31'.  So we need to handle it somehow.
> >
> >  So what would be the right value of `si_code' to use here for such an 
> > unexpected exception condition?  I think `BUG()' would be too big a 
> > hammer here.  Or wouldn't it?
> 
> The possible solutions I can think of are:
> 
> WARN_ON_ONCE with a comment.
> 
> Add a new si_code to uapi/asm-generic/siginfo.h perhaps FPE_IMPOSSIBLE.
> Like syscall numbers si_codes are cheap.

 I think we ought to do both.

 First, we have our own FP emulation code, which is changed from time to 
time, that uses the same exit path that the hardware exception does.  It 
could happen that we miss something and return SIGFPE from the emulation 
code without setting the cause bits appropriately.  This would be our own 
bug which might trigger exceedingly rarely and could then be caught by 
WARN_ON_ONCE or otherwise stay there forever in the absence of that check.

 Second, changing `si_code' from __SI_FAULT to 0 aka __SI_KILL will likely 
interfere with `copy_siginfo_to_user32' in arch/mips/kernel/signal32.c, 
making the userland lose the address of the faulting instruction in 32-bit 
software run on 64-bit hardware only, making our API inconsistent.  Using 
a distinct `si_code' value such as FPE_IMPOSSIBLE (though we might choose 
say FPE_FLTUNK for "FLoaTing point UNKnown" instead, for consistency; mind 
that most `si_code' macros have the same number of characters within 
groups associated with individual signals) for such odd traps is allowed 
by SUS and will prevent the inconsistency from happening, very cheaply as 
you say.

  Maciej

[toc] | [prev] | [next] | [standalone]

#1690302 — [PATCH 3/7] signal/sparc: Document a conflict with SI_USER with SIGFPE

Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0.  This is the same si_code as SI_USER.  Posix
and common sense requires that SI_USER not be a signal specific
si_code.  As such this use of 0 for the si_code is a pretty
horribly broken ABI.

This was introduced in 2.3.41 so this mess has had a long time for
people to be able to start depending on it.

As this bug has existed for 17 years already I don't know if it is
worth fixing.  It is definitely worth documenting what is going
on so that no one decides to copy this bad decision.

Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/sparc/include/uapi/asm/siginfo.h | 7 +++++++
 arch/sparc/kernel/traps_32.c          | 2 +-
 arch/sparc/kernel/traps_64.c          | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h
index 2d9b79ccaa50..da2126e0c536 100644
--- a/arch/sparc/include/uapi/asm/siginfo.h
+++ b/arch/sparc/include/uapi/asm/siginfo.h
@@ -17,6 +17,13 @@
 #define SI_NOINFO	32767		/* no information in siginfo_t */
 
 /*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME	(__SI_FAULT|0)	/* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
  * SIGEMT si_codes
  */
 #define EMT_TAGOVF	(__SI_FAULT|1)	/* tag overflow */
diff --git a/arch/sparc/kernel/traps_32.c b/arch/sparc/kernel/traps_32.c
index 466d4aed06c7..581cf35ee7e3 100644
--- a/arch/sparc/kernel/traps_32.c
+++ b/arch/sparc/kernel/traps_32.c
@@ -306,7 +306,7 @@ void do_fpe_trap(struct pt_regs *regs, unsigned long pc, unsigned long npc,
 	info.si_errno = 0;
 	info.si_addr = (void __user *)pc;
 	info.si_trapno = 0;
-	info.si_code = __SI_FAULT;
+	info.si_code = FPE_FIXME;
 	if ((fsr & 0x1c000) == (1 << 14)) {
 		if (fsr & 0x10)
 			info.si_code = FPE_FLTINV;
diff --git a/arch/sparc/kernel/traps_64.c b/arch/sparc/kernel/traps_64.c
index 196ee5eb4d48..e882e128faa3 100644
--- a/arch/sparc/kernel/traps_64.c
+++ b/arch/sparc/kernel/traps_64.c
@@ -2258,7 +2258,7 @@ static void do_fpe_common(struct pt_regs *regs)
 		info.si_errno = 0;
 		info.si_addr = (void __user *)regs->tpc;
 		info.si_trapno = 0;
-		info.si_code = __SI_FAULT;
+		info.si_code = FPE_FIXME;
 		if ((fsr & 0x1c000) == (1 << 14)) {
 			if (fsr & 0x10)
 				info.si_code = FPE_FLTINV;
-- 
2.10.1

[toc] | [prev] | [next] | [standalone]

#1690305 — [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP

Setting si_code to __SI_FAULT results in a userspace seeing
an si_code of 0.  This is the same si_code as SI_USER.  Posix
and common sense requires that SI_USER not be a signal specific
si_code.  As such this use of 0 for the si_code is a pretty
horribly broken ABI.

Given that alpha is on it's last legs I don't know that it is worth
fixing this, but it is worth documenting what is going on so that
no one decides to copy this bad decision.

This was introduced during the 2.5 development cycle so this
mess has had a long time for people to be able to depend upon it.

v2: Added FPE_FIXME for alpha as Helge Deller <deller@gmx.de> pointed out
    with his alternate patch one of the cases is SIGFPE not SIGTRAP.

Cc: Helge Deller <deller@gmx.de>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: linux-alpha@vger.kernel.org
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Ref: 0a635c7a84cf ("Fill in siginfo_t.")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/alpha/include/uapi/asm/siginfo.h | 14 ++++++++++++++
 arch/alpha/kernel/traps.c             |  6 +++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/siginfo.h b/arch/alpha/include/uapi/asm/siginfo.h
index 9822362a8424..972f547d9e41 100644
--- a/arch/alpha/include/uapi/asm/siginfo.h
+++ b/arch/alpha/include/uapi/asm/siginfo.h
@@ -6,4 +6,18 @@
 
 #include <asm-generic/siginfo.h>
 
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME	(__SI_FAULT|0)	/* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+/*
+ * SIGTRAP si_codes
+ */
+#ifdef __KERNEL__
+#define TRAP_FIXME	(__SI_FAULT|0)	/* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
 #endif
diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 65bb102d985b..e94f4b73ac04 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -278,7 +278,7 @@ do_entIF(unsigned long type, struct pt_regs *regs)
 	      case 1: /* bugcheck */
 		info.si_signo = SIGTRAP;
 		info.si_errno = 0;
-		info.si_code = __SI_FAULT;
+		info.si_code = TRAP_FIXME;
 		info.si_addr = (void __user *) regs->pc;
 		info.si_trapno = 0;
 		send_sig_info(SIGTRAP, &info, current);
@@ -318,7 +318,7 @@ do_entIF(unsigned long type, struct pt_regs *regs)
 			break;
 		case GEN_ROPRAND:
 			signo = SIGFPE;
-			code = __SI_FAULT;
+			code = FPE_FIXME;
 			break;
 
 		case GEN_DECOVF:
@@ -340,7 +340,7 @@ do_entIF(unsigned long type, struct pt_regs *regs)
 		case GEN_SUBRNG7:
 		default:
 			signo = SIGTRAP;
-			code = __SI_FAULT;
+			code = TRAP_FIXME;
 			break;
 		}
 
-- 
2.10.1

[toc] | [prev] | [next] | [standalone]

#1690552 — Re: [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP

On 07/18/2017 04:06 AM, Eric W. Biederman wrote:
> Setting si_code to __SI_FAULT results in a userspace seeing
> an si_code of 0.  This is the same si_code as SI_USER.  Posix
> and common sense requires that SI_USER not be a signal specific
> si_code.  As such this use of 0 for the si_code is a pretty
> horribly broken ABI.
> 
> Given that alpha is on it's last legs I don't know that it is worth
> fixing this, but it is worth documenting what is going on so that
> no one decides to copy this bad decision.
> 
> This was introduced during the 2.5 development cycle so this
> mess has had a long time for people to be able to depend upon it.
> 
> v2: Added FPE_FIXME for alpha as Helge Deller<deller@gmx.de>  pointed out
>      with his alternate patch one of the cases is SIGFPE not SIGTRAP.
> 
> Cc: Helge Deller<deller@gmx.de>
> Cc: Richard Henderson<rth@twiddle.net>
> Cc: Ivan Kokshaysky<ink@jurassic.park.msu.ru>
> Cc: Matt Turner<mattst88@gmail.com>
> Cc:linux-alpha@vger.kernel.org
> History Tree:https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> Ref: 0a635c7a84cf ("Fill in siginfo_t.")
> Signed-off-by: "Eric W. Biederman"<ebiederm@xmission.com>
> ---
>   arch/alpha/include/uapi/asm/siginfo.h | 14 ++++++++++++++
>   arch/alpha/kernel/traps.c             |  6 +++---
>   2 files changed, 17 insertions(+), 3 deletions(-)

Acked-by: Richard Henderson <rth@twiddle.net>


r~

[toc] | [prev] | [next] | [standalone]

#1690445 — Re: [PATCH 7/7] signal: Remove kernel interal si_code magic

On Tue, Jul 18, 2017 at 7:06 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> struct siginfo is a union and the kernel since 2.4 has been hiding a union
> tag in the high 16bits of si_code using the values:
> __SI_KILL
> __SI_TIMER
> __SI_POLL
> __SI_FAULT
> __SI_CHLD
> __SI_RT
> __SI_MESGQ
> __SI_SYS
>
> While this looks plausible on the surface, in practice this situation has
> not worked well.

So on the whole I think we just need to do this, but the part I really
hate about this series is still this the siginfo_layout() part.

I can well believe that it is needed for the compat case. siginfo is a
piece of crap crazy type, and re-ordering fields for compat is
something we are always going to have to do.

But for the native case, the *only* reason we do not just copy the
siginfo as-is seems to be that it's just too big, due to other bad
design decisions in siginfo ("let's make sure it's big enough by
allocating 512 bytes for it).

And afaik, absolutely nobody uses more than about 36 bytes of that
512-byte _sifields union (and that one use is SIGILL with three
pointers and three integers and some padding.

So why don't we just say "screw this idiotic layout crap, and just
unconditionally copy that much smaller maximum of bytes"?

Leave that layout thing purely for compat handling.

Yes, yes, there's a couple of small gotchas's:

 - "_sys_private" for posix timers, and it would have to be moved to
the end of the structure so that it doesn't get copied.

 - make sure those 36 bytes are cleared when allocating the siginfo
(this should be trivial) so that we don't leak any other memory.

But on the whole, it looks pretty straightforward to just get rid of
those stupid layout things, and make them purely about compat stuff.

Please?

The si_code stuff clearly needs to be done regardless, so much of this
patch series looks good to me.  But if we're doign this cleanup, can't
we please go that one extra step and get rid of the crazy "let's treat
the union as different types", and just treat it as a largely opaque
thing.

Pretty please?

                  Linus

[toc] | [prev] | [next] | [standalone]

#1690519 — Re: [PATCH 7/7] signal: Remove kernel interal si_code magic

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, Jul 18, 2017 at 7:06 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> struct siginfo is a union and the kernel since 2.4 has been hiding a union
>> tag in the high 16bits of si_code using the values:
>> __SI_KILL
>> __SI_TIMER
>> __SI_POLL
>> __SI_FAULT
>> __SI_CHLD
>> __SI_RT
>> __SI_MESGQ
>> __SI_SYS
>>
>> While this looks plausible on the surface, in practice this situation has
>> not worked well.
>
> So on the whole I think we just need to do this, but the part I really
> hate about this series is still this the siginfo_layout() part.
>
> I can well believe that it is needed for the compat case. siginfo is a
> piece of crap crazy type, and re-ordering fields for compat is
> something we are always going to have to do.
>
> But for the native case, the *only* reason we do not just copy the
> siginfo as-is seems to be that it's just too big, due to other bad
> design decisions in siginfo ("let's make sure it's big enough by
> allocating 512 bytes for it).
>
> And afaik, absolutely nobody uses more than about 36 bytes of that
> 512-byte _sifields union (and that one use is SIGILL with three
> pointers and three integers and some padding.
>
> So why don't we just say "screw this idiotic layout crap, and just
> unconditionally copy that much smaller maximum of bytes"?
>
> Leave that layout thing purely for compat handling.

I completely agree.

> Yes, yes, there's a couple of small gotchas's:
>
>  - "_sys_private" for posix timers, and it would have to be moved to
> the end of the structure so that it doesn't get copied.

I don't think we actually need _sys_private at all.

I think the best solution would involve embedding struct siginfo
into struct k_itimer (as we always allocate one).   Then we can just
perform container_of on the siginfo and look at the k_itimer instead.

>  - make sure those 36 bytes are cleared when allocating the siginfo
> (this should be trivial) so that we don't leak any other memory.
>
> But on the whole, it looks pretty straightforward to just get rid of
> those stupid layout things, and make them purely about compat stuff.
>
> Please?
>
> The si_code stuff clearly needs to be done regardless, so much of this
> patch series looks good to me.  But if we're doign this cleanup, can't
> we please go that one extra step and get rid of the crazy "let's treat
> the union as different types", and just treat it as a largely opaque
> thing.
>
> Pretty please?

That is my next step.

I have started on it but it is a big additional patch.  I have to insert
a bunch of memsets to ensure we are not copying unitialized stack
contents to userspace.

I have been convinced not to expect any performance issues:
  - Worst case two reads from memory 60ns*2 = 120ns.
  - 650ns time to send a signal.
  - 350ns time to receive a signal.
  So that is maybe a 10% change, and more likely lost completely
  in the noise.

I intend to measure the performance change just copying it all to see if
I even need to optimize to just copy the needed 36 bytes.

The diffstat for introducing a clear_siginfo to ensure we have made
those memsets is huge so I am worried about introducing bugs along
the way or missing something.

 arch/alpha/kernel/osf_sys.c               |  1 +
 arch/alpha/kernel/signal.c                |  2 ++
 arch/alpha/kernel/traps.c                 |  5 ++++
 arch/alpha/mm/fault.c                     |  2 ++
 arch/arc/kernel/traps.c                   | 14 ++++++----
 arch/arc/mm/fault.c                       |  1 +
 arch/arm/kernel/ptrace.c                  |  2 ++
 arch/arm/kernel/swp_emulate.c             |  1 +
 arch/arm/kernel/traps.c                   |  5 ++++
 arch/arm/mm/alignment.c                   |  1 +
 arch/arm/mm/fault.c                       |  3 ++
 arch/arm/vfp/vfpmodule.c                  |  2 +-
 arch/arm64/kernel/debug-monitors.c        | 13 +++++----
 arch/arm64/kernel/fpsimd.c                |  2 +-
 arch/arm64/kernel/ptrace.c                | 13 +++++----
 arch/arm64/kernel/traps.c                 |  2 ++
 arch/arm64/mm/fault.c                     |  4 +++
 arch/blackfin/kernel/traps.c              |  1 +
 arch/c6x/kernel/traps.c                   |  1 +
 arch/cris/mm/fault.c                      |  1 +
 arch/frv/kernel/traps.c                   |  7 +++++
 arch/frv/mm/fault.c                       |  1 +
 arch/hexagon/kernel/traps.c               |  1 +
 arch/hexagon/mm/vm_fault.c                |  2 ++
 arch/ia64/kernel/brl_emu.c                |  3 ++
 arch/ia64/kernel/signal.c                 |  2 ++
 arch/ia64/kernel/traps.c                  |  3 +-
 arch/ia64/kernel/unaligned.c              |  1 +
 arch/ia64/mm/fault.c                      |  1 +
 arch/m32r/kernel/traps.c                  |  1 +
 arch/m32r/mm/fault.c                      |  1 +
 arch/m68k/kernel/traps.c                  |  2 ++
 arch/m68k/mm/fault.c                      |  3 +-
 arch/metag/kernel/traps.c                 |  2 ++
 arch/metag/mm/fault.c                     |  2 ++
 arch/microblaze/kernel/exceptions.c       |  1 +
 arch/microblaze/mm/fault.c                |  1 +
 arch/mips/kernel/traps.c                  | 29 +++++++++++++------
 arch/mips/mm/fault.c                      |  1 +
 arch/mn10300/kernel/fpu.c                 |  1 +
 arch/mn10300/kernel/traps.c               |  1 +
 arch/mn10300/mm/fault.c                   |  1 +
 arch/mn10300/mm/misalignment.c            |  2 ++
 arch/nios2/kernel/traps.c                 |  1 +
 arch/openrisc/kernel/traps.c              |  5 +++-
 arch/openrisc/mm/fault.c                  |  1 +
 arch/parisc/kernel/ptrace.c               |  1 +
 arch/parisc/kernel/traps.c                |  2 ++
 arch/parisc/kernel/unaligned.c            |  2 ++
 arch/parisc/math-emu/driver.c             |  1 +
 arch/parisc/mm/fault.c                    |  1 +
 arch/powerpc/kernel/process.c             |  2 ++
 arch/powerpc/kernel/traps.c               |  4 +--
 arch/powerpc/mm/fault.c                   |  1 +
 arch/powerpc/platforms/cell/spufs/fault.c |  2 +-
 arch/s390/kernel/traps.c                  |  3 ++
 arch/s390/mm/fault.c                      |  2 ++
 arch/score/kernel/traps.c                 |  1 +
 arch/score/mm/fault.c                     |  1 +
 arch/sh/kernel/hw_breakpoint.c            |  1 +
 arch/sh/kernel/traps_32.c                 |  4 +++
 arch/sh/math-emu/math.c                   |  1 +
 arch/sh/mm/fault.c                        |  1 +
 arch/sparc/kernel/process_64.c            |  1 +
 arch/sparc/kernel/sys_sparc_32.c          |  1 +
 arch/sparc/kernel/sys_sparc_64.c          |  1 +
 arch/sparc/kernel/traps_32.c              | 10 +++++++
 arch/sparc/kernel/traps_64.c              | 15 ++++++++++
 arch/sparc/kernel/unaligned_32.c          |  1 +
 arch/sparc/mm/fault_32.c                  |  1 +
 arch/sparc/mm/fault_64.c                  |  1 +
 arch/tile/kernel/hardwall.c               |  1 +
 arch/tile/kernel/ptrace.c                 |  2 +-
 arch/tile/kernel/single_step.c            | 24 +++++++++-------
 arch/tile/kernel/traps.c                  |  4 ++-
 arch/tile/kernel/unaligned.c              | 46 +++++++++++++++++--------------
 arch/tile/mm/fault.c                      |  1 +
 arch/um/kernel/ptrace.c                   |  2 +-
 arch/um/kernel/trap.c                     |  4 ++-
 arch/unicore32/kernel/fpu-ucf64.c         |  3 +-
 arch/unicore32/mm/fault.c                 |  3 ++
 arch/x86/entry/vsyscall/vsyscall_64.c     |  2 +-
 arch/x86/kernel/ptrace.c                  |  2 +-
 arch/x86/kernel/traps.c                   |  3 ++
 arch/x86/kvm/mmu.c                        |  1 +
 arch/x86/mm/fault.c                       |  1 +
 arch/xtensa/kernel/ptrace.c               |  1 +
 arch/xtensa/kernel/traps.c                |  1 +
 arch/xtensa/mm/fault.c                    |  1 +
 drivers/usb/core/devio.c                  |  4 +--
 fs/fcntl.c                                |  1 +
 include/linux/ptrace.h                    |  2 +-
 include/linux/signal.h                    |  5 ++++
 ipc/mqueue.c                              |  1 +
 kernel/debug/kdb/kdb_main.c               |  1 +
 kernel/ptrace.c                           |  2 +-
 kernel/seccomp.c                          |  2 +-
 kernel/signal.c                           | 21 ++++++++++----
 kernel/time/posix-timers.c                |  2 +-
 mm/memory-failure.c                       |  1 +
 100 files changed, 272 insertions(+), 85 deletions(-)

Eric

[toc] | [prev] | [next] | [standalone]

#1694193 — Simplfying copy_siginfo_to_user

ebiederm@xmission.com (Eric W. Biederman) writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Tue, Jul 18, 2017 at 7:06 AM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> struct siginfo is a union and the kernel since 2.4 has been hiding a union
>>> tag in the high 16bits of si_code using the values:
>>> __SI_KILL
>>> __SI_TIMER
>>> __SI_POLL
>>> __SI_FAULT
>>> __SI_CHLD
>>> __SI_RT
>>> __SI_MESGQ
>>> __SI_SYS
>>>
>>> While this looks plausible on the surface, in practice this situation has
>>> not worked well.
>>
>> So on the whole I think we just need to do this, but the part I really
>> hate about this series is still this the siginfo_layout() part.
>>
>> I can well believe that it is needed for the compat case. siginfo is a
>> piece of crap crazy type, and re-ordering fields for compat is
>> something we are always going to have to do.
>>
>> But for the native case, the *only* reason we do not just copy the
>> siginfo as-is seems to be that it's just too big, due to other bad
>> design decisions in siginfo ("let's make sure it's big enough by
>> allocating 512 bytes for it).
>>
>> And afaik, absolutely nobody uses more than about 36 bytes of that
>> 512-byte _sifields union (and that one use is SIGILL with three
>> pointers and three integers and some padding.
>>
>> So why don't we just say "screw this idiotic layout crap, and just
>> unconditionally copy that much smaller maximum of bytes"?
>>
>> Leave that layout thing purely for compat handling.
>
> I completely agree.

So I just did some measurements to see what the performance impact is of
doing the simple and obvious thing of always copying the entire siginfo
around.  There is a fair amount of variation in my timings but for
the whole change I see about a 20ns increase in time taken to send
a signal with siginfo from the current process to the current process.
AKA timing kill(getpid(),...). 

I played with some clever changes such as limiting the copy to 48 bytes,
disabling the memset and the like but I could not get a strong enough
signal to say that any one change removed the extra or a clear part of
it 20ns.

Do we care about those 20ns for signal deliver?  I suspect from my
previous numbers that if Andy can get signal delivery to use sysret
it will more than make up for the small increase in cost here.

Eric

[toc] | [prev] | [next] | [standalone]

#1694944 — Re: Simplfying copy_siginfo_to_user

On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> I played with some clever changes such as limiting the copy to 48 bytes,
> disabling the memset and the like but I could not get a strong enough
> signal to say that any one change removed the extra or a clear part of
> it 20ns.

What CPU did you use? Because the SMAP bit in particular matters.

The field-by-field copies are extremely slow on modern CPU's that
implement SMAP, unless you also use the special "unsafe_put_user()"
code (or the nasty old put_user_ex() code that some of the x86 signal
code uses).

So one of the advantages of just copy_to_user() ends up being visible
only on Broadwell+ (or whatever the SMAP cutoff is).

                 Linus

[toc] | [prev] | [next] | [standalone]

#1695024 — Re: Simplfying copy_siginfo_to_user

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> I played with some clever changes such as limiting the copy to 48 bytes,
>> disabling the memset and the like but I could not get a strong enough
>> signal to say that any one change removed the extra or a clear part of
>> it 20ns.
>
> What CPU did you use? Because the SMAP bit in particular matters.
>
> The field-by-field copies are extremely slow on modern CPU's that
> implement SMAP, unless you also use the special "unsafe_put_user()"
> code (or the nasty old put_user_ex() code that some of the x86 signal
> code uses).
>
> So one of the advantages of just copy_to_user() ends up being visible
> only on Broadwell+ (or whatever the SMAP cutoff is).

Good point.

The cpu I was testing on was an AMD A10.  I don't actually have a cpu
that supports SMAP handy.

If you would like I can post the minimal patches and benckmark so anyone
who is interested could reproduce this for themselves.

I suspect that if it is down to only 20ns without SMAP this will
definitely be a performance improvement in the presence of SMAP.

Eric

[toc] | [prev] | [next] | [standalone]

#1695334 — Re: Simplfying copy_siginfo_to_user

On Mon, Jul 24, 2017 at 10:43:34AM -0700, Linus Torvalds wrote:
> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > I played with some clever changes such as limiting the copy to 48 bytes,
> > disabling the memset and the like but I could not get a strong enough
> > signal to say that any one change removed the extra or a clear part of
> > it 20ns.
> 
> What CPU did you use? Because the SMAP bit in particular matters.
> 
> The field-by-field copies are extremely slow on modern CPU's that
> implement SMAP, unless you also use the special "unsafe_put_user()"
> code (or the nasty old put_user_ex() code that some of the x86 signal
> code uses).
> 
> So one of the advantages of just copy_to_user() ends up being visible
> only on Broadwell+ (or whatever the SMAP cutoff is).

Guys, could you take a look at vfs.git#work.siginfo?  I'd been pretty
much buried lately (and probably will for several more weeks - long-distance
moves *suck*), so that thing got stalled, but it might be worth a look.

The code generated in copy_siginfo_to_user() in it looks reasonably good,
we don't copy more than we need and all copying to userland is done
by copy_to_user() - one call per call of copy_siginfo_to_user(), so
SMAP crap is not an issue.

The next thing I hope to do is converting compat side of that thing to
the same; that got stalled.

Al "Buried in boxes" Viro...

[toc] | [prev] | [next] | [standalone]

#1700199 — Re: Simplfying copy_siginfo_to_user

Al Viro <viro@ZenIV.linux.org.uk> writes:

2> On Mon, Jul 24, 2017 at 10:43:34AM -0700, Linus Torvalds wrote:
>> On Sat, Jul 22, 2017 at 1:25 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>> > I played with some clever changes such as limiting the copy to 48 bytes,
>> > disabling the memset and the like but I could not get a strong enough
>> > signal to say that any one change removed the extra or a clear part of
>> > it 20ns.
>> 
>> What CPU did you use? Because the SMAP bit in particular matters.
>> 
>> The field-by-field copies are extremely slow on modern CPU's that
>> implement SMAP, unless you also use the special "unsafe_put_user()"
>> code (or the nasty old put_user_ex() code that some of the x86 signal
>> code uses).
>> 
>> So one of the advantages of just copy_to_user() ends up being visible
>> only on Broadwell+ (or whatever the SMAP cutoff is).
>
> Guys, could you take a look at vfs.git#work.siginfo?  I'd been pretty
> much buried lately (and probably will for several more weeks - long-distance
> moves *suck*), so that thing got stalled, but it might be worth a
> look.

There is some good stuff in there.  If you don't mind I am going to
cherry pick out your unification of struct siginfo and struct compat_siginfo.

> The code generated in copy_siginfo_to_user() in it looks reasonably good,
> we don't copy more than we need and all copying to userland is done
> by copy_to_user() - one call per call of copy_siginfo_to_user(), so
> SMAP crap is not an issue.

There is actually a core problem with doing things that way.  You rely
on having the siginfo union member stored in the high bits of si_code.

I have just fixed that in my tree and replaced using the high bits
with calling the function siginfo_layout.

It has been a significant problem storing the union member differently
in the kernel than in userspace.  It has allowed for some pretty
horrendous gaffs in the archictecures changing the meaning of SI_USER
when specific signals are delivered over.  It has also meant that ptrace
siginfo injection and tg_sigqueueinfo have been broken for some signals
almost since the interface was added.

Without any optimization and just changing the code to be copy_to_user
I am seeing a maybe 2% slowdown.  Given that no one has seemed to care
overly for the performance of signal delivery I suspect an almost
unmeasurable slowdown is a reasonable tradeoff for simpler code.

> The next thing I hope to do is converting compat side of that thing to
> the same; that got stalled.

All of that said your precise copying code appears reasonable and quite
nice so I may adopt it on the compat side.

> Al "Buried in boxes" Viro...

Eric "Also Buried in boxes" Biederman

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web