From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-arch@vger.kernel.org,
Frederic Weisbecker <fweisbec@gmail.com>,
Li Zefan <lizf@cn.fujitsu.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: sys_fanotify_mark (again)
Date: Sun, 22 Nov 2009 10:05:19 +0100 [thread overview]
Message-ID: <20091122090519.GA3974@osiris.boeblingen.de.ibm.com> (raw)
Hi Eric,
as I can see you changed the syscall interface for sys_fanotify_mark to:
asmlinkage long sys_fanotify_mark(int fanotify_fd, unsigned int flags,
__u64 mask, int dfd,
const char __user * pathname)
Please note that you need the patch below in addition, otherwise the
syscall wrapper stuff won't work on those 32 bit architectures which enable
the wrappers.
When enabled the syscall wrapper defines always take long parameters and then
cast them to whatever is needed. This approach doesn't work for the 32 bit
case where the original syscall takes a long long parameter, since we would
lose the upper 32 bits.
So syscalls with 64 bit arguments are special cases wrt to syscall wrappers
and enp up in the ugliness below (see also sys_fallocate). In addition these
special cased syscall wrappers have the drawback that ftrace syscall tracing
doesn't work on them, since they don't get defined by using the usual macros.
Considering that fanotify_mark doesn't look performance critical to the point
that one would start count instructions I would propose the following
interface:
asmlinkage long sys_fanotify_mark(int fanotify_fd, unsigned int flags,
int dfd, const char __user * pathname,
u32 mask_high, u32 mask_low)
As already pointed out by Ralf this also has the advantage that no special
compat syscall handling is needed which otherwise would have to merge the
upper and lower 32 bits of the mask parameter in case of 32 bit userspace
and 64 bit kernel.
Alternatively you could also fix the syscall wrapper stuff to automatically
do the right thing for long long parameters. But I wouldn't how... except
with hpa's proposed automatic syscall wrapper creation engine :)
---
fs/notify/fanotify/fanotify_user.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
Index: linux-next/fs/notify/fanotify/fanotify_user.c
===================================================================
--- linux-next.orig/fs/notify/fanotify/fanotify_user.c
+++ linux-next/fs/notify/fanotify/fanotify_user.c
@@ -473,8 +473,9 @@ out_put_group:
return fd;
}
-SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, unsigned int, flags,
- __u64, mask, int, dfd, const char __user *, pathname)
+SYSCALL_DEFINE(fanotify_mark)(int fanotify_fd, unsigned int flags,
+ __u64 mask, int dfd,
+ const char __user * pathname)
{
struct inode *inode;
struct fsnotify_group *group;
@@ -518,6 +519,17 @@ fput_and_out:
return ret;
}
+#ifdef CONFIG_HAVE_SYSCALL_WRAPPERS
+asmlinkage long SyS_fanotify_mark(long fanotify_fd, long flags, __u64 mask,
+ long dfd, long pathname)
+{
+ return SYSC_fanotify_mark((int) fanotify_fd, (unsigned int) flags,
+ mask, (int) dfd,
+ (const char __user *) pathname);
+}
+SYSCALL_ALIAS(sys_fanotify_mark, SyS_fanotify_mark);
+#endif
+
/*
* fanotify_user_setup - Our initialization function. Note that we cannnot return
* error because we have compiled-in VFS hooks. So an (unlikely) failure here
next reply other threads:[~2009-11-22 9:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-22 9:05 Heiko Carstens [this message]
2009-11-23 3:05 ` sys_fanotify_mark (again) H. Peter Anvin
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=20091122090519.GA3974@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=eparis@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
/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).