Re: [PATCH] [2/11] Add unlocked_fasync

[Randy Dunlap]

On Tue, 20 May 2008 17:28:43 +0200 (CEST) Andi Kleen wrote:

> 
> Add a new fops entry point to allow fasync without BKL. While it's arguably
> unclear this entry point is called often enough for it really matters
> it was still relatively easy to do. And there are far less async users
> in the tree than ioctls so it's likely they can be all converted 
> eventually and then the non unlocked async entry point could be dropped.
> 
> There was still the problem of the actual flags change being
> protected against other setters of flags. Instead of using BKL
> for this use the i_mutex now.
> 
> I also added a mutex_lock against one other flags change
> that was lockless and could potentially lose updates.
> 
> There are a couple of potential problems I added comments about on.
> 
> Signed-off-by: Andi Kleen <ak@xxxxxxx>
> Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> 
> ---
>  Documentation/filesystems/vfs.txt |    5 ++++-
>  fs/fcntl.c                        |   22 +++++++++++++++-------
>  fs/ioctl.c                        |   13 ++++++++++++-
>  include/linux/fs.h                |    1 +
>  4 files changed, 32 insertions(+), 9 deletions(-)

> Index: linux/Documentation/filesystems/vfs.txt
> ===================================================================
> --- linux.orig/Documentation/filesystems/vfs.txt
> +++ linux/Documentation/filesystems/vfs.txt
> @@ -755,6 +755,7 @@ struct file_operations {
>  	int (*fsync) (struct file *, struct dentry *, int datasync);
>  	int (*aio_fsync) (struct kiocb *, int datasync);
>  	int (*fasync) (int, struct file *, int);
> +	int (*unlocked_fasync) (int, struct file *, int);
>  	int (*lock) (struct file *, int, struct file_lock *);
>  	ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
>  	ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
> @@ -814,7 +815,9 @@ otherwise noted.
>    fsync: called by the fsync(2) system call
>  
>    fasync: called by the fcntl(2) system call when asynchronous
> -	(non-blocking) mode is enabled for a file
> +	(non-blocking) mode is enabled for a file. BKL hold

	                                           BKL held.
so is that BKL must be held by the caller or this function
holds the BKL?

> +
> +  unlocked_fasync: like fasync, but without BKL
>  
>    lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
>    	commands


---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/