| Message ID | 20170806164428.2273-15-mikko.rapeli@iki.fi |
|---|---|
| State | New |
| Headers | show |
On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote: > Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here > so trying to fall back to gcc's <stddef.h>. The only architecture where you cannot do this safely is x86 family because of x32 exception. If there is no chance that the change will affect x32, feel free to replace size_t with __kernel_size_t like I did some time ago, see http://lkml.kernel.org/r/20170302002022.GB27097@altlinux.org
On Wed, Aug 9, 2017 at 12:57 AM, Dmitry V. Levin <ldv@altlinux.org> wrote: > On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote: >> Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here >> so trying to fall back to gcc's <stddef.h>. > > The only architecture where you cannot do this safely is x86 family > because of x32 exception. If there is no chance that the change will > affect x32, feel free to replace size_t with __kernel_size_t like I did > some time ago, see > http://lkml.kernel.org/r/20170302002022.GB27097@altlinux.org There is another problem: on some 32-bit architectures, size_t is defined as 'unsigned int', while '__kernel_size_t' is defined as 'unsigned long'. These obviously have the same size, but the man page explicitly defines it as 'size_t ss_size'. If a user space program accesses the field in a way requires an exact type match, it gets a warning or error, e.g. 1. printf("signal with %zd bytes\n", stack->ss_size); 2. size_t *pointer_to_size_t = &stack->ss_size; 3. assert(__builtin_types_compatible_p(size_t, typeof(stack->ss_size))) Not sure how important those are, but I think there is at least a risk of any of those showing up in user space. Arnd
On Wed, Aug 09, 2017 at 02:41:59PM +0200, Arnd Bergmann wrote: > On Wed, Aug 9, 2017 at 12:57 AM, Dmitry V. Levin <ldv@altlinux.org> wrote: > > On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote: > >> Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here > >> so trying to fall back to gcc's <stddef.h>. > > > > The only architecture where you cannot do this safely is x86 family > > because of x32 exception. If there is no chance that the change will > > affect x32, feel free to replace size_t with __kernel_size_t like I did > > some time ago, see > > http://lkml.kernel.org/r/20170302002022.GB27097@altlinux.org > > There is another problem: on some 32-bit architectures, size_t is > defined as 'unsigned int', while '__kernel_size_t' is defined as 'unsigned > long'. These obviously have the same size, but the man page > explicitly defines it as 'size_t ss_size'. > > If a user space program accesses the field in a way requires an > exact type match, it gets a warning or error, e.g. > > 1. printf("signal with %zd bytes\n", stack->ss_size); > 2. size_t *pointer_to_size_t = &stack->ss_size; > 3. assert(__builtin_types_compatible_p(size_t, typeof(stack->ss_size))) > > Not sure how important those are, but I think there is at least a risk > of any of those showing up in user space. Agreed, one has to take this issue into consideration when replacing size_t with __kernel_size_t.
diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h index 33073bdcf091..63066f624c10 100644 --- a/arch/arm/include/uapi/asm/signal.h +++ b/arch/arm/include/uapi/asm/signal.h @@ -12,6 +12,8 @@ struct siginfo; #define NSIG 32 typedef unsigned long sigset_t; +#include <stddef.h> + #endif /* __KERNEL__ */ #define SIGHUP 1
Arnd Bergmann <arnd@arndb.de> doubts that __kernel_size_t could be used here so trying to fall back to gcc's <stddef.h>. Fixes uapi header compilation error from userspace on ARCH=arm: asm/signal.h:112:2: error: unknown type name ‘size_t’ size_t ss_size; Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Cc: Arnd Bergmann <arnd@arndb.de> --- arch/arm/include/uapi/asm/signal.h | 2 ++ 1 file changed, 2 insertions(+)