linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Borislav Petkov <bp@alien8.de>
Cc: "Jan Kara" <jack@suse.cz>, "Paweł Jasiak" <pawel@jasiak.xyz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	x86@kernel.org, "Thomas Gleixner" <tglx@linutronix.de>,
	"Brian Gerst" <brgerst@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>
Subject: Re: PROBLEM: fanotify_mark EFAULT on x86
Date: Thu, 26 Nov 2020 11:48:27 +0100	[thread overview]
Message-ID: <20201126104827.GA422@quack2.suse.cz> (raw)
In-Reply-To: <20201124102814.GE4009@zn.tnic>

On Tue 24-11-20 11:28:14, Borislav Petkov wrote:
> On Tue, Nov 24, 2020 at 11:20:33AM +0100, Jan Kara wrote:
> > On Tue 24-11-20 09:45:07, Borislav Petkov wrote:
> > > On Mon, Nov 23, 2020 at 11:46:51PM +0100, Paweł Jasiak wrote:
> > > > On 23/11/20, Jan Kara wrote:
> > > > > OK, with a help of Boris Petkov I think I have a fix that looks correct
> > > > > (attach). Can you please try whether it works for you? Thanks!
> > > > 
> > > > Unfortunately I am getting a linker error.
> > > > 
> > > > ld: arch/x86/entry/syscall_32.o:(.rodata+0x54c): undefined reference to `__ia32_sys_ia32_fanotify_mark'
> > > 
> > > Because CONFIG_COMPAT is not set in your .config.
> > > 
> > > Jan, look at 121b32a58a3a and especially this hunk
> > > 
> > > diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> > > index 9b294c13809a..b8f89f78b8cd 100644
> > > --- a/arch/x86/kernel/Makefile
> > > +++ b/arch/x86/kernel/Makefile
> > > @@ -53,6 +53,8 @@ obj-y                 += setup.o x86_init.o i8259.o irqinit.o
> > >  obj-$(CONFIG_JUMP_LABEL)       += jump_label.o
> > >  obj-$(CONFIG_IRQ_WORK)  += irq_work.o
> > >  obj-y                  += probe_roms.o
> > > +obj-$(CONFIG_X86_32)   += sys_ia32.o
> > > +obj-$(CONFIG_IA32_EMULATION)   += sys_ia32.o
> > > 
> > > how it enables the ia32 syscalls depending on those config items. Now,
> > > you have
> > > 
> > >  #ifdef CONFIG_COMPAT
> > > -COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> > > +SYSCALL_DEFINE6(ia32_fanotify_mark,
> > > 
> > > which is under CONFIG_COMPAT which is not set in Paweł's config.
> > > 
> > > config COMPAT
> > >         def_bool y
> > >         depends on IA32_EMULATION || X86_X32
> > > 
> > > but it depends on those two config items.
> > > 
> > > However, it looks to me like ia32_fanotify_mark's definition should be
> > > simply under CONFIG_X86_32 because:
> > > 
> > > IA32_EMULATION is 32-bit emulation on 64-bit kernels
> > > X86_X32 is for the x32 ABI
> > 
> > Thanks for checking! I didn't realize I needed to change the ifdefs as well
> > (I missed that bit in 121b32a58a3a). So do I understand correctly that
> > whenever the kernel is 64-bit, 64-bit syscall args (e.g. defined as u64) are
> > passed just fine regardless of whether the userspace is 32-bit or not?
> > 
> > Also how about other 32-bit archs? Because I now realized that
> > CONFIG_COMPAT as well as the COMPAT_SYSCALL_DEFINE6() is also utilized by
> > other 32-bit archs (I can see a reference to compat_sys_fanotify_mark e.g.
> > in sparc, powerpc, and other args). So I probably need to actually keep
> > that for other archs but do the modification only for x86, don't I?
> 
> Hmm, you raise a good point and looking at that commit again, the
> intention is to supply those ia32 wrappers as both 32-bit native *and*
> 32-bit emulation ones.
> 
> So I think this
> 
> > -#ifdef CONFIG_COMPAT
> > +#if defined(CONFIG_COMPAT) || defined(CONFIG_X86_32)
> > +#ifdef CONFIG_X86_32
> > +SYSCALL_DEFINE6(ia32_fanotify_mark,
> > +#elif CONFIG_COMPAT
> >  COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> > +#endif
> 
> should be
> 
> if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
> SYSCALL_DEFINE6(ia32_fanotify_mark,
> #elif CONFIG_COMPAT
> COMPAT_SYSCALL_DEFINE6(fanotify_mark,
> #endif
> 
> or so.
> 
> Meaning that 32-bit native or 32-bit emulation supplies
> ia32_fanotify_mark() as a syscall wrapper and other arches doing
> CONFIG_COMPAT, still do the COMPAT_SYSCALL_DEFINE6() thing.

Yeah, looking again at what those config options mean I agree. Patch
updated.

> But I'd prefer if someone more knowledgeable than me in that whole
> syscall macros muck to have a look...

I'd prefer that as well but if nobody pops up, I'll just push this to my
tree next week and will see what breaks :)

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2020-11-26 10:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 21:27 PROBLEM: fanotify_mark EFAULT on x86 Paweł Jasiak
2020-11-01 21:38 ` Matthew Wilcox
2020-11-01 22:27   ` Paweł Jasiak
2020-11-02 12:26 ` Jan Kara
2020-11-02 17:16   ` Paweł Jasiak
2020-11-03 21:17   ` Paweł Jasiak
2020-11-04 10:14     ` Jan Kara
2020-11-23 16:46     ` Jan Kara
2020-11-23 22:46       ` Paweł Jasiak
2020-11-24  8:45         ` Borislav Petkov
2020-11-24 10:20           ` Jan Kara
2020-11-24 10:28             ` Borislav Petkov
2020-11-26 10:48               ` Jan Kara [this message]
2020-11-26 10:52                 ` Borislav Petkov
2020-11-25 19:31             ` Naresh Kamboju
2020-11-26 10:48               ` Jan Kara
2020-11-23 23:07       ` [PATCH] fanotify: Fix fanotify_mark() on 32-bit archs kernel test robot

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=20201126104827.GA422@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@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).