All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Matthew Wilcox <willy@debian.org>
Cc: Andrea Arcangeli <andrea@e-mind.com>, linux-kernel@vger.kernel.org
Subject: Re: O_DIRECT handling introduced a race in F_SETFL
Date: Fri, 5 Jul 2002 16:19:34 +0200	[thread overview]
Message-ID: <20020705141934.GI7734@dualathlon.random> (raw)
In-Reply-To: <20020702193019.C27706@parcelfarce.linux.theplanet.co.uk>

On Tue, Jul 02, 2002 at 07:30:19PM +0100, Matthew Wilcox wrote:
> 
> I was doing some random kernel janitoring, pushing the BKL down a
> little bit, when I noticed O_DIRECT introduced a race.  If alloc_kiovec
> sleeps, we will effectively be unprotected by the BKL.  This would
> allow two processes sharing an fd both changing the FASYNC flag to
> call f_op->fasync() the wrong number of times and potentially leave
> the application erroneously believing that fasync is off when it is on,
> or vice versa.
> 
> My patch below fixes this problem by allocating the O_DIRECT kiovec
> before taking the BKL.  Any comments?  Also, should we be freeing the
> kiovec when removing the O_DIRECT attribute from the filp?
> 
> diff -urNX dontdiff linux-2.5.24/fs/fcntl.c linux-2.5.24-mm/fs/fcntl.c
> --- linux-2.5.24/fs/fcntl.c	Sun Jun  9 06:09:49 2002
> +++ linux-2.5.24-mm/fs/fcntl.c	Tue Jul  2 10:55:29 2002
> @@ -235,24 +235,11 @@
>  	if (!(arg & O_APPEND) && IS_APPEND(inode))
>  		return -EPERM;
>  
> -	/* Did FASYNC state change? */
> -	if ((arg ^ filp->f_flags) & FASYNC) {
> -		if (filp->f_op && filp->f_op->fasync) {
> -			error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
> -			if (error < 0)
> -				return error;
> -		}
> -	}
> -
>  	if (arg & O_DIRECT) {
>  		/*
> -		 * alloc_kiovec() can sleep and we are only serialized by
> -		 * the big kernel lock here, so abuse the i_sem to serialize
> -		 * this case too. We of course wouldn't need to go deep down
> -		 * to the inode layer, we could stay at the file layer, but
> -		 * we don't want to pay for the memory of a semaphore in each
> -		 * file structure too and we use the inode semaphore that we just
> -		 * pay for anyways.
> +		 * alloc_kiovec() can sleep, so abuse the i_sem to serialize
> +		 * this case too.  Note we have to do this before we take the
> +		 * BKL otherwise we have a race if it sleeps.
>  		 */
>  		error = 0;
>  		down(&inode->i_sem);
> @@ -263,13 +250,26 @@
>  			return error;
>  	}
>  
> +	lock_kernel();
> +	/* Did FASYNC state change? */
> +	if ((arg ^ filp->f_flags) & FASYNC) {
> +		if (filp->f_op && filp->f_op->fasync) {
> +			error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
> +			if (error < 0)
> +				goto out;
> +		}
> +	}
> +
>  	/* required for strict SunOS emulation */
>  	if (O_NONBLOCK != O_NDELAY)
>  	       if (arg & O_NDELAY)
>  		   arg |= O_NONBLOCK;
>  
>  	filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
> -	return 0;
> +	error = 0;
> + out:
> +	unlock_kernel();
> +	return error;
>  }
>  
>  static long do_fcntl(unsigned int fd, unsigned int cmd,
> @@ -295,9 +295,7 @@
>  			err = filp->f_flags;
>  			break;
>  		case F_SETFL:
> -			lock_kernel();
>  			err = setfl(fd, filp, arg);
> -			unlock_kernel();
>  			break;
>  		case F_GETLK:
>  			err = fcntl_getlk(filp, (struct flock *) arg);

that's correct. Also moving the if (arg & O_DIRECT) {} right after
setting filp->f_flags would fix the race, that wouldn't require the move
the locking to the setfl, but I guess moving the locking down was your
object since the first place :). Please post it for mainline inclusion
too.

Andrea

  reply	other threads:[~2002-07-05 14:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-02 18:30 O_DIRECT handling introduced a race in F_SETFL Matthew Wilcox
2002-07-05 14:19 ` Andrea Arcangeli [this message]
2002-07-10 11:29   ` Andrea Arcangeli
2002-07-11 21:24     ` Marcus Alanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020705141934.GI7734@dualathlon.random \
    --to=andrea@suse.de \
    --cc=andrea@e-mind.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.