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 [off-list ref] wrote:

quoted

On Sun, Aug 06, 2017 at 06:44:05PM +0200, Mikko Rapeli wrote:

quoted

Arnd Bergmann [off-list ref] 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-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.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.


-- 
ldv