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
On Tue, Jan 15, 2008 at 04:14:54PM +0100, Peter Zijlstra wrote:
> Humm, we were trying to get rid of file_list_lock(), this puts up
> another user of the sb file list.
>
> Also, that loop looks horribly expensive: n*(1+m); where n is the list
> size, and m the number of matching fds.
>
> Granted,
On Fri, 2007-12-14 at 17:16 +0200, Pekka J Enberg wrote:
> +static int revoke_files(struct inode *inode)
> +{
> + struct super_block *sb;
> + struct file *file;
> + int err = 0;
> +
> + sb = inode->i_sb;
> + if (!sb)
> + return -EINVAL;
> +
> +restart:
> + file
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
4 matches
Mail list logo
