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]
Date:	Tue, 17 Jul 2007 18:48:46 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Domen Puncer <domen.puncer@...argo.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] introduce __init_exit function annotation

On Tue, Jul 17, 2007 at 05:40:15PM +0200, Takashi Iwai wrote:
> At Tue, 17 Jul 2007 17:32:36 +0200,
> Sam Ravnborg wrote:
> > 
> > On Tue, Jul 17, 2007 at 05:16:13PM +0200, Takashi Iwai wrote:
> > > At Tue, 17 Jul 2007 17:14:32 +0200,
> > > Sam Ravnborg wrote:
> > > > 
> > > > On Tue, Jul 17, 2007 at 04:52:12PM +0200, Takashi Iwai wrote:
> > > > > At Tue, 17 Jul 2007 15:02:30 +0200,
> > > > > Sam Ravnborg wrote:
> > > > > > 
> > > > > > On Tue, Jul 17, 2007 at 10:02:48AM +0200, Domen Puncer wrote:
> > > > > > > Introduce __init_exit, which is useful ie. for drivers that call
> > > > > > > cleanup functions when they fail in __init functions.
> > > > > > 
> > > > > > This is wrong.
> > > > > > On arm (just one example of several) the __exit section are discarded
> > > > > > at buildtime so any reference from __init to __exit will cause the
> > > > > > linker to error out.
> > > > > 
> > > > > Hmm, from what I see, it adds __init to the function.  There is no
> > > > > reference to __exit.
> > > > 
> > > > The cleanup functions are marked __exit in the referenced case.
> > > 
> > > My understanding is that it's the very purpose of this patch --
> > > change the mark from __exit to __init_exit for such clean-up
> > > functions.
> > 
> > And that is wrong.
> 
> You misunderstood.  What I meant is the case like this:
> 
> static void __init_exit cleanup()
> {
> 	...
> }
> 
> static void __init foo_init()
> {
> 	if (error)
> 		cleanup();
> }
> 
> static void __exit foo_exit()
> {
> 	cleanup();
> }
> 
> Currently, there is no proper way to mark cleanup().  Neither __init,
> __exit, __devinit nor __devexit can be used there.

Then you get the annotation sorted out so cleanup() get discarded in the
built-in case. But you leave no room for automated tools to detect this.

If this is really necessary (and I daught) then a specific section should be
dedicated for this usage.

We have lot of issues with current __init/__exit, __devinit/__devexit, __cpuint/__cpuexit
and introducing more of the kind does not help it.
So even if it saves a few bytes in some odd cases the added complaxity is IMHO not worth it.

	Sam
-
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/

Powered by blists - more mailing lists