Messages in this thread | | | Date | Fri, 21 Jul 2006 23:59:31 -0700 | From | Andrew Morton <> | Subject | Re: [RFC/PATCH] revoke/frevoke system calls |
| |
On Sat, 22 Jul 2006 09:22:37 +0300 (EEST) Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
> On Thu, 20 Jul 2006 15:07:30 +0300 (EEST) > Pekka J Enberg <penberg@cs.Helsinki.FI> wrote: > > > This patch implements the revoke(2) and frevoke(2) system calls for all > > > types of files. > > > > > > ... > > > > > > - file = fget_light(fd, &fput_needed); > > > + file = fget(fd); > > On Fri, 21 Jul 2006, Andrew Morton wrote: > > This is sad. > > There are alternatives, playing games with ->f_op, creating fake struct > file, and doing IS_REVOKED if-else in the paths, but I think this is by > far the simplest way to do it. So in the Andrew scale of sads, how > sad is it, exactly?-)
Sad enough. Certainly worth an if-else to fix.
> On Thu, 20 Jul 2006 15:07:30 +0300 (EEST) > Pekka J Enberg <penberg@cs.Helsinki.FI> wrote: > > > +static int revoke_files(struct task_struct *owner, struct inode *inode, > > > + struct file *exclude, struct list_head *to_close) > > > +{ > > > ... > > > + spin_lock(&files->file_lock); > > > ... > > > + revoked = kmalloc(sizeof(*revoked), GFP_KERNEL); > > On Fri, 21 Jul 2006, Andrew Morton wrote: > > This is bad. > > Indeed, I'll come up with a better one as soon as I sort out the mmap > takedown issues. >
Why is this approach so different from Tigran's, I wonder.
iirc, one of the things we added file.f_mapping for was revokation, but this patch doesn't use it. Please ask Al Viro about this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |