On Thu, Nov 11, 2010 at 11:50:01PM +0300, Vladislav Bolkhovitin wrote:
> Boaz Harrosh, on 11/11/2010 12:59 PM wrote:
> >> static void x_release(struct kobject *kobj)
>
> Yes. Precisely speaking, of its kobj_type.
>
> > This one is put on the kobj.release Right?
> >
> >> {
> >> struct object_x *x;
> >> struct completion *c;
> >>
> >> x = container_of(kobj, struct object_x, kobj);
> >> c = x->release_completion;
> >> kfree(x);
> >> complete_all(c);
> >> }
> >>
> >
> > I don't see the unregister of the object_x.kobj, where do
> > you do this one in x_release or del_object below?
>
> Which unregister? Put for object_x.kobj is in del_object()
>
> >> void del_object(struct object_x *x)
> >> {
> >> DECLARE_COMPLETION_ONSTACK(completion);
> >>
> >> ...
> >> x->release_completion = &completion;
> >> kobject_put(&x->kobj);
> >
> > This put might not be the last put on the object, IOs in flight
> > and/or open files might have extra reference on the object.
> > We release our initial ref, and below wait for all operations
> > to complete. (Is there a matter of timeout like files not closing?)
>
> This is the last internal put. All other references are from outsiders.
> So, we are waiting for all them to put before we go on.
>
The question is why do you need to wait here? I presume it is module
unloading path, but then it is quite bad - you can easily wedge your
subsystem if you make something to take a reference to your kobject
while module is ytying to be unloaded. Back when sysfs attributes tied
kobjects the easiest thing was to do:
rmmod <module> < / sys/devices/..../attribute
If you are done with the kobject - just proceed with what you were doing
and let it die its own peaceful death some time later. You just need to
make sure release code sticks around to free it and your subsystem core
can be tasked with this. Use module counter to prevent unloading of the
subsystem core until all kobjects belonging to the subsystem are
destroyed.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
