From: Christoph Hellwig <hch@lst.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Hellwig <hch@lst.de>, Jonathan Corbet <corbet@lwn.net>,
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: Tue, 30 Dec 2008 15:48:37 +0100 [thread overview]
Message-ID: <20081230144836.GA31439@lst.de> (raw)
In-Reply-To: <20081230133737.GM496@one.firstfloor.org>
On Tue, Dec 30, 2008 at 02:37:37PM +0100, Andi Kleen wrote:
> That's not clear. Mutexes can be much slower than a spinlock
> like BKL in some situations, mostly because they schedule more and
> have generally more overhead.
>
> As long as you don't have another BKL user contending the BKL
> is likely faster than the mutex.
Note that I did not say faster, but better. The subtle races the
BKL semantics introduce are nasty.
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.
>
> -Andi
>
> --
> ak@linux.intel.com
>
> _______________________________________________
> xfs-masters mailing list
> xfs-masters@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs-masters
---end quoted text---
next prev parent reply other threads:[~2008-12-30 14:49 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 [this message]
2008-12-31 9:52 ` Jonathan Corbet
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=20081230144836.GA31439@lst.de \
--to=hch@lst.de \
--cc=Al@oss.sgi.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=bfields@fieldses.org \
--cc=corbet@lwn.net \
--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 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.