linux-kernel - Re: [RFC] New kobject/kset/ktype documentation and example code

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <Pine.LNX.4.44L0.0711281407320.5566-100000@iolanthe.rowland.org>
Date:	Wed, 28 Nov 2007 14:18:18 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
cc:	Greg KH <greg@...ah.com>, <linux-kernel@...r.kernel.org>,
	Kay Sievers <kay.sievers@...y.org>,
	Jonathan Corbet <corbet@....net>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [RFC] New kobject/kset/ktype documentation and example code

On Wed, 28 Nov 2007, Cornelia Huck wrote:

> We should perhaps add a bit fat warning here:
> 
> Note that once you registered your kobject via kobject_add(), you must
> never use kfree() to free it directly. The only safe way is to use

Slightly ambiguous.  Instead just say:

If you have initialized your kobject via kobject_init() or
kobject_register(), you must not deallocate the kobject anywhere other
than its release() method (which is invoked during the final
kobject_put() call).  Otherwise the kernel will leak memory.

> > One important point cannot be overstated: every kobject must have a
> > release() method, and the kobject must persist (in a consistent state)
> > until that method is called. 
> 
> Which is especially hurting if you use kobjects in modules. (Which
> reminds me: Must dig up the patchset that fixes the module unload vs.
> release problem.)

In theory modules shouldn't present a problem -- especially if Greg 
merges the "Kobjects: drop child->parent ref at unregistration" patch.

When a module is unloaded, it has to unregister all its kobjects, which 
should force all their children to be unregistered too.  At that time 
the children's drivers should drop all their references to the parent 
kobject, leaving only references held by the module being unloaded.  
Presumably it can arrange to drop its own references before its exit() 
routine returns.

The only problem arises when a child's driver retains a reference to 
the parent kobject.  If things are done properly, this reference should 
involve incrementing the module count -- which would prevent the module 
from being unloaded in the first place.

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/