[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1106131048080.1983-100000@iolanthe.rowland.org>
Date: Mon, 13 Jun 2011 11:10:57 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Greg KH <greg@...ah.com>,
Kernel development list <linux-kernel@...r.kernel.org>
cc: Hans de Goede <hdegoede@...hat.com>
Subject: Unbinding drivers for resources that are in use
The kernel prevents modules from being unloaded if they are being used.
But it doesn't have any analogous mechanism for preventing a driver
being unbound from a device that's in use.
For example, suppose a SATA disk contains a mounted filesystem. If the
user writes the corresponding device name to
/sys/bus/scsi/drivers/sd/unbind without unmounting the filesystem, the
drive will become inaccessible and data may be lost. The same problem
arises with USB devices and programs using usbfs to unbind a device
from its kernel driver.
It's true that the "unbind" attribute has mode 0200 and therefore can
be written only by the superuser. Still, this puts the onus on
userspace to determine whether or not a device is being used. The
kernel could easily keep track of this automatically and atomically
-- userspace can't do this without races.
Therefore I'm asking if the driver core should add a refcount to every
struct device for keeping track of the number of open file references
(or other types of resource) using this device. If this number is
nonzero, the kernel should prevent the device from being unbound from
its driver -- except of course in cases where the device has been
hot-unplugged; there's nothing we can do to prevent errors when this
happens.
Changes to the refcount would have to propagate up the device tree: If
a device holds an important resource then we don't want any of the
device's ancestors to become inaccessible either. This would be easy
to implement.
Should we do it?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists