From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: "David C. Hansen" <haveblue@us.ibm.com>
Cc: Russell King <rmk@arm.linux.org.uk>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove BKL from drivers' release functions
Date: Wed, 28 Nov 2001 19:37:35 -0500 [thread overview]
Message-ID: <3C05834F.13C60B0C@mandrakesoft.com> (raw)
In-Reply-To: <E169EFX-0006TA-00@the-village.bc.nu> <3C057410.3090201@us.ibm.com> <20011128234505.C2561@flint.arm.linux.org.uk> <3C0580A8.5030706@us.ibm.com>
"David C. Hansen" wrote:
>
> Russell King wrote:
>
> >On Wed, Nov 28, 2001 at 03:32:32PM -0800, David C. Hansen wrote:
> >
> >>Nothing, because the BKL is not held for all opens anymore. In most of
> >>the cases that we addressed, the BKL was in release _only_, not in open
> >>at all. There were quite a few drivers where we added a spinlock, or
> >>used atomic operations to keep open from racing with release.
> >>
> >
> >All char and block devs are opened with the BKL held - see chrdev_open in
> >fs/devices.c and do_open in fs/block_dev.c
> >
> I wrote a quick and dirty char device driver to see if this happened.
> If I run two tasks doing a bunch of opens and closes, the -EBUSY
> condition in the open function does happen. Is my driver doing
> something wrong?
>
> Here is the meat of the driver:
>
> static int Device_Open = 0;
>
> int testdev_open(struct inode *inode, struct file *file)
> {
> if ( test_and_set_bit(0,&Device_Open) ) {
> printk( "attempt to open testdev more than once\n" );
> return -EBUSY;
> }
> MOD_INC_USE_COUNT;
> return SUCCESS;
> }
>
> int testdev_release(struct inode *inode, struct file *file)
> {
> clear_bit(0,&Device_Open);
> MOD_DEC_USE_COUNT;
> return 0;
> }
it is still racy, that's why struct file_operations and other structs
have an 'owner' member......
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
next prev parent reply other threads:[~2001-11-29 0:38 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 [this message]
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
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=3C05834F.13C60B0C@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.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.