From: "David C. Hansen" <dave@sr71.net>
To: Alexander Viro <viro@math.psu.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, Rick Lindsley <ricklind@us.ibm.com>
Subject: Re: [PATCH] remove BKL from drivers' release functions
Date: Fri, 30 Nov 2001 11:38:50 -0800 [thread overview]
Message-ID: <3C07E04A.7020301@sr71.net> (raw)
In-Reply-To: <Pine.GSO.4.21.0111300444180.13367-100000@weyl.math.psu.edu>
Alexander Viro wrote:
> ->release() is not serialized AT ALL. It is serialized for given
> struct file, but call open(2) twice and you've got two struct file
> for the same device. close() both and you've got two calls of
> ->release(), quite possibly - simultaneous.
OK, that clears some things up. So, the file->fcount is only used in
cases where the file descriptor was dup'd, right?
As Rick Lindsley pointed out to me:
> In cases where we removed BKL from release() and left obvious locking
> issues as "an exercise to the reader", we MAY have broken things
> because the BKL (we now know) may have been serializing opens and
> closes.
> In cases where we replaced it with atomic locking or a spinlock, we've
> done nothing but replace one lock with another (unless there are
> subtleties
back to Alexander Viro:
> In other words, patch is completely bogus.
No, not completely. In a lot of cases we just replaced some regular
arithmetic with atomic instructions of some sort. These changes are
still completely valid. But, in the cases where we added locking, we
need to reevaluate them for potential problem. In the cases where we
just removed the BKL, we really need to check them to make sure that we
didn't introduce anything.
Thanks for the feedback, Al! This has been very helpful!
--
Dave Hansen
dave@sr71.net
next prev parent reply other threads:[~2001-11-30 19:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 23:05 [PATCH] remove BKL from drivers' release functions David C. Hansen
2001-11-28 23:29 ` Andrew Morton
2001-11-28 23:42 ` David C. Hansen
2001-11-28 23:50 ` Robert Love
2001-11-28 23:36 ` Alan Cox
2001-11-28 23:32 ` David C. Hansen
2001-11-28 23:45 ` Russell King
2001-11-29 0:26 ` David C. Hansen
2001-11-29 0:37 ` Jeff Garzik
2001-11-29 0:41 ` Russell King
2001-11-29 1:33 ` David C. Hansen
2001-11-29 1:42 ` Jeff Garzik
2001-11-29 7:17 ` Oliver Neukum
2001-11-29 1:47 ` Alan Cox
2001-11-29 9:15 ` Russell King
2001-11-29 13:55 ` BALBIR SINGH
2001-11-30 19:30 ` Rick Lindsley
2001-11-30 9:57 ` Alexander Viro
2001-11-30 12:41 ` Victor Yodaiken
2001-11-30 20:02 ` Rick Lindsley
2001-11-30 19:38 ` David C. Hansen [this message]
2001-11-30 23:12 ` Alexander Viro
2001-12-01 0:47 ` Rick Lindsley
2001-12-01 9:52 ` Alan Cox
2001-12-01 10:06 ` Rick Lindsley
2001-11-30 20:11 ` Rick Lindsley
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=3C07E04A.7020301@sr71.net \
--to=dave@sr71.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=ricklind@us.ibm.com \
--cc=viro@math.psu.edu \
/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