Re: [RFC/PATCH 4/8] revoke: core code V7

2008-01-16 Thread Pekka J Enberg
Hi, On Tue, 15 Jan 2008, Christoph Hellwig wrote: Something like the loop above is not going to go in for sure. Once we get rid of the sb-s_files we can put the list_head in struct file to new use eventually if we don't want to get rid of it. E.g. and per-inode list would be much better

Re: [RFC/PATCH 2/8] revoke: inode revoke lock V7

2007-12-19 Thread Pekka J Enberg
Hi Jonathan, (Thanks for the review!) On Tue, 18 Dec 2007, Jonathan Corbet wrote: This is a relatively minor detail in the rather bigger context of this patch, but... @@ -642,6 +644,7 @@ struct inode { struct list_headinotify_watches; /* watches on this inode */ struct

Re: [RFC/PATCH 2/8] revoke: inode revoke lock V7

2007-12-19 Thread Pekka J Enberg
Hi, On Wed, 19 Dec 2007, Serge E. Hallyn wrote: I assume you mean S_REVOKE_LOCK and not -i_mutex, right? No I did mean the i_mutex since you take the i_mutex when you set S_REVOKE_LOCK. So between that and the comment above do_lookup(), I assumed you were trying to lock out concurrent

Re: [RFC/PATCH 2/8] revoke: inode revoke lock V7

2007-12-17 Thread Pekka J Enberg
Hi Serge, (Thanks for looking at this. I appreciate the review!) On Mon, 17 Dec 2007, [EMAIL PROTECTED] wrote: struct vfsmount *mnt = nd-mnt; - struct dentry *dentry = __d_lookup(nd-dentry, name); + struct dentry *dentry; +again: + dentry = __d_lookup(nd-dentry, name);

[RFC/PATCH 8/8] revoke: add to documentation V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Add the -revoke() file operation to VFS documentation. Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL PROTECTED] ---

[RFC/PATCH 7/8] revoke: support for ext2 and ext3 V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Add revoke support to ext2, ext3 and ext4 by wiring f_ops-revoke with generic_file_revoke. Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Pekka Enberg

[RFC/PATCH 6/8] revoke: wire up i386 system call V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Make revokeat system call available to user-space on i386. [EMAIL PROTECTED]: fix 32-bit userspace] Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Pekka

[RFC/PATCH 5/8] revoke: add to makefile V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Add fs/revoke.c and fs/revoked_inode.c to build when CONFIG_MMU is enabled. Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL PROTECTED]

[RFC/PATCH 4/8] revoke: core code V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] The revokeat(2) system call ensures that after successful revocation you can only access an inode via a file descriptor that is obtained from a subsequent open(2) call. The open(2) system call can be blocked by the caller with chmod(2) and chown(2) prior to

[RFC/PATCH 3/8] revoke: file, inode, and address space operations V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Add file, inode, and addresspace operations for inodes that represent revoked files. Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc: Christoph Hellwig [EMAIL PROTECTED] Cc: Peter Zijlstra [EMAIL PROTECTED] Signed-off-by: Pekka Enberg [EMAIL

[RFC/PATCH 1/8] revoke: special mmap handling V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] This adds special handling for revoked shared memory mappings. We want to raise SIGBUS if someone accesses a revoked mapping and return ENODEV if somebody tries to remap one with mmap(2). Cc: Alan Cox [EMAIL PROTECTED] Cc: Al Viro [EMAIL PROTECTED] Cc:

[RFC/PATCH 2/8] revoke: inode revoke lock V7

2007-12-14 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] The revoke operation cannibalizes the revoked struct inode and removes it from the inode cache thus forcing subsequent callers to look up the real inode. Therefore we must make sure that while the revoke operation is in progress (e.g. flushing dirty pages to

Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland

2007-10-14 Thread Pekka J Enberg
Hi Erez, On Sun, 14 Oct 2007, Erez Zadok wrote: In unionfs_writepage() I tried to emulate as best possible what the lower f/s will have returned to the VFS. Since tmpfs's -writepage can return AOP_WRITEPAGE_ACTIVATE and re-mark its page as dirty, I did the same in unionfs: mark again my page

Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland

2007-10-07 Thread Pekka J Enberg
Hi Erez, On 10/7/07, Erez Zadok [EMAIL PROTECTED] wrote: Anyway, some Ubuntu users of Unionfs reported that msync(2) sometimes returns AOP_WRITEPAGE_ACTIVATE (decimal 524288) back to userland. Therefore, some user programs fail, esp. if they're written such as this: [snip] On 10/7/07, Erez

[RFC/PATCH 1/5] revoke: special mmap handling

2007-07-11 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] This adds special handling for revoked memory mappings. We want to raise SIGBUS when accessing revoked mappings and return ENODEV when trying to remap with mmap(2). Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- include/linux/mm.h |1 + mm/memory.c

[RFC/PATCH 2/5] revoke: core code

2007-07-11 Thread Pekka J Enberg
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.

[RFC/PATCH 3/5] revoke: wire up i386 system calls

2007-07-11 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Make revokeat and frevoke system calls available to user-space on i386. Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- arch/i386/kernel/syscall_table.S |2 ++ arch/x86_64/ia32/ia32entry.S |2 ++ include/asm-i386/unistd.h|4 +++- 3

[RFC/PATCH 4/5] revoke: support for ext2 and ext3

2007-07-11 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] Add revoke support to ext2, ext3 and ext4 by wiring f_ops-revoke with generic_file_revoke. Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- fs/ext2/file.c |1 + fs/ext3/file.c |1 + fs/ext4/file.c |1 + 3 files changed, 3 insertions(+) Index:

[RFC/PATCH 5/5] revoke: add documentation

2007-07-11 Thread Pekka J Enberg
From: Pekka Enberg [EMAIL PROTECTED] This documents revoke file operation in Documentation/filesystems/vfs.txt. Signed-off-by: Pekka Enberg [EMAIL PROTECTED] --- Documentation/filesystems/vfs.txt |5 + 1 file changed, 5 insertions(+) Index: 2.6/Documentation/filesystems/vfs.txt

Re: [RFC/PATCH 2/5] revoke: core code

2007-07-11 Thread Pekka J Enberg
Hi Al, On Wed, 11 Jul 2007, Al Viro wrote: Better: I have the only opened descriptor for foo. I send it to myself as described above. I close it. revoke() is called, finds no opened instances of foo in any descriptor tables and cheerfully does nothing. I call recvmsg() and I have

Re: [RFC/PATCH 2/5] revoke: core code

2007-07-11 Thread Pekka J Enberg
On Wed, 11 Jul 2007, Al Viro wrote: BTW, read() or write() in progress might get rather unhappy if your live replacement of -f_mapping races with them... For writes, we (1) never start any new operations after we've cleaned up the file descriptor tables so (2) after we're done with do_fsync()

Re: [RFC/PATCH 2/5] revoke: core code

2007-07-11 Thread Pekka J Enberg
Hi, On Wed, 11 Jul 2007, Al Viro wrote: The fundamental issue here is that even if you do find struct file, you can't blindly rip its -f_mapping since it can be in the middle of -read(), -write(), pageout, etc. And even if you do manage that, you still have the ability to do fchmod() later.

Re: [PATCH] LogFS take three

2007-05-16 Thread Pekka J Enberg
Hi Joern, +#define LOGFS_BUG(sb) do { \ + struct super_block *__sb = sb; \ + logfs_crash_dump(__sb); \ + BUG(); \ +} while(0) Note that BUG() can be a no-op so dumping something on disk might not make sense there. This seems useful,

Re: forced umount?

2007-03-26 Thread Pekka J Enberg
On Mon, 26 Mar 2007, Phillip Susi wrote: Is this revoke system supported for the filesystem as a whole? I thought it was just to force specific files closed, not the whole filesystem. What if the filesystem itself has pending IO to say, update inodes or block bitmaps? Can these be aborted?

Re: [RFC/PATCH] revokeat/frevoke system calls V5

2007-02-07 Thread Pekka J Enberg
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

[RFC/PATCH] revokeat/frevoke system calls V5

2007-01-28 Thread Pekka J Enberg
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.

Re: share/private/slave a subtree

2005-07-08 Thread Pekka J Enberg
On Fri, 8 Jul 2005, Pekka J Enberg wrote: Hey, I just review patches. I don't get to set requirements. There's a reason why enums are preferred though. They define a proper name for the constant. Roman Zippel writes: Who prefers that? Well, me, at least. I can't speak for others