All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.