linux-kernel - Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Jan 2009 06:51:04 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jonathan Corbet <corbet@....net>
Cc:	linux-kernel@...r.kernel.org, andi@...stfloor.org,
	viro@...IV.linux.org.uk, oleg@...hat.com,
	linux-api@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325

> On Thu, 15 Jan 2009 15:32:11 -0700 Jonathan Corbet <corbet@....net> wrote:
> One of these years I've got to get this right.  I've fixed the problem
> pointed out by Oleg where f_flags would get changed even if fasync()
> fails.  
> 
> I have also taken out the ABI change.  CCing the linux-api list because
> I still think it's not quite right; fcntl() should not silently let
> applications set the FASYNC flag if the underlying driver/filesystem
> does not support it.  But that's How We've Always Done It, and one
> messes with such things at great risk.  If we want fcntl() to return an
> error in this case, it's an easy change.
> 
> This one's against 2.6.29-rc1.  If I don't hear screaming, I'll drop
> this one into linux-next.
> 

scream.

> 
> jon
> 
> --
> 
> Accesses to the f_flags member of struct file involve read-modify-write
> cycles; they have traditionally been done in a racy way.  This patch
> introduces a global spinlock to protect f_flags against concurrent
> modifications.
> 
> Additionally, changes to the FASYNC flag and resulting calls to
> f_op->fasync() need to be done in an atomic manner.  Here, the BKL is
> removed and FASYNC modifications are protected with a mutex.
> 
> Signed-off-by: Jonathan Corbet <corbet@....net>
> ---
>  drivers/char/tty_io.c |    5 +--
>  fs/fcntl.c            |   65 +++++++++++++++++++++++++++++++++++++++----------
>  fs/ioctl.c            |   25 ++++---------------
>  fs/nfsd/vfs.c         |    5 +++-
>  include/linux/fs.h    |   17 +++++++++++++
>  5 files changed, 80 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index d33e5ab..8450316 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -2160,13 +2160,12 @@ static int fionbio(struct file *file, int __user *p)
>  	if (get_user(nonblock, p))
>  		return -EFAULT;
>  
> -	/* file->f_flags is still BKL protected in the fs layer - vomit */
> -	lock_kernel();
> +	lock_file_flags();
>  	if (nonblock)
>  		file->f_flags |= O_NONBLOCK;
>  	else
>  		file->f_flags &= ~O_NONBLOCK;
> -	unlock_kernel();
> +	unlock_file_flags();

OK, replacing a lock_kernel() with a spin_lock(&global_lock) is pretty
straightforwad.  But it's really really sad.  It basically leaves a great
big FIXME in there.  It'd be better to fix it.

We don't have a handy lock in struct file which could be borrowed.

- We could add one

- We could borrow file->f_path.dentry->d_inode->i_lock

- We could convert that field to long and use bitops (sounds nice?)

>  	return 0;
>  }
>  
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index cdc1419..ddd497d 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
>
> ...
>
> +/*
> + * Change the setting of fasync, let the driver know.
> + * Not static because ioctl_fioasync() uses it too.
> + */
> +int fasync_change(int fd, struct file *filp, int on)
> +{
> +	int ret = 0;
> +	static DEFINE_MUTEX(fasync_mutex);
> +
> +	if (filp->f_op->fasync == NULL)
> +		return -ENOTTY;
> +
> +	mutex_lock(&fasync_mutex);
> +	/* Can test without flags lock, nobody else will change it */
> +	if (((filp->f_flags & FASYNC) == 0) == (on == 0))
> +		goto out;
> +	ret = filp->f_op->fasync(fd, filp, on);
> +	if (ret >= 0) {
> +		lock_file_flags();
> +		if (on)
> +			filp->f_flags |= FASYNC;
> +		else
> +			filp->f_flags &= ~FASYNC;
> +		unlock_file_flags();
> +	}
> +  out:

column zero, please.

> +	mutex_unlock(&fasync_mutex);
> +	return ret;
> +}

It isn't completely obvious what fasync_mutex is protecting, why it exists.

A comment which explains this would be appropriate?


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