All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>
Cc: Patrick Mochel <mochel@osdl.org>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Jeff Garzik <jgarzik@pobox.com>, Greg KH <greg@kroah.com>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: PCI driver module unload race?
Date: Sat, 8 Mar 2003 10:47:49 +0000	[thread overview]
Message-ID: <20030308104749.A29145@flint.arm.linux.org.uk> (raw)

Hi,

What prevents the following scenario from happening?  It's purely
theoretical - I haven't seen this occuring.

- Load PCI driver.

- PCI driver registers using pci_module_init(), and adds itself to sysfs.

- Hot-plugin a PCI device which uses this driver.  sysfs matches the PCI
  driver, and calls the PCI drivers probe function.

- The probe function calls kmalloc or some other function which sleeps
  (or gets preempted, if CONFIG_PREEMPT is enabled.)

- We switch to another thread, which happens to be rmmod for this PCI
  driver.  We remove the driver since it has a use count of zero.

- We switch back to the PCI driver.  Oops.

I've probably missed something, but I don't think so.  I suspect we need
struct device_driver to include a struct module pointer which sysfs can
take before calling any driver functions.

Comments?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


             reply	other threads:[~2003-03-08 19:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-08 10:47 Russell King [this message]
2003-03-08 19:12 ` PCI driver module unload race? Greg KH
2003-03-08 19:47   ` Petr Vandrovec
2003-03-08 19:51     ` Greg KH
2003-03-09  2:33       ` Petr Vandrovec
2003-03-08 20:03     ` Russell King
2003-03-08 20:09   ` Russell King
2003-03-08 20:21     ` Greg KH
2003-03-10 21:44       ` Greg KH
2003-03-10 23:48         ` Oliver Neukum
2003-03-10 23:51           ` Greg KH
2003-03-11  1:04             ` Roman Zippel
2003-03-11  1:15               ` Greg KH
2003-03-11  9:00                 ` Oliver Neukum
2003-03-11 15:06                   ` Patrick Mochel
2003-03-11 16:07                     ` Oliver Neukum
2003-03-16 13:13                       ` Rusty Russell
2003-03-11 11:05                 ` Roman Zippel
2003-03-11 15:27                   ` Patrick Mochel
2003-03-11 20:09                     ` Roman Zippel
2003-03-11 19:15                       ` Patrick Mochel
2003-03-12  2:28                         ` Roman Zippel
2003-03-16 13:05                     ` Rusty Russell

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=20030308104749.A29145@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=greg@kroah.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=rusty@rustcorp.com.au \
    /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.