linux-kernel - Re: How should an exit routine wait for release() callbacks?

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: <20070416170508.07939b18@gondolin.boeblingen.de.ibm.com>
Date:	Mon, 16 Apr 2007 17:05:08 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Tejun Heo <htejun@...il.com>,
	Markus Rechberger <markus.rechberger@....com>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: How should an exit routine wait for release() callbacks?

On Mon, 16 Apr 2007 10:43:01 -0400 (EDT),
Alan Stern <stern@...land.harvard.edu> wrote:

> Actually it has to be done in kobject_init() since the release method can 
> be called any time after that, even if the kobject is never add'ed.

True. This would also imply that we only ever must free a kobject with
kobject_put() if kobject_init() has been called.

> 
> > from now on it may be looked up). kobject_get()/kobject_put() wouldn't
> > need to grab an extra reference (we already have refcounting for this
> > object in place). kobject_cleanup() could do something like:
> > 
> > struct module * kobject_owner = kobj->owner;
> > ...
> > call_release();
> > put_second_module_refcount(kobject_owner);
> > 
> > combined with the module unloading code waiting after calling the exit
> > function until the second type refcount dropped to 0. This would make
> > sure that the module is not deleted until the last release function has
> > been called.
> > 
> > The module would stay in memory (not be unloaded) until the last
> > kobject created by the module is deleted, but I think that is just what
> > we want. At least this doesn't mean that the module blocks its own
> > unloading.
> 
> Yes, that's what I had in mind.
> 
> It would have to apply to other things besides kobjects -- in principle,
> anything with a release routine, although in many cases it wouldn't be 
> needed.  But in particular, it _would_ be needed for struct device.
> 
> (In fact, perhaps kobject would not need it.  There aren't too many places
> where a raw kobject is used; almost always it is embedded in some larger
> object -- like struct device -- along with a release method pointer.  
> This larger object would need an owner but its embedded kobject usually
> would not.)

Yes, struct device might be enough for most use cases. However, this
would involve looking hard at the code :)

> 
> On the other hand, this proposal involves adding a fair amount of overhead
> (all those .owner fields) for a rather small benefit.  And it involves
> modifying a core kernel subsystem (kernel/module.c).  All to prevent
> certain unlikely sorts of errors when removing a module -- something which
> Linus has said repeatedly need not be supported terribly well.

The basic infrastructure isn't too hard (I'm having a patch using mkobj
on my disk that is in nearly workable state). And I think that this is
something that really should be fixed - it is just way too easy for a
driver writer to mess this up (and the race window becomes even bigger
on virtualized platforms).
-
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/