On Mon 30-11-20 17:21:08, Brian Gerst wrote: > On Fri, Nov 27, 2020 at 7:36 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > On Fri, Nov 27, 2020 at 2:30 PM Brian Gerst <brgerst@xxxxxxxxx> wrote: > > > > > > On Fri, Nov 27, 2020 at 1:13 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Nov 26, 2020 at 7:52 AM Jan Kara <jack@xxxxxxx> wrote: > > > > > > > > > > Commit converting syscalls taking 64-bit arguments to new scheme of compat > > > > > handlers omitted converting fanotify_mark(2) which then broke the > > > > > syscall for 32-bit x86 builds. Add missed conversion. It is somewhat > > > > > cumbersome since we need to keep the original compat handler for all the > > > > > other 32-bit archs. > > > > > > > > > > > > > This is stupendously ugly. I'm not really sure how this is supposed > > > > to work on any 32-bit arch. I'm also not sure whether we should > > > > expect the SYSCALL_DEFINE macros to figure this out by themselves. > > > > > > It works on 32-bit arches because the compiler implicitly uses > > > consecutive input registers or stack slots for 64-bit arguments, and > > > some arches have alignment requirements that result in hidden padding. > > > x86-32 is different now because parameters are passed in via pt_regs, > > > and the 64-bit value has to explicitly be reassembled from the high > > > and low 32-bit values, just like in the compat case. > > > > > > > That was my guess. > > > > > I think the simplest way to handle this is add a wrapper in > > > arch/x86/kernel/sys_ia32.c with the other fs syscalls that need 64-bit > > > args. That keeps this mess out of general code. > > > > > > Want to send a patch? > > I settled on doing something along the same line as Jan, but in a more > generic way that lays the groundwork for converting more of these > arch-specific compat wrappers to a generic wrapper. Cool, thanks for looking into this! > Patch coming soon. Looking forward to it :) Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
