On Fri, Jan 15, 2021 at 1:03 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > On Fri, Jan 15, 2021 at 3:06 AM Ryan Houdek <sonicadvance1@xxxxxxxxx> wrote: > > On Wed, Jan 6, 2021 at 12:49 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > >> On Wed, Jan 6, 2021 at 7:48 AM <sonicadvance1@xxxxxxxxx> wrote: > >> > From: Ryan Houdek <Sonicadvance1@xxxxxxxxx> > >> ... > >> > >> 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.
