[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081231025220.1e67236e@tpl>
Date: Wed, 31 Dec 2008 02:52:20 -0700
From: Jonathan Corbet <corbet@....net>
To: Christoph Hellwig <hch@....de>
Cc: Andi Kleen <andi@...stfloor.org>, Christoph Hellwig <hch@....de>,
Al@....sgi.com, Oleg Nesterov <oleg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, bfields@...ldses.org,
xfs-masters@....sgi.com, Viro <viro@...IV.linux.org.uk>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [xfs-masters] RFC: Fix f_flags races without the BKL
On Tue, 30 Dec 2008 15:48:37 +0100
Christoph Hellwig <hch@....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
--
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/
Powered by blists - more mailing lists