xfs-masters
[Top] [All Lists]

Re: [xfs-masters] RFC: Fix f_flags races without the BKL

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [xfs-masters] RFC: Fix f_flags races without the BKL
From: Jonathan Corbet <corbet@xxxxxxx>
Date: Wed, 31 Dec 2008 02:52:20 -0700
Cc: Andi Kleen <andi@xxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Al@xxxxxxxxxxx, Oleg Nesterov <oleg@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, bfields@xxxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Viro <viro@xxxxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <20081230144836.GA31439@lst.de>
Organization: LWN.net
References: <20081229041352.6bbdf57c@tpl> <20081229124151.GA29634@redhat.com> <20081229152732.GH496@one.firstfloor.org> <20081230055956.1747bd86@tpl> <20081230130439.GA28874@lst.de> <20081230133737.GM496@one.firstfloor.org> <20081230144836.GA31439@lst.de>
On Tue, 30 Dec 2008 15:48:37 +0100
Christoph Hellwig <hch@xxxxxx> 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

<Prev in Thread] Current Thread [Next in Thread>