kobject_put vs module unload

kobject_put vs module unload

[Mikulas Patocka]

Hi

I'm looking at some kobject problem in device mapper and I came across 
this problem:

According to kobject interface specification, If we embed a kobject into 
the device structure, we shouldn't free the device structure when the 
device is unloaded, but we should register a "release" callback in 
kobj_type that will actually free the device structure.

What happens in this scenario?:

1) someone references a device kobject
2) the device is unloaded (but the device structure is still in memory 
because of that reference)
3) the driver module is unloaded
4) the reference obtained at point 1) is dropped, kobject reference count 
reaches zero and the release callback is called. But that callback points 
to an unloaded module and causes a crash.

How is it solved? Am I missing something?

Mikulas

Re: kobject_put vs module unload

[Greg KH]

On Fri, Jan 07, 2011 at 10:42:22PM -0500, Mikulas Patocka wrote:
> Hi
> 
> I'm looking at some kobject problem in device mapper and I came across 
> this problem:
> 
> According to kobject interface specification, If we embed a kobject into 
> the device structure, we shouldn't free the device structure when the 
> device is unloaded, but we should register a "release" callback in 
> kobj_type that will actually free the device structure.

That is correct.

What does "device is unloaded" mean?  That really doesn't mean anything
in reference to the driver model/kobject code.

> What happens in this scenario?:
> 
> 1) someone references a device kobject
> 2) the device is unloaded (but the device structure is still in memory 
> because of that reference)

What do you mean here?  How can a device be "unloaded"?  Is it just
unregistered?

> 3) the driver module is unloaded

Oops, you just lost.

> 4) the reference obtained at point 1) is dropped, kobject reference count 
> reaches zero and the release callback is called. But that callback points 
> to an unloaded module and causes a crash.
> 
> How is it solved? Am I missing something?

You have the code that creates and frees the object, to not be in the
module that could have been unloaded.  It's really just that simple.

Hope this helps,

greg k-h

Re: kobject_put vs module unload

[Mikulas Patocka]

On Fri, 7 Jan 2011, Greg KH wrote:

> On Fri, Jan 07, 2011 at 10:42:22PM -0500, Mikulas Patocka wrote:
> > Hi
> > 
> > I'm looking at some kobject problem in device mapper and I came across 
> > this problem:
> > 
> > According to kobject interface specification, If we embed a kobject into 
> > the device structure, we shouldn't free the device structure when the 
> > device is unloaded, but we should register a "release" callback in 
> > kobj_type that will actually free the device structure.
> 
> That is correct.
> 
> What does "device is unloaded" mean?  That really doesn't mean anything
> in reference to the driver model/kobject code.
> 
> > What happens in this scenario?:
> > 
> > 1) someone references a device kobject
> > 2) the device is unloaded (but the device structure is still in memory 
> > because of that reference)
> 
> What do you mean here?  How can a device be "unloaded"?  Is it just
> unregistered?

Device mapper devices can be unloaded by the user with "dmsetup remove" 
command. Other drivers (like md), offer other commands to unload devices, 
but the principle is the same.

> > 3) the driver module is unloaded
> 
> Oops, you just lost.

If you unload all device mappers's devices, the module reference count 
drops to zero and you can unload the device mapper module.

> > 4) the reference obtained at point 1) is dropped, kobject reference count 
> > reaches zero and the release callback is called. But that callback points 
> > to an unloaded module and causes a crash.
> > 
> > How is it solved? Am I missing something?
> 
> You have the code that creates and frees the object, to not be in the
> module that could have been unloaded.  It's really just that simple.

If the whole device mapper subsystem can be a module, where can I put the 
code?

I think a similar bug exists in md, it can also be unloaded as a module 
and it has "release" method in its module code.

> Hope this helps,
> 
> greg k-h

Mikulas

Re: kobject_put vs module unload

[Kay Sievers]

On Sat, Jan 8, 2011 at 14:19, Mikulas Patocka <mpatocka@redhat.com> wrote:
> On Fri, 7 Jan 2011, Greg KH wrote:

>> > 4) the reference obtained at point 1) is dropped, kobject reference count
>> > reaches zero and the release callback is called. But that callback points
>> > to an unloaded module and causes a crash.
>> >
>> > How is it solved? Am I missing something?
>>
>> You have the code that creates and frees the object, to not be in the
>> module that could have been unloaded.  It's really just that simple.
>
> If the whole device mapper subsystem can be a module, where can I put the
> code?
>
> I think a similar bug exists in md, it can also be unloaded as a module
> and it has "release" method in its module code.

If you still have data structures hanging around, these structures are
supposed to take a reference on the module -- and you can not unload
the module as long as this is the case.

Kay

Re: kobject_put vs module unload

[Mikulas Patocka]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1281 bytes --]



On Sat, 8 Jan 2011, Kay Sievers wrote:

> On Sat, Jan 8, 2011 at 14:19, Mikulas Patocka <mpatocka@redhat.com> wrote:
> > On Fri, 7 Jan 2011, Greg KH wrote:
> 
> >> > 4) the reference obtained at point 1) is dropped, kobject reference count
> >> > reaches zero and the release callback is called. But that callback points
> >> > to an unloaded module and causes a crash.
> >> >
> >> > How is it solved? Am I missing something?
> >>
> >> You have the code that creates and frees the object, to not be in the
> >> module that could have been unloaded.  It's really just that simple.
> >
> > If the whole device mapper subsystem can be a module, where can I put the
> > code?
> >
> > I think a similar bug exists in md, it can also be unloaded as a module
> > and it has "release" method in its module code.
> 
> If you still have data structures hanging around, these structures are
> supposed to take a reference on the module -- and you can not unload
> the module as long as this is the case.
> 
> Kay

kobject references don't increase module reference count. If kobject held 
module references, it would be a fix for this bug, but could cause other 
bugs (some modules could be unloadable due to self-references to its own 
kobjects).

Mikulas

Re: kobject_put vs module unload

[Kay Sievers]

On Sat, Jan 8, 2011 at 19:01, Mikulas Patocka <mpatocka@redhat.com> wrote:
> On Sat, 8 Jan 2011, Kay Sievers wrote:
>> On Sat, Jan 8, 2011 at 14:19, Mikulas Patocka <mpatocka@redhat.com> wrote:
>> > On Fri, 7 Jan 2011, Greg KH wrote:
>>
>> >> > 4) the reference obtained at point 1) is dropped, kobject reference count
>> >> > reaches zero and the release callback is called. But that callback points
>> >> > to an unloaded module and causes a crash.
>> >> >
>> >> > How is it solved? Am I missing something?
>> >>
>> >> You have the code that creates and frees the object, to not be in the
>> >> module that could have been unloaded.  It's really just that simple.
>> >
>> > If the whole device mapper subsystem can be a module, where can I put the
>> > code?
>> >
>> > I think a similar bug exists in md, it can also be unloaded as a module
>> > and it has "release" method in its module code.
>>
>> If you still have data structures hanging around, these structures are
>> supposed to take a reference on the module -- and you can not unload
>> the module as long as this is the case.
>>
>> Kay
>
> kobject references don't increase module reference count. If kobject held
> module references, it would be a fix for this bug, but could cause other
> bugs (some modules could be unloadable due to self-references to its own
> kobjects).

Sure, they don't automatically take references. It's the job of the
driver/module, to make sure to pin the module for any data of it,
which might be still in use.

Kay

Re: kobject_put vs module unload

[Mikulas Patocka]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1965 bytes --]



On Sat, 8 Jan 2011, Kay Sievers wrote:

> On Sat, Jan 8, 2011 at 19:01, Mikulas Patocka <mpatocka@redhat.com> wrote:
> > On Sat, 8 Jan 2011, Kay Sievers wrote:
> >> On Sat, Jan 8, 2011 at 14:19, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >> > On Fri, 7 Jan 2011, Greg KH wrote:
> >>
> >> >> > 4) the reference obtained at point 1) is dropped, kobject reference count
> >> >> > reaches zero and the release callback is called. But that callback points
> >> >> > to an unloaded module and causes a crash.
> >> >> >
> >> >> > How is it solved? Am I missing something?
> >> >>
> >> >> You have the code that creates and frees the object, to not be in the
> >> >> module that could have been unloaded.  It's really just that simple.
> >> >
> >> > If the whole device mapper subsystem can be a module, where can I put the
> >> > code?
> >> >
> >> > I think a similar bug exists in md, it can also be unloaded as a module
> >> > and it has "release" method in its module code.
> >>
> >> If you still have data structures hanging around, these structures are
> >> supposed to take a reference on the module -- and you can not unload
> >> the module as long as this is the case.
> >>
> >> Kay
> >
> > kobject references don't increase module reference count. If kobject held
> > module references, it would be a fix for this bug, but could cause other
> > bugs (some modules could be unloadable due to self-references to its own
> > kobjects).
> 
> Sure, they don't automatically take references. It's the job of the
> driver/module, to make sure to pin the module for any data of it,
> which might be still in use.
> 
> Kay

A module can't unpin itself. If it does, the module can be unloaded 
immediatelly after module_put(THIS_MODULE) call and the function that 
called module_put crashes.

A module must be unpinned by someone else. The question is: who unpins the 
module when kobject references are gone?

Mikulas

Re: kobject_put vs module unload

[Greg KH]

On Sat, Jan 08, 2011 at 01:50:50PM -0500, Mikulas Patocka wrote:
> 
> 
> On Sat, 8 Jan 2011, Kay Sievers wrote:
> 
> > On Sat, Jan 8, 2011 at 19:01, Mikulas Patocka <mpatocka@redhat.com> wrote:
> > > On Sat, 8 Jan 2011, Kay Sievers wrote:
> > >> On Sat, Jan 8, 2011 at 14:19, Mikulas Patocka <mpatocka@redhat.com> wrote:
> > >> > On Fri, 7 Jan 2011, Greg KH wrote:
> > >>
> > >> >> > 4) the reference obtained at point 1) is dropped, kobject reference count
> > >> >> > reaches zero and the release callback is called. But that callback points
> > >> >> > to an unloaded module and causes a crash.
> > >> >> >
> > >> >> > How is it solved? Am I missing something?
> > >> >>
> > >> >> You have the code that creates and frees the object, to not be in the
> > >> >> module that could have been unloaded.  It's really just that simple.
> > >> >
> > >> > If the whole device mapper subsystem can be a module, where can I put the
> > >> > code?
> > >> >
> > >> > I think a similar bug exists in md, it can also be unloaded as a module
> > >> > and it has "release" method in its module code.
> > >>
> > >> If you still have data structures hanging around, these structures are
> > >> supposed to take a reference on the module -- and you can not unload
> > >> the module as long as this is the case.
> > >>
> > >> Kay
> > >
> > > kobject references don't increase module reference count. If kobject held
> > > module references, it would be a fix for this bug, but could cause other
> > > bugs (some modules could be unloadable due to self-references to its own
> > > kobjects).
> > 
> > Sure, they don't automatically take references. It's the job of the
> > driver/module, to make sure to pin the module for any data of it,
> > which might be still in use.
> > 
> > Kay
> 
> A module can't unpin itself. If it does, the module can be unloaded 
> immediatelly after module_put(THIS_MODULE) call and the function that 
> called module_put crashes.
> 
> A module must be unpinned by someone else. The question is: who unpins the 
> module when kobject references are gone?

Who ever you decide to have unpin it.

Seriously, it's up to you to handle this properly, it's not something
built into the kobject/driver model at all due to it being something
that can be done in a number of different ways.

thanks,

greg k-h