On Fri, Jan 15, 2021 at 1:03 AM Arnd Bergmann [off-list ref] wrote:

On Fri, Jan 15, 2021 at 3:06 AM Ryan Houdek [off-list ref] wrote:

quoted

On Wed, Jan 6, 2021 at 12:49 AM Arnd Bergmann [off-list ref] wrote:

quoted

On Wed, Jan 6, 2021 at 7:48 AM [off-list ref] wrote:

quoted

From: Ryan Houdek <redacted>

...

For x86, this has another complication, as some ioctls also need to
check whether they are in an ia32 task (with packed u64 and 32-bit
__kernel_old_time_t) or an x32 task (with aligned u64 and 64-bit
__kernel_old_time_t). If the new syscall gets wired up on x86 as well,
you'd need to decide which of the two behaviors you want.

I can have a follow-up patch that makes this do ni-syscall on x86_64 since
we can go through the int 0x80 handler, or x32 handler path and choose
whichever one there.

I'd say for consistency

We need to make it crystal clear on x86 what this ioctl does.  We have
a silly selection of options:

 - ioctl32() via SYSCALL, x32 bit clear -- presumably does an i386 ioctl?
 - ioctl32() via SYSCALL, x32 bit set -- this needs to do something
clearly documented.
 - ioctl32() via int80 -- presumably you're not wiring this up

In any case, the compat alloc thing should just go away.  It's a hack
and serves no real purpose.

Finally, I'm not convinced that this patch works correctly.  We have
in_compat_syscall(), and code that uses it may well be reachable from
ioctl.  I personally would like to see in_compat_syscall() go away,
but some other people (Hi, Christoph!) disagree, and usage seems to be
increasing, not decreasing.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel