LKML Archive on
help / color / mirror / Atom feed
From: Alan Stern <>
To: Christoph Hellwig <>, Tejun Heo <>
Cc: Bart Van Assche <>,
	James Bottomley <>,
	Hannes Reinecke <>,
	"" <>,
	Greg Kroah-Hartman <>,
	Kernel development list <>
Subject: sysfs methods can race with ->remove
Date: Thu, 15 Jan 2015 13:22:03 -0500 (EST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


The context is that we have been talking about
drivers/scsi/scsi_scan.c:scsi_rescan_device(), which is called by the
store_rescan_field() sysfs method in scsi_sysfs.c.  The problem is
this: What happens in scsi_rescan_device if the device is unbound from
its driver before the module_put call?  The dev->driver->owner
calculation would dereference a NULL pointer.

On Thu, 15 Jan 2015, Christoph Hellwig wrote:

> On Wed, Jan 14, 2015 at 10:07:00AM -0500, Alan Stern wrote:
> > and the kernfs core insures that the underlying device won't be 
> > deallocated while a sysfs method runs.
> It has a reference to keep it from beeing freed, but so far I can't find
> anything that prevents ->remove from beeing called while we are in or
> just before a method call.

There are two types of methods to think about: Those registered by the 
subsystem and those registered by the driver.

If a method is registered by the driver, then the driver will
unregister it when the ->remove routine runs.  I don't know for
certain, but I would expect that the sysfs/kernfs core will make sure
that any existing method calls complete before unregister returns.  
This would prevent races.

If a method is registered by the subsystem, and if the method runs 
entirely within the subsystem's code, then ->remove doesn't matter.  
The driver could be unbound while the method is running and it would be 

The only time we have a problem is when the method is registered by the 
subsystem and the method calls into the driver.  (Note that this is 
exactly what happens with scsi_rescan_device.)

> > > But this seems like a more generic problem, and at least a quick glance at
> > > the pci_driver methods seems like others don't have a good
> > > synchroniation of ->remove against random driver methods.
> > 
> > Can you give one or two examples?
> I look at the sriov_configure PCI method, or the various sub-methods
> under pci_driver.err_handler.

The sriov_numvfs_store method does have the same problem, and so does 
the reset_store method (by way of pci_reset_function -> 
pci_dev_save_and_disable -> pci_reset_notify).

Tejun, is my analysis correct?  How should we fix these races?

Alan Stern

  reply	other threads:[~2015-01-15 18:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
2015-01-14  9:33   ` [PATCH for v3.19, v2] Avoid that sd_shutdown() triggers a kernel warning Christoph Hellwig
2015-01-14 15:07     ` Alan Stern
2015-01-15 16:06       ` Christoph Hellwig
2015-01-15 18:22         ` Alan Stern [this message]
2015-01-15 19:40           ` sysfs methods can race with ->remove Tejun Heo
2015-01-26 17:19             ` Christoph Hellwig
2015-01-26 18:38               ` Alan Stern
2015-01-20 15:11     ` [PATCH for v3.19, v2] Avoid that sd_shutdown() triggers a kernel warning Alan Stern

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: sysfs methods can race with ->remove' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).