lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 4 Jan 2014 10:16:20 -0800
From:	Greg Kroah-Hartman <>
To:	Mikulas Patocka <>
Cc:	Jeff Mahoney <>,,,,,,
Subject: Re: [PATCH] kobject: provide kobject_put_wait to fix module unload

On Sat, Jan 04, 2014 at 01:06:01PM -0500, Mikulas Patocka wrote:
> Hi
> I noticed that Jeff Mahoney added a new structure kobj_completion, defined 
> in include/linux/kobj_completion.h to the kernel 3.13-rc1 in the patch 
> eee031649707db3c9920d9498f8d03819b74fc23. In the current upstream kernel, 
> this interface is still unused.

There are pending btrfs patches to use this interface.

> However, converting the drivers to use kobj_completion is not trivial 
> (note that all users of the original kobject interface are buggy - so all 
> of them need to be converted).

Wait, what?  How are "all users" buggy?  Please explain this in detail.

> I came up with a simpler patch to achieve the same purpose - this patch 
> makes fixing the drivers easy - the driver is fixed just by replacing 
> "kobject_put" with "kobject_put_wait" in the unload routine.

No, that's not ok at all.

> I'd like to ask if you could revert 
> eee031649707db3c9920d9498f8d03819b74fc23 (no code uses it) and replace it 
> with this patch.
> See for 
> the bug that this patch fixes.
> Mikulas
> From: Mikulas Patocka <>
> This patch introduces a new function kobject_put_wait. It decrements the
> kobject reference count, waits until the count reaches zero. When this
> function returns, it is guaranteed that the kobject was freed.
> A rationale for this function:
> The kobject is keeps a reference count. The driver unload routine
> decrements the reference count, however, references to the kobject may
> still be held by other kernel subsystems. The driver must not free the
> memory that contains the kobject. Instead, the driver provides a "release"
> method. The "release" method is called by the kernel when the last kobject
> refernce is dropped. The "release" method should free the memory that
> contains the kobject.
> However, this pattern is buggy with respect to modules. The release method
> is placed in the driver's module. When the driver exits, the module
> reference count is zero, thus the module may be freed. However, there may
> still be references to the kobject. If the module is unloaded and then the
> release method is called, a crash happens.

Yes, module unloading while a kobject is still "active" is not a good
thing, what modules do you have that cause this problem?  Why not just
grab the module reference in your kobject if you need this type of
protection?  It's not the kobject's code fault that this issue is there,
or that we now have a "delayed release" function to expose this type of
thing, it's the user of the kobject.

Please fix the broken users of the kobject first.


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists