public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Christoph Hellwig <hch@lst.de>
Cc: Andi Kleen <andi@firstfloor.org>, Christoph Hellwig <hch@lst.de>,
	Al@oss.sgi.com, Oleg Nesterov <oleg@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	bfields@fieldses.org, xfs-masters@oss.sgi.com,
	Viro <viro@ZenIV.linux.org.uk>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [xfs-masters] RFC: Fix f_flags races without the BKL
Date: Wed, 31 Dec 2008 02:52:20 -0700	[thread overview]
Message-ID: <20081231025220.1e67236e@tpl> (raw)
In-Reply-To: <20081230144836.GA31439@lst.de>

On Tue, 30 Dec 2008 15:48:37 +0100
Christoph Hellwig <hch@lst.de> wrote:

> That beeing said I took another look at the patch and it seems like
> most places are indeed just very quick flags setting / clearing
> with the only sleeping possible inside ->fasync.  So having a
> file_flags_lock spinlock, and another sleeping mutex protecting
> ->fasync might be another options.  
> 
> Jon, do you remember what we actually need to protect in -fasync?
> any reason not to take the locking inside the method?  Together with
> ->lock and the old ->ioctl it's pretty special in fops as none of  
> the others have any locking at all.

There's nothing special about fasync() itself.  The problem is that the
setting of the FASYNC flag and the associated call to fasync() need to
be atomic, lest the driver/filesystem and the VFS end up with differing
ideas about the setting of that flag.  In the absence of that
constraint, one could just use the normal bit operations on f_flags.

jon

  reply	other threads:[~2008-12-31  9:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 11:13 RFC: Fix f_flags races without the BKL Jonathan Corbet
2008-12-29 11:57 ` Sam Ravnborg
2008-12-30 12:49   ` Jonathan Corbet
2008-12-29 12:41 ` Oleg Nesterov
2008-12-29 15:27   ` Andi Kleen
2008-12-30 12:59     ` Jonathan Corbet
2008-12-30 13:04       ` [xfs-masters] " Christoph Hellwig
2008-12-30 13:37         ` Andi Kleen
2008-12-30 14:48           ` Christoph Hellwig
2008-12-31  9:52             ` Jonathan Corbet [this message]
2008-12-30 14:55       ` Andi Kleen
2009-01-08 23:28   ` Jonathan Corbet
2009-01-09 10:08     ` Oleg Nesterov
2009-01-09 13:18       ` Jonathan Corbet
2009-01-09 14:03         ` Oleg Nesterov
2009-01-09 15:09         ` Andi Kleen
2008-12-29 12:50 ` [xfs-masters] " Christoph Hellwig
2008-12-29 15:15   ` Andi Kleen
2009-01-02 18:29     ` Al Viro
2009-01-02 18:27   ` Al Viro
2009-01-02 18:42 ` Al Viro
2009-01-02 19:09   ` Oleg Nesterov
2009-01-02 19:54     ` Al Viro
2009-01-03 16:45       ` Oleg Nesterov

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=20081231025220.1e67236e@tpl \
    --to=corbet@lwn.net \
    --cc=Al@oss.sgi.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=bfields@fieldses.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=viro@ZenIV.linux.org.uk \
    --cc=xfs-masters@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox