mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rick Lindsley <ricklind@us.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: viro@math.psu.edu (Alexander Viro),
	dave@sr71.net (David C. Hansen),
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove BKL from drivers' release functions
Date: Sat, 01 Dec 2001 02:06:59 -0800	[thread overview]
Message-ID: <200112011007.fB1A70429394@eng4.beaverton.ibm.com> (raw)
In-Reply-To: Your message of "Sat, 01 Dec 2001 09:52:57 GMT." <E16A6pN-0006d0-00@the-village.bc.nu>

    This is why we have a development tree. Its moving things in the
    right direction which is important. I suspect many drivers will
    want to use semaphores rather than atomic counts however, to ensure
    that an open doesn't complete while a previous release is still
    shutting down hardware

Yes, the only successful application for atomic counts that I've seen
(in this context) is for exclusive open code that looks like

    if (count++) {
	count--;
	return -EBUSY;
    }

in the open routine and

    count--;

in the release.  If you want to do anything else as a result of that
count, you'll need additional locking because it could have changed a
nanosecond after it was (safely) incremented or decremented. You can't
count on it remaining that value after you check it.

release()s that want to shutdown the device, free memory, or take other
actions will want to employ either a spinlock (plain or r/w as
appropriate) or a sleeping semaphore to insure things remain stable
until those actions are complete.

Rick

  reply	other threads:[~2001-12-01 10:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-28 23:05 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
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 [this message]
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=200112011007.fB1A70429394@eng4.beaverton.ibm.com \
    --to=ricklind@us.ibm.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®