From: Dave Hansen <haveblue@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, Rick Lindsley <ricklind@us.ibm.com>,
Greg KH <gregkh@us.ibm.com>
Subject: Re: [RFC] Push BKL into chrdev opens
Date: Thu, 01 Aug 2002 11:02:43 -0700 [thread overview]
Message-ID: <3D4977C3.7050806@us.ibm.com> (raw)
In-Reply-To: 3D490BF2.2000709@us.ibm.com
Dave Hansen wrote:
> This patch adds the BKL to each character device's open() function. The
> BKL will remain in chrdev_open() until the module unload races are
> fixed, but this makes it unnecessary there for any other reason.
Greg KH noticed that I'd touched USB, and wondered about the places
where get/put_fops were used to make sure the driver gets called
directly the next time, instead of going through the subsystem. I
don't believe that the BKL is needed in the devices in this case, only
in the subsystem itself.
During inode init (init_special_inode) f_op is set to def_chr_fops,
which contains chrdev_open
First open of char device file:
if (f->f_op && f->f_op->open) {
error = f->f_op->open(inode,f);
}
The ->open() call goes to chrdev_open
USB is determined to handle the device
BKL is grabbed in chrdev_open
generic USB ->open() called (usb_open())
driver ->open() is called
f_op is replaced with the driver's f_op struct.
BKL is released
Subsequent calls:
if (f->f_op && f->f_op->open) {
error = f->f_op->open(inode,f);
}
->open() goes directly to driver. No BKL grabbed after first call.
The drivers were only protected during the first call, not during
subsequent ones. The addition of the BKL to usb_open() alone
duplicates this behavior. Adding BKL to individual devices in cases
like this is not required.
The tree is available for pulling from:
http://linux-bkl.bkbits.net/linux-2.5-bkl
--
Dave Hansen
haveblue@us.ibm.com
next prev parent reply other threads:[~2002-08-01 17:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-01 10:22 [RFC] Push BKL into chrdev opens Dave Hansen
2002-08-01 18:02 ` Dave Hansen [this message]
2002-08-02 18:20 ` Kevin O'Connor
2002-08-02 18:43 ` Dave Hansen
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=3D4977C3.7050806@us.ibm.com \
--to=haveblue@us.ibm.com \
--cc=gregkh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ricklind@us.ibm.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.