Re: [RFC/PATCH] revokeat/frevoke system calls V5
On Feb 26, 2007, at 13:46:21, H. Peter Anvin wrote:
Alan wrote:
I'm not sure. Turning, for example, the statat(dir_fd, name ==
NULL) error case into fstat(dir_fd) sounds like a way for apps,
admittedly buggy ones, to be surprised. Maybe libc would be
exptected to catch the error before performing the shared system
call?
At that point would it not be cheaper to have two system calls,
the table cost isn't very large.
It's not just the table, though, you need two entry points, but
even that isn't really all that big either, I guess.
Well, I suppose there are multiple possibilities for consolidation:
frevokeat(fd, "/foo/bar/baz") => normal frevokeat
frevokeat(-1, "/foo/bar/baz") => revoke("/foo/bar/baz");
frevokeat(fd, NULL) => frevoke(fd);
Neither of those would ordinarily be considered to do anything useful
and for new syscalls I can't see the possibility of breaking existing
programs. On the other hand, it's not like we have any problems with
the syscall tables getting too large.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Alan wrote: I'm not sure. Turning, for example, the statat(dir_fd, name == NULL) error case into fstat(dir_fd) sounds like a way for apps, admittedly buggy ones, to be surprised. Maybe libc would be exptected to catch the error before performing the shared system call? At that point would it not be cheaper to have two system calls, the table cost isn't very large. It's not just the table, though, you need two entry points, but even that isn't really all that big either, I guess. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
> I'm not sure. Turning, for example, the statat(dir_fd, name == NULL) > error case into fstat(dir_fd) sounds like a way for apps, admittedly > buggy ones, to be surprised. Maybe libc would be exptected to catch > the error before performing the shared system call? At that point would it not be cheaper to have two system calls, the table cost isn't very large. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
I'm not sure. Turning, for example, the statat(dir_fd, name == NULL) error case into fstat(dir_fd) sounds like a way for apps, admittedly buggy ones, to be surprised. Maybe libc would be exptected to catch the error before performing the shared system call? At that point would it not be cheaper to have two system calls, the table cost isn't very large. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Alan wrote: I'm not sure. Turning, for example, the statat(dir_fd, name == NULL) error case into fstat(dir_fd) sounds like a way for apps, admittedly buggy ones, to be surprised. Maybe libc would be exptected to catch the error before performing the shared system call? At that point would it not be cheaper to have two system calls, the table cost isn't very large. It's not just the table, though, you need two entry points, but even that isn't really all that big either, I guess. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
On Feb 26, 2007, at 13:46:21, H. Peter Anvin wrote: Alan wrote: I'm not sure. Turning, for example, the statat(dir_fd, name == NULL) error case into fstat(dir_fd) sounds like a way for apps, admittedly buggy ones, to be surprised. Maybe libc would be exptected to catch the error before performing the shared system call? At that point would it not be cheaper to have two system calls, the table cost isn't very large. It's not just the table, though, you need two entry points, but even that isn't really all that big either, I guess. Well, I suppose there are multiple possibilities for consolidation: frevokeat(fd, /foo/bar/baz) = normal frevokeat frevokeat(-1, /foo/bar/baz) = revoke(/foo/bar/baz); frevokeat(fd, NULL) = frevoke(fd); Neither of those would ordinarily be considered to do anything useful and for new syscalls I can't see the possibility of breaking existing programs. On the other hand, it's not like we have any problems with the syscall tables getting too large. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Pekka Enberg wrote: Hi Alan, On 2/26/07, Alan <[EMAIL PROTECTED]> wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/utils/ What they are lacking is review so I am not sure how to proceed with the patches. On this general subject, would it make sense to, for the future, have system calls of the -at() form only, and specify that the f- system calls take (fd, NULL) as the (file descriptor, filename) tuple? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hi Alan, On 2/26/07, Alan <[EMAIL PROTECTED]> wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/utils/ What they are lacking is review so I am not sure how to proceed with the patches. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Whats the status on this, I was suprised to see something so important just go dead ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Whats the status on this, I was suprised to see something so important just go dead ? Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hi Alan, On 2/26/07, Alan [EMAIL PROTECTED] wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/utils/ What they are lacking is review so I am not sure how to proceed with the patches. Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Pekka Enberg wrote: Hi Alan, On 2/26/07, Alan [EMAIL PROTECTED] wrote: Whats the status on this, I was suprised to see something so important just go dead ? It's not dead. You can find the latest patches here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/patches/ and user-space tests here: http://www.cs.helsinki.fi/u/penberg/linux/revoke/utils/ What they are lacking is review so I am not sure how to proceed with the patches. On this general subject, would it make sense to, for the future, have system calls of the -at() form only, and specify that the f- system calls take (fd, NULL) as the (file descriptor, filename) tuple? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
On Wed 07-02-07 12:50:34, Pekka J Enberg wrote: > Hi Honza, > > On Wed, 7 Feb 2007, Jan Kara wrote: > > Have you considered using similar hack as bad_inode.c instead of > > revoked_inode.c? > > I am not sure what you mean, revoked_inode.c looks pretty much the same as > bad_inode.c in mainline... Oops, sorry for confusion. I was looking into 2.6.19 and there the code looks differently. In 2.6.20, obviously your method was preferred. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hi Honza, On Wed, 7 Feb 2007, Jan Kara wrote: > Have you considered using similar hack as bad_inode.c instead of > revoked_inode.c? I am not sure what you mean, revoked_inode.c looks pretty much the same as bad_inode.c in mainline... Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hello,
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> The revokeat(2) and frevoke(2) system calls invalidate open file
> descriptors and shared mappings of an inode. After an successful
> revocation, operations on file descriptors fail with the EBADF or
> ENXIO error code for regular and device files,
> respectively. Attempting to read from or write to a revoked mapping
> causes SIGBUS.
>
> The actual operation is done in two passes:
>
> 1. Revoke all file descriptors that point to the given inode. We do
> this under tasklist_lock so that after this pass, we don't need
> to worry about racing with close(2) or dup(2).
>
> 2. Take down shared memory mappings of each revoked file and close
> the file pointer.
>
> The file descriptors are kept until the owning task does close(2) and
> memory mapping ranges preserved until the owning task does munmap(2).
>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
Have you considered using similar hack as bad_inode.c instead of
revoked_inode.c?
> Index: 2.6/fs/revoked_inode.c
> ===
> --- /dev/null
> +++ 2.6/fs/revoked_inode.c
> @@ -0,0 +1,664 @@
> +/*
> + * linux/fs/revoked_inode.c
> + *
> + * Copyright (C) 1997, Stephen Tweedie
> + *
> + * Provide stub functions for revoked inodes
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static loff_t revoked_file_llseek(struct file *file, loff_t offset, int
> origin)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_read(struct file *filp, char __user * buf,
> + size_t size, loff_t * ppos)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_write(struct file *filp, const char __user * buf,
> + size_t siz, loff_t * ppos)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_aio_read(struct kiocb *iocb,
> + const struct iovec *iov,
> + unsigned long nr_segs, loff_t pos)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_aio_write(struct kiocb *iocb,
> + const struct iovec *iov,
> + unsigned long nr_segs, loff_t pos)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_readdir(struct file *filp, void *dirent,
> + filldir_t filldir)
> +{
> + return -EBADF;
> +}
> +
> +static unsigned int revoked_file_poll(struct file *filp, poll_table * wait)
> +{
> + return POLLERR;
> +}
> +
> +static int revoked_file_ioctl(struct inode *inode, struct file *filp,
> + unsigned int cmd, unsigned long arg)
> +{
> + return -EBADF;
> +}
> +
> +static long revoked_file_unlocked_ioctl(struct file *file, unsigned cmd,
> + unsigned long arg)
> +{
> + return -EBADF;
> +}
> +
> +static long revoked_file_compat_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_open(struct inode *inode, struct file *filp)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_flush(struct file *file, fl_owner_t id)
> +{
> + return 0;
> +}
> +
> +static int revoked_file_release(struct inode *inode, struct file *filp)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_fsync(struct file *file, struct dentry *dentry,
> + int datasync)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_aio_fsync(struct kiocb *iocb, int datasync)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_fasync(int fd, struct file *filp, int on)
> +{
> + return -EBADF;
> +}
> +
> +static int revoked_file_lock(struct file *file, int cmd, struct file_lock
> *fl)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_sendfile(struct file *in_file, loff_t * ppos,
> + size_t count, read_actor_t actor,
> + void *target)
> +{
> + return -EBADF;
> +}
> +
> +static ssize_t revoked_file_sendpage(struct file *file, struct page *page,
> + int off, size_t len, loff_t * pos,
> + int more)
> +{
> + return -EBADF;
> +}
> +
> +static unsigned long revoked_file_get_unmapped_area(struct file *file,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + return -EBADF;
> +}
> +
> +static int
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hello,
From: Pekka Enberg [EMAIL PROTECTED]
The revokeat(2) and frevoke(2) system calls invalidate open file
descriptors and shared mappings of an inode. After an successful
revocation, operations on file descriptors fail with the EBADF or
ENXIO error code for regular and device files,
respectively. Attempting to read from or write to a revoked mapping
causes SIGBUS.
The actual operation is done in two passes:
1. Revoke all file descriptors that point to the given inode. We do
this under tasklist_lock so that after this pass, we don't need
to worry about racing with close(2) or dup(2).
2. Take down shared memory mappings of each revoked file and close
the file pointer.
The file descriptors are kept until the owning task does close(2) and
memory mapping ranges preserved until the owning task does munmap(2).
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
Have you considered using similar hack as bad_inode.c instead of
revoked_inode.c?
Index: 2.6/fs/revoked_inode.c
===
--- /dev/null
+++ 2.6/fs/revoked_inode.c
@@ -0,0 +1,664 @@
+/*
+ * linux/fs/revoked_inode.c
+ *
+ * Copyright (C) 1997, Stephen Tweedie
+ *
+ * Provide stub functions for revoked inodes
+ */
+
+#include linux/fs.h
+#include linux/module.h
+#include linux/stat.h
+#include linux/time.h
+#include linux/smp_lock.h
+#include linux/namei.h
+#include linux/poll.h
+
+static loff_t revoked_file_llseek(struct file *file, loff_t offset, int
origin)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_read(struct file *filp, char __user * buf,
+ size_t size, loff_t * ppos)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_write(struct file *filp, const char __user * buf,
+ size_t siz, loff_t * ppos)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_aio_read(struct kiocb *iocb,
+ const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_aio_write(struct kiocb *iocb,
+ const struct iovec *iov,
+ unsigned long nr_segs, loff_t pos)
+{
+ return -EBADF;
+}
+
+static int revoked_file_readdir(struct file *filp, void *dirent,
+ filldir_t filldir)
+{
+ return -EBADF;
+}
+
+static unsigned int revoked_file_poll(struct file *filp, poll_table * wait)
+{
+ return POLLERR;
+}
+
+static int revoked_file_ioctl(struct inode *inode, struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ return -EBADF;
+}
+
+static long revoked_file_unlocked_ioctl(struct file *file, unsigned cmd,
+ unsigned long arg)
+{
+ return -EBADF;
+}
+
+static long revoked_file_compat_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ return -EBADF;
+}
+
+static int revoked_file_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ return -EBADF;
+}
+
+static int revoked_file_open(struct inode *inode, struct file *filp)
+{
+ return -EBADF;
+}
+
+static int revoked_file_flush(struct file *file, fl_owner_t id)
+{
+ return 0;
+}
+
+static int revoked_file_release(struct inode *inode, struct file *filp)
+{
+ return -EBADF;
+}
+
+static int revoked_file_fsync(struct file *file, struct dentry *dentry,
+ int datasync)
+{
+ return -EBADF;
+}
+
+static int revoked_file_aio_fsync(struct kiocb *iocb, int datasync)
+{
+ return -EBADF;
+}
+
+static int revoked_file_fasync(int fd, struct file *filp, int on)
+{
+ return -EBADF;
+}
+
+static int revoked_file_lock(struct file *file, int cmd, struct file_lock
*fl)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_sendfile(struct file *in_file, loff_t * ppos,
+ size_t count, read_actor_t actor,
+ void *target)
+{
+ return -EBADF;
+}
+
+static ssize_t revoked_file_sendpage(struct file *file, struct page *page,
+ int off, size_t len, loff_t * pos,
+ int more)
+{
+ return -EBADF;
+}
+
+static unsigned long revoked_file_get_unmapped_area(struct file *file,
+ unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags)
+{
+ return -EBADF;
+}
+
+static int revoked_file_check_flags(int flags)
+{
+ return -EBADF;
+}
+
+static int
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Hi Honza, On Wed, 7 Feb 2007, Jan Kara wrote: Have you considered using similar hack as bad_inode.c instead of revoked_inode.c? I am not sure what you mean, revoked_inode.c looks pretty much the same as bad_inode.c in mainline... Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
On Wed 07-02-07 12:50:34, Pekka J Enberg wrote: Hi Honza, On Wed, 7 Feb 2007, Jan Kara wrote: Have you considered using similar hack as bad_inode.c instead of revoked_inode.c? I am not sure what you mean, revoked_inode.c looks pretty much the same as bad_inode.c in mainline... Oops, sorry for confusion. I was looking into 2.6.19 and there the code looks differently. In 2.6.20, obviously your method was preferred. Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Quoting Pekka J Enberg ([EMAIL PROTECTED]): > From: Pekka Enberg <[EMAIL PROTECTED]> > > The revokeat(2) and frevoke(2) system calls invalidate open file > descriptors and shared mappings of an inode. After an successful > revocation, operations on file descriptors fail with the EBADF or > ENXIO error code for regular and device files, > respectively. Attempting to read from or write to a revoked mapping > causes SIGBUS. > > The actual operation is done in two passes: > > 1. Revoke all file descriptors that point to the given inode. We do > this under tasklist_lock so that after this pass, we don't need > to worry about racing with close(2) or dup(2). > > 2. Take down shared memory mappings of each revoked file and close > the file pointer. > > The file descriptors are kept until the owning task does close(2) and > memory mapping ranges preserved until the owning task does munmap(2). With the attached patch, this passes all your revoke tests on s390, as well as ltp runalltests.sh. thanks, -serge From: "Serge E. Hallyn" <[EMAIL PROTECTED]> Subject: [PATCH] revoke: do s390 syscalls revoke: do s390 syscalls Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]> (cherry picked from 9962b52d7bd7b70b99e7515d30b8217b0de491b3 commit) --- arch/s390/kernel/compat_wrapper.S | 11 +++ arch/s390/kernel/syscalls.S |2 ++ include/asm-s390/unistd.h |4 +++- 3 files changed, 16 insertions(+), 1 deletions(-) 3f0afa7b9a6b8c9ec930bdef73601f7260c79f47 diff --git a/arch/s390/kernel/compat_wrapper.S b/arch/s390/kernel/compat_wrapper.S index 71e54ef..b5c2bfa 100644 --- a/arch/s390/kernel/compat_wrapper.S +++ b/arch/s390/kernel/compat_wrapper.S @@ -1665,3 +1665,14 @@ sys_getcpu_wrapper: llgtr %r3,%r3 # unsigned * llgtr %r4,%r4 # struct getcpu_cache * jg sys_getcpu + + .globl sys_revokeat_wrapper +sys_revokeat_wrapper: + lgfr%r2,%r2 # int + llgtr %r3,%r3 # const char * + jg sys_revokeat + + .globl sys_frevoke_wrapper +sys_frevoke_wrapper: + llgfr %r2,%r2 # unsigned int + jg sys_frevoke diff --git a/arch/s390/kernel/syscalls.S b/arch/s390/kernel/syscalls.S index a4ceae3..85a6673 100644 --- a/arch/s390/kernel/syscalls.S +++ b/arch/s390/kernel/syscalls.S @@ -321,3 +321,5 @@ SYSCALL(sys_vmsplice,sys_vmsplice,compat NI_SYSCALL /* 310 sys_move_pages */ SYSCALL(sys_getcpu,sys_getcpu,sys_getcpu_wrapper) SYSCALL(sys_epoll_pwait,sys_epoll_pwait,sys_ni_syscall) +SYSCALL(sys_revokeat,sys_revokeat,sys_revokeat_wrapper) +SYSCALL(sys_frevoke,sys_frevoke,sys_frevoke_wrapper) diff --git a/include/asm-s390/unistd.h b/include/asm-s390/unistd.h index fb6fef9..6651cb1 100644 --- a/include/asm-s390/unistd.h +++ b/include/asm-s390/unistd.h @@ -250,8 +250,10 @@ /* Number 310 is reserved for new sys_move_pages */ #define __NR_getcpu311 #define __NR_epoll_pwait 312 +#define __NR_revokeat 313 +#define __NR_frevoke 314 -#define NR_syscalls 313 +#define NR_syscalls 315 /* * There are some system calls that are not present on 64 bit, some -- 1.1.6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] revokeat/frevoke system calls V5
Quoting Pekka J Enberg ([EMAIL PROTECTED]): From: Pekka Enberg [EMAIL PROTECTED] The revokeat(2) and frevoke(2) system calls invalidate open file descriptors and shared mappings of an inode. After an successful revocation, operations on file descriptors fail with the EBADF or ENXIO error code for regular and device files, respectively. Attempting to read from or write to a revoked mapping causes SIGBUS. The actual operation is done in two passes: 1. Revoke all file descriptors that point to the given inode. We do this under tasklist_lock so that after this pass, we don't need to worry about racing with close(2) or dup(2). 2. Take down shared memory mappings of each revoked file and close the file pointer. The file descriptors are kept until the owning task does close(2) and memory mapping ranges preserved until the owning task does munmap(2). With the attached patch, this passes all your revoke tests on s390, as well as ltp runalltests.sh. thanks, -serge From: Serge E. Hallyn [EMAIL PROTECTED] Subject: [PATCH] revoke: do s390 syscalls revoke: do s390 syscalls Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] (cherry picked from 9962b52d7bd7b70b99e7515d30b8217b0de491b3 commit) --- arch/s390/kernel/compat_wrapper.S | 11 +++ arch/s390/kernel/syscalls.S |2 ++ include/asm-s390/unistd.h |4 +++- 3 files changed, 16 insertions(+), 1 deletions(-) 3f0afa7b9a6b8c9ec930bdef73601f7260c79f47 diff --git a/arch/s390/kernel/compat_wrapper.S b/arch/s390/kernel/compat_wrapper.S index 71e54ef..b5c2bfa 100644 --- a/arch/s390/kernel/compat_wrapper.S +++ b/arch/s390/kernel/compat_wrapper.S @@ -1665,3 +1665,14 @@ sys_getcpu_wrapper: llgtr %r3,%r3 # unsigned * llgtr %r4,%r4 # struct getcpu_cache * jg sys_getcpu + + .globl sys_revokeat_wrapper +sys_revokeat_wrapper: + lgfr%r2,%r2 # int + llgtr %r3,%r3 # const char * + jg sys_revokeat + + .globl sys_frevoke_wrapper +sys_frevoke_wrapper: + llgfr %r2,%r2 # unsigned int + jg sys_frevoke diff --git a/arch/s390/kernel/syscalls.S b/arch/s390/kernel/syscalls.S index a4ceae3..85a6673 100644 --- a/arch/s390/kernel/syscalls.S +++ b/arch/s390/kernel/syscalls.S @@ -321,3 +321,5 @@ SYSCALL(sys_vmsplice,sys_vmsplice,compat NI_SYSCALL /* 310 sys_move_pages */ SYSCALL(sys_getcpu,sys_getcpu,sys_getcpu_wrapper) SYSCALL(sys_epoll_pwait,sys_epoll_pwait,sys_ni_syscall) +SYSCALL(sys_revokeat,sys_revokeat,sys_revokeat_wrapper) +SYSCALL(sys_frevoke,sys_frevoke,sys_frevoke_wrapper) diff --git a/include/asm-s390/unistd.h b/include/asm-s390/unistd.h index fb6fef9..6651cb1 100644 --- a/include/asm-s390/unistd.h +++ b/include/asm-s390/unistd.h @@ -250,8 +250,10 @@ /* Number 310 is reserved for new sys_move_pages */ #define __NR_getcpu311 #define __NR_epoll_pwait 312 +#define __NR_revokeat 313 +#define __NR_frevoke 314 -#define NR_syscalls 313 +#define NR_syscalls 315 /* * There are some system calls that are not present on 64 bit, some -- 1.1.6 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] revokeat/frevoke system calls V5
From: Pekka Enberg <[EMAIL PROTECTED]>
The revokeat(2) and frevoke(2) system calls invalidate open file
descriptors and shared mappings of an inode. After an successful
revocation, operations on file descriptors fail with the EBADF or
ENXIO error code for regular and device files,
respectively. Attempting to read from or write to a revoked mapping
causes SIGBUS.
The actual operation is done in two passes:
1. Revoke all file descriptors that point to the given inode. We do
this under tasklist_lock so that after this pass, we don't need
to worry about racing with close(2) or dup(2).
2. Take down shared memory mappings of each revoked file and close
the file pointer.
The file descriptors are kept until the owning task does close(2) and
memory mapping ranges preserved until the owning task does munmap(2).
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
arch/i386/kernel/syscall_table.S |3
fs/Makefile |2
fs/ext2/file.c |1
fs/ext3/file.c |1
fs/file_table.c |1
fs/revoke.c | 588 ++
fs/revoked_inode.c | 664 +++
include/asm-i386/unistd.h|4
include/linux/file.h | 14
include/linux/fs.h |6
include/linux/mm.h |2
include/linux/syscalls.h |3
mm/memory.c |3
mm/mmap.c| 11
14 files changed, 1298 insertions(+), 5 deletions(-)
Index: 2.6/arch/i386/kernel/syscall_table.S
===
--- 2.6.orig/arch/i386/kernel/syscall_table.S
+++ 2.6/arch/i386/kernel/syscall_table.S
@@ -319,3 +319,6 @@ ENTRY(sys_call_table)
.long sys_move_pages
.long sys_getcpu
.long sys_epoll_pwait
+ .long sys_revokeat /* 320 */
+ .long sys_frevoke
+
Index: 2.6/fs/Makefile
===
--- 2.6.orig/fs/Makefile
+++ 2.6/fs/Makefile
@@ -11,7 +11,7 @@ obj-y := open.o read_write.o file_table.
attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
- stack.o
+ stack.o revoke.o revoked_inode.o
ifeq ($(CONFIG_BLOCK),y)
obj-y += buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
Index: 2.6/fs/revoke.c
===
--- /dev/null
+++ 2.6/fs/revoke.c
@@ -0,0 +1,588 @@
+/*
+ * fs/revoke.c - Invalidate all current open file descriptors of an inode.
+ *
+ * Copyright (C) 2006-2007 Pekka Enberg
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * We pre-allocate an array of file pointers (including dummy inodes)
+ * so that we do not need to do kmalloc() under tasklist_lock. The
+ * revoke operation is done in two passes: first we revoke all fds
+ * pointing to an inode and then we do close/munmap in a second pass.
+ */
+struct revoke_table {
+ struct file **files;
+ unsigned long nr_files; /* capacity */
+ unsigned long nr_revoked; /* used in first pass */
+ unsigned long nr_closed;/* used in second pass */
+};
+
+struct kmem_cache *revokefs_inode_cache;
+
+/*
+ * Revoked file descriptors point to inodes in the revokefs filesystem.
+ */
+static struct vfsmount *revokefs_mnt;
+
+struct revokefs_inode_info {
+ struct task_struct *owner;
+ struct file *file;
+ unsigned int fd;
+ struct inode vfs_inode;
+};
+
+static inline struct revokefs_inode_info *REVOKEFS_I(struct inode *inode)
+{
+ return container_of(inode, struct revokefs_inode_info, vfs_inode);
+}
+
+extern void make_revoked_inode(struct inode *, int);
+
+static struct file *get_revoked_file(void)
+{
+ struct dentry *dentry;
+ struct inode *inode;
+ struct file *filp;
+ struct qstr name;
+
+ filp = get_empty_filp();
+ if (!filp)
+ goto err;
+
+ inode = new_inode(revokefs_mnt->mnt_sb);
+ if (!inode)
+ goto err_inode;
+
+ name.name = "revoked_file";
+ name.len = strlen(name.name);
+ dentry = d_alloc(revokefs_mnt->mnt_sb->s_root, );
+ if (!dentry)
+ goto err_dentry;
+
+ d_instantiate(dentry, inode);
+
+ filp->f_mapping = inode->i_mapping;
+ filp->f_dentry = dget(dentry);
+ filp->f_vfsmnt = mntget(revokefs_mnt);
+ filp->f_op = fops_get(inode->i_fop);
+ filp->f_pos = 0;
+
+ return filp;
+
+ err_dentry:
+ iput(inode);
+ err_inode:
+ fput(filp);
+ err:
+ return NULL;
+}
+
+static inline int
[RFC/PATCH] revokeat/frevoke system calls V5
From: Pekka Enberg [EMAIL PROTECTED]
The revokeat(2) and frevoke(2) system calls invalidate open file
descriptors and shared mappings of an inode. After an successful
revocation, operations on file descriptors fail with the EBADF or
ENXIO error code for regular and device files,
respectively. Attempting to read from or write to a revoked mapping
causes SIGBUS.
The actual operation is done in two passes:
1. Revoke all file descriptors that point to the given inode. We do
this under tasklist_lock so that after this pass, we don't need
to worry about racing with close(2) or dup(2).
2. Take down shared memory mappings of each revoked file and close
the file pointer.
The file descriptors are kept until the owning task does close(2) and
memory mapping ranges preserved until the owning task does munmap(2).
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
---
arch/i386/kernel/syscall_table.S |3
fs/Makefile |2
fs/ext2/file.c |1
fs/ext3/file.c |1
fs/file_table.c |1
fs/revoke.c | 588 ++
fs/revoked_inode.c | 664 +++
include/asm-i386/unistd.h|4
include/linux/file.h | 14
include/linux/fs.h |6
include/linux/mm.h |2
include/linux/syscalls.h |3
mm/memory.c |3
mm/mmap.c| 11
14 files changed, 1298 insertions(+), 5 deletions(-)
Index: 2.6/arch/i386/kernel/syscall_table.S
===
--- 2.6.orig/arch/i386/kernel/syscall_table.S
+++ 2.6/arch/i386/kernel/syscall_table.S
@@ -319,3 +319,6 @@ ENTRY(sys_call_table)
.long sys_move_pages
.long sys_getcpu
.long sys_epoll_pwait
+ .long sys_revokeat /* 320 */
+ .long sys_frevoke
+
Index: 2.6/fs/Makefile
===
--- 2.6.orig/fs/Makefile
+++ 2.6/fs/Makefile
@@ -11,7 +11,7 @@ obj-y := open.o read_write.o file_table.
attr.o bad_inode.o file.o filesystems.o namespace.o aio.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o drop_caches.o splice.o sync.o utimes.o \
- stack.o
+ stack.o revoke.o revoked_inode.o
ifeq ($(CONFIG_BLOCK),y)
obj-y += buffer.o bio.o block_dev.o direct-io.o mpage.o ioprio.o
Index: 2.6/fs/revoke.c
===
--- /dev/null
+++ 2.6/fs/revoke.c
@@ -0,0 +1,588 @@
+/*
+ * fs/revoke.c - Invalidate all current open file descriptors of an inode.
+ *
+ * Copyright (C) 2006-2007 Pekka Enberg
+ *
+ * This file is released under the GPLv2.
+ */
+
+#include linux/file.h
+#include linux/fs.h
+#include linux/namei.h
+#include linux/mm.h
+#include linux/mman.h
+#include linux/module.h
+#include linux/mount.h
+#include linux/sched.h
+
+/*
+ * We pre-allocate an array of file pointers (including dummy inodes)
+ * so that we do not need to do kmalloc() under tasklist_lock. The
+ * revoke operation is done in two passes: first we revoke all fds
+ * pointing to an inode and then we do close/munmap in a second pass.
+ */
+struct revoke_table {
+ struct file **files;
+ unsigned long nr_files; /* capacity */
+ unsigned long nr_revoked; /* used in first pass */
+ unsigned long nr_closed;/* used in second pass */
+};
+
+struct kmem_cache *revokefs_inode_cache;
+
+/*
+ * Revoked file descriptors point to inodes in the revokefs filesystem.
+ */
+static struct vfsmount *revokefs_mnt;
+
+struct revokefs_inode_info {
+ struct task_struct *owner;
+ struct file *file;
+ unsigned int fd;
+ struct inode vfs_inode;
+};
+
+static inline struct revokefs_inode_info *REVOKEFS_I(struct inode *inode)
+{
+ return container_of(inode, struct revokefs_inode_info, vfs_inode);
+}
+
+extern void make_revoked_inode(struct inode *, int);
+
+static struct file *get_revoked_file(void)
+{
+ struct dentry *dentry;
+ struct inode *inode;
+ struct file *filp;
+ struct qstr name;
+
+ filp = get_empty_filp();
+ if (!filp)
+ goto err;
+
+ inode = new_inode(revokefs_mnt-mnt_sb);
+ if (!inode)
+ goto err_inode;
+
+ name.name = revoked_file;
+ name.len = strlen(name.name);
+ dentry = d_alloc(revokefs_mnt-mnt_sb-s_root, name);
+ if (!dentry)
+ goto err_dentry;
+
+ d_instantiate(dentry, inode);
+
+ filp-f_mapping = inode-i_mapping;
+ filp-f_dentry = dget(dentry);
+ filp-f_vfsmnt = mntget(revokefs_mnt);
+ filp-f_op = fops_get(inode-i_fop);
+ filp-f_pos = 0;
+
+ return filp;
+
+ err_dentry:
+ iput(inode);
+ err_inode:
+
