From: Andi Kleen <andi@firstfloor.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH, RFC] fasync() BKL pushdown
Date: Fri, 20 Jun 2008 21:12:51 +0200 [thread overview]
Message-ID: <485C0133.3020708@firstfloor.org> (raw)
In-Reply-To: <20080620130905.6694a7be@bike.lwn.net>
Jonathan Corbet wrote:
> On Fri, 20 Jun 2008 19:55:03 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
>> Jonathan Corbet wrote:
>>
>>> The majority of fasync() functions just call fasync_helper() with a
>>> pointer to an fasync_struct reachable from the file structure.
>>> Given that (1) the struct file will not go away while fasync() is
>>> running, and (2) the VFS-level fasync() stuff is protected with the
>>> Big Fasync Lock, I contend that these simple implementations have
>>> no need for the BKL.
>> Not necessarily true, they might require BKL still for fd live time
>> issues.
>
> Could you help me out a bit here? I'm even slower than usual when it
> comes to VFS stuff. As far as I can tell, the given file cannot go
> away during the call to fasync(), as sys_fcntl() holds a reference on
> it. Are you saying that something else can happen during that time?
Some devices do state change even when the reference count is > 0.
Would need to double check it's all ok with the fasync list.
Anyways I did this auditing for the cases where I used unlocked_ioctl
[but I think I wanted to redo it because i wasn't 100% sure anymore]
and I haven't done it at all for the cases that weren't converted.
-Andi
next prev parent reply other threads:[~2008-06-20 19:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 17:29 [PATCH, RFC] fasync() BKL pushdown Jonathan Corbet
2008-06-20 17:55 ` Andi Kleen
2008-06-20 19:09 ` Jonathan Corbet
2008-06-20 19:12 ` Andi Kleen [this message]
2008-06-25 22:30 ` [PATCH, RFC] fasync() BKL pushdown (take 2) Jonathan Corbet
2008-06-27 8:48 ` Andi Kleen
2008-06-20 20:58 ` [PATCH, RFC] fasync() BKL pushdown Arjan van de Ven
2008-06-20 21:05 ` Jonathan Corbet
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=485C0133.3020708@firstfloor.org \
--to=andi@firstfloor.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.