From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Helge Deller <deller@gmx.de>
Cc: Eric Paris <eparis@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-parisc@vger.kernel.org,
James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel
Date: Fri, 04 Jul 2014 18:48:33 +0200 [thread overview]
Message-ID: <53B6DAE1.1040709@gmx.de> (raw)
In-Reply-To: <20140704151235.GA22454@ls3530.dhcp.wdf.sap.corp>
On 04.07.2014 17:12, Helge Deller wrote:
> This patch affects big endian architectures only.
>
> On those with 32bit userspace and 64bit kernel (CONFIG_COMPAT=y) the
> 64bit mask parameter is correctly constructed out of two 32bit values in
> the compat_fanotify_mark() function and then passed as 64bit parameter
> to the fanotify_mark() syscall.
>
> But for the CONFIG_COMPAT=n case (32bit kernel & userspace),
> compat_fanotify_mark() isn't used and the fanotify_mark syscall implementation
I was not able to find a symbol compat_fanotify_mark. Could you, please,
indicate were this coding is.
> is used directly. In that case the upper and lower 32 bits of the 64bit mask
> parameter is still swapped on big endian machines and thus leads to
> fanotify_mark failing with -EINVAL.
>
> Here is a strace of the same 32bit executable (fanotify01 testcase from LTP):
https://github.com/linux-test-project/ltp
testcases/kernel/syscalls/fanotify/fanotify01.c
I guess.
>
> On a 64bit kernel it suceeds:
> syscall_322(0, 0, 0x3, 0x3, 0x266c8, 0x1) = 0x3
> syscall_323(0x3, 0x1, 0, 0x3b, 0xffffff9c, 0x266c8) = 0
>
> On a 32bit kernel it fails:
> syscall_322(0, 0, 0x3, 0x3, 0x266c8, 0x1) = 0x3
> syscall_323(0x3, 0x1, 0, 0x3b, 0xffffff9c, 0x266c8) = -1 (errno 22)
The syscall numbers are architecture specific.
Which architecture did you test on?
>
> Below is the easiest fix for this problem by simply swapping the upper and
> lower 32bit of the 64 bit mask parameter when building a pure 32bit kernel.
The problem you report is architecture specific.
Is fanotify_user.c really the right place for the correction?
Or should the fix be in the "arch" directory?
Best regards
Heinrich Schuchardt
>
> But on the other side, using __u64 in a syscall API is IMHO wrong. This may
> easily break 32bit kernel builds, esp. on big endian machines.
>
> The clean solution would probably be to use SYSCALL_DEFINE5() when
> building a 64bit-kernel, and SYSCALL_DEFINE6() for fanotify_mark() when
> building a pure 32bit kernel, something like this:
>
> #ifdef CONFIG_64BIT
> SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, unsigned int, flags,
> __u64, mask, int, dfd,
> const char __user *, pathname)
> #else
> SYSCALL_DEFINE6(fanotify_mark, int, fanotify_fd, unsigned int, flags,
> __u32, mask0, __u32, mask1, int, dfd,
> const char __user *, pathname)
> #endif
>
>
> Signed-off-by: Helge Deller <deller@gmx.de>
> To: Eric Paris <eparis@redhat.com>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 3fdc8a3..374261c 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -787,6 +787,10 @@ SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, unsigned int, flags,
> struct path path;
> int ret;
>
> +#if defined(__BIG_ENDIAN) && !defined(CONFIG_64BIT)
> + mask = (mask << 32) | (mask >> 32);
> +#endif
> +
> pr_debug("%s: fanotify_fd=%d flags=%x dfd=%d pathname=%p mask=%llx\n",
> __func__, fanotify_fd, flags, dfd, pathname, mask);
>
>
next prev parent reply other threads:[~2014-07-04 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 15:12 [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel Helge Deller
2014-07-04 16:48 ` Heinrich Schuchardt [this message]
2014-07-04 17:03 ` Helge Deller
2014-07-06 9:15 ` Heiko Carstens
2014-07-06 15:08 ` John David Anglin
2014-07-07 13:54 ` Aw: " Helge Deller
2014-07-07 15:28 ` Heiko Carstens
2014-07-11 8:00 ` [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel [SOLVED] Helge Deller
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=53B6DAE1.1040709@gmx.de \
--to=xypron.glpk@gmx.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=deller@gmx.de \
--cc=eparis@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.