Re: [RFC PATCH 0/3] sysfs: allow suicide

Hello,

Eric W. Biederman wrote:
Tejun Heo <htejun@xxxxxxxxx> writes:

Thanks for the points. I do agree that it could be a bit too clever,
but the thing is that protecting the code area from going underneath
something is a pretty special thing to begin with and I think it's
better to apply special solution rather than trying to work around it
using general mechanisms. So, I actually think the global inhibit
thing is one of the better ways to deal with the nasty-in-nature
problem.

Protecting the data structures from going away is just as important,
and the module_inhibit does not address that.

Yeap, I was talking about the code issue only.

When I looked at it I could not see any touches of kobj in the sysfs
code after we dropped the reference count in a strange place, but
I haven't been able to convince myself that we will be safe.

The reference is dropped when the suiciding thread calls delete on the
sysfs node. It forfeits its right to access the object when it
deletes it, which makes sense. The things which are guaranteed after
deleting the base object are the code it's running off of and the
sysfs object itself. I think it's pretty intuitive from user's POV.

My view is that this is a general hotplug problem and not a sysfs
problem. Further I see inhibiting module reload as only solving
have the problem as dropping the kobject reference opens a window to
a use after free on the kobj.

kobject_del(obj); obj->whatever; isn't any different from kfree(p);
*p;. If the caller accesses the object after deleting it, it's gonna
fail unless it already held a separate reference count. There is no
window.

The problem that I see is that we are missing support from the device
model for hotunplug. Running the device remove method from process
context is required. Typically hotplug controllers discover a
device has been removed or will be removed in interrupt context.

Therefore every hotplug driver I have looked at has it's own workqueue
to solve the problem of getting the notification of a hotplug event
from an inappropriate context.

So the general problem that I see is that I need a solution to trigger
a remove from interrupt context and that same solution will happen to
work just fine for sysfs.

I think the problem is more driver domain specific and not quite sure
whether one size would fit all. We have a lot of drivers in the tree.
I think the best approach would be trying to move upwards from the
bottom. ie. Consolidate hotplug / error handling support from low
level drivers to specific driver subsystem, from driver subsystems to
higher layer (ie. block layer) and then see whether there can be more
commonalities which can be factored, but the chance is that once
things are pushed upwards enough, moving it into the kobject layer
probably wouldn't worth the trouble. Well, it's all speculations at
this point tho.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC PATCH 0/3] sysfs: allow suicide
    ... device has been removed or will be removed in interrupt context. ... Therefore every hotplug driver I have looked at has it's own workqueue ...
    (Linux-Kernel)
  • Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
    ... It is not hotplug, and your changes broke it completely. ... > - separate master registering and allocation so drivers can setup proper ... > Drop custom-made hotplug over netlink notification from w1 core. ... > - get rid of separate refcount, rely on driver model to enforce ...
    (Linux-Kernel)
  • [PATCH] driver core: replace "hotplug" by "uevent"
    ... Leave the overloaded "hotplug" word to susbsystems which are handling ... This last call causes the device driver for the card to be stopped, ... extern struct kobj_type ktype_part; ... static struct kset acpi_namespace_kset = { ...
    (Linux-Kernel)
  • Re: Unresolved Externals creating driver
    ... usbpdi.obj: error LNK2019: unresolved external symbol ... > an identical driver, under a different name. ... > I get in this vicious circle of putting in a reference to a library, ... > having the build complain about multiply defined symbols. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [patch 031/104] PCI: prevent duplicate slot names
    ... We take advantage of the new 'hotplug' parameter in pci_create_slot ... The hotplug driver creates the slot with its desired name, ... goto error_info; ... struct pci_bus of parent bridge ...
    (Linux-Kernel)