[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMzpN2gCETE3O7K7ORxTsOB5KNcX669yVskG==UpJ2ersGFt7Q@mail.gmail.com>
Date: Fri, 28 Feb 2020 14:56:17 -0500
From: Brian Gerst <brgerst@...il.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH v3 5/8] x86: Move 32-bit compat syscalls to common location
On Fri, Feb 28, 2020 at 1:47 PM Andy Lutomirski <luto@...nel.org> wrote:
>
> On Thu, Feb 27, 2020 at 5:28 AM Brian Gerst <brgerst@...il.com> wrote:
> >
> > Move the 32-bit wrappers for syscalls that take 64-bit arguments (loff_t)
> > to a common location so that native 32-bit can use them in preparation for
> > enabling pt_regs-based syscalls.
>
> Can you clarify the purpose? Even having read the series up to this
> point, I have no idea what this has to do with pt_regs.
>
> I think some renaming is in order. Consider:
>
> >
> > -COMPAT_SYSCALL_DEFINE3(x86_ftruncate64, unsigned int, fd,
> > - unsigned long, offset_low, unsigned long, offset_high)
>
> It used to be at least a little bit clear what was going on. There's
> this compat-only mess that changes arguments for ftruncate64. But
> now:
>
> > +SYSCALL_DEFINE3(x86_ftruncate64, unsigned int, fd,
> > + unsigned long, offset_low, unsigned long, offset_high)
> > {
> > return ksys_ftruncate(fd, ((loff_t) offset_high << 32) | offset_low);
> > }
>
> What is this "x86" ftruncate64 thing?
>
> Maybe call it ia32_ftructate? Or at least do something to indicate
> that this is for a specific ABI.
Previously, these syscalls relied on the fact that the 64-bit loff_t
was passed in through two consecutive stack slots. This doesn't work
when switching to using pt_regs, where we need to reassemble the
64-bit arg from two 32-bit args. These wrapper functions were already
in use for the compat versions of these syscalls, because the 64-bit
kernel does use pt_regs for the 32-bit compat syscalls. In order to
enable pt_regs syscalls for 32-bit native the same wrappers are
needed.
These wrappers exists for other architectures as well. It would be
nice to combine them into a more generic version.
>
> > diff --git a/arch/x86/um/sys_call_table_32.c b/arch/x86/um/sys_call_table_32.c
> > index 9649b5ad2ca2..d5520e92f89d 100644
> > --- a/arch/x86/um/sys_call_table_32.c
> > +++ b/arch/x86/um/sys_call_table_32.c
> > @@ -26,6 +26,16 @@
> >
> > #define old_mmap sys_old_mmap
> >
> > +#define sys_x86_pread sys_pread64
> > +#define sys_x86_pwrite sys_pwrite64
> > +#define sys_x86_truncate64 sys_truncate64
> > +#define sys_x86_ftruncate64 sys_ftruncate64
> > +#define sys_x86_readahead sys_readahead
> > +#define sys_x86_fadvise64 sys_fadvise64
> > +#define sys_x86_fadvise64_64 sys_fadvise64_64
> > +#define sys_x86_sync_file_range sys_sync_file_range
> > +#define sys_x86_fallocate sys_fallocate
>
> Can this not be killed by changing the table itself instead of adding
> a bunch of defines?
Ultimately I want to get UML using pt_regs syscalls too, and this
would go away along with the hacks in syscalltbl.sh.
--
Brian Gerst
Powered by blists - more mailing lists