From: Andy Lutomirski <luto@kernel.org>
To: Andy Lutomirski <luto@kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Cc: "Brian Gerst" <brgerst@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, "X86 ML" <x86@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Thomas Gleixner" <tglx@linutronix.de>, "Jan Kara" <jack@suse.cz>,
"Paweł Jasiak" <pawel@jasiak.xyz>
Subject: Re: [PATCH] fanotify: Fix sys_fanotify_mark() on native x86-32
Date: Tue, 1 Dec 2020 09:34:32 -0800 [thread overview]
Message-ID: <CALCETrWbEvD4SO4GosJyeCmaT2BFwX8Xy+EF_D0x91np3k9OaA@mail.gmail.com> (raw)
In-Reply-To: <CALCETrWZ5eH=0Rjd-vBFRtk-tFQ3tN8_rReaKdVbSm78PFQ7_g@mail.gmail.com>
On Tue, Dec 1, 2020 at 9:23 AM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Mon, Nov 30, 2020 at 2:31 PM Brian Gerst <brgerst@gmail.com> wrote:
> >
> > Commit 121b32a58a3a converted native x86-32 which take 64-bit arguments to
> > use the compat handlers to allow conversion to passing args via pt_regs.
> > sys_fanotify_mark() was however missed, as it has a general compat handler.
> > Add a config option that will use the syscall wrapper that takes the split
> > args for native 32-bit.
> >
> > Reported-by: Paweł Jasiak <pawel@jasiak.xyz>
> > Fixes: 121b32a58a3a ("x86/entry/32: Use IA32-specific wrappers for syscalls taking 64-bit arguments")
> > Signed-off-by: Brian Gerst <brgerst@gmail.com>
> > ---
> > arch/Kconfig | 6 ++++++
> > arch/x86/Kconfig | 1 +
> > fs/notify/fanotify/fanotify_user.c | 17 +++++++----------
> > include/linux/syscalls.h | 24 ++++++++++++++++++++++++
> > 4 files changed, 38 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 090ef3566c56..452cc127c285 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -1045,6 +1045,12 @@ config HAVE_STATIC_CALL_INLINE
> > bool
> > depends on HAVE_STATIC_CALL
> >
> > +config ARCH_SPLIT_ARG64
> > + bool
> > + help
> > + If a 32-bit architecture requires 64-bit arguments to be split into
> > + pairs of 32-bit arguemtns, select this option.
>
> You misspelled arguments. You might also want to clarify that, for
> 64-bit arches, this means that compat syscalls split their arguments.
No, that's backwards. Maybe it should be depends !64BIT instead.
But I'm really quite confused about something: what's special about
x86 here? Are there really Linux arches (compat or 32-bit native)
that *don't* split arguments like this? Sure, some arches probably
work the same way that x86 used to in which the compiler did the
splitting by magic for us, but that was always a bit of a kludge.
Could this change maybe be made unconditional?
--Andy
>
> Aside from that:
>
> Acked-by: Andy Lutomirski <luto@kernel.org>
next parent reply other threads:[~2020-12-01 17:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201130223059.101286-1-brgerst@gmail.com>
[not found] ` <CALCETrWZ5eH=0Rjd-vBFRtk-tFQ3tN8_rReaKdVbSm78PFQ7_g@mail.gmail.com>
2020-12-01 17:34 ` Andy Lutomirski [this message]
2020-12-01 19:00 ` [PATCH] fanotify: Fix sys_fanotify_mark() on native x86-32 Catalin Marinas
2020-12-01 19:10 ` Andy Lutomirski
2020-12-01 19:19 ` Brian Gerst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrWbEvD4SO4GosJyeCmaT2BFwX8Xy+EF_D0x91np3k9OaA@mail.gmail.com \
--to=luto@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=jack@suse.cz \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pawel@jasiak.xyz \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).