linux-kernel - Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

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: <20190612075049.GB17662@kroah.com>
Date:   Wed, 12 Jun 2019 09:50:49 +0200
From:   Greg KH <greg@...ah.com>
To:     Rolf Eike Beer <eb@...ix.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        stable@...r.kernel.org, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

On Wed, Jun 12, 2019 at 09:19:15AM +0200, Rolf Eike Beer wrote:
> Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
> > On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
> > > On Thu, Jun 6, 2019 at 5:29 PM Greg KH <greg@...ah.com> wrote:
> > > > And if you want this, you should look at how the backports to 4.14.y
> > > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use
> > > > feature checks instead of version checks"), as that gets really messy...
> > > 
> > > I am confused -- I interpreted Rolf's message as reporting that he
> > > already successfully built 4.9 by applying a6e60d84989f
> > > ("include/linux/module.h: copy __init/__exit attrs to
> > > init/cleanup_module") and manually fixing it up. But maybe I am
> > > completely wrong... :-)
> > 
> > "manually fixing it up" means "hacked it to pieces" to me, I have no
> > idea what the end result really was :)
> > 
> > If someone wants to send me some patches I can actually apply, that
> > would be best...
> 
> Hi all,
> 
> the patch I actually used was this:
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 8fa38d3e7538..f5bc4c046461 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -129,13 +129,13 @@ extern void cleanup_module(void);
>  #define module_init(initfn)					\
>  	static inline initcall_t __maybe_unused __inittest(void)		\
>  	{ return initfn; }					\
> -	int init_module(void) __attribute__((alias(#initfn)));
> +	int init_module(void) __attribute__((__copy__(initfn))) __attribute__((alias(#initfn)));
>  
>  /* This is only required if you want to be unloadable. */
>  #define module_exit(exitfn)					\
>  	static inline exitcall_t __maybe_unused __exittest(void)		\
>  	{ return exitfn; }					\
> -	void cleanup_module(void) __attribute__((alias(#exitfn)));
> +	void cleanup_module(void) __attribute__((__copy__(exitfn))) __attribute__((alias(#exitfn)));
>  
>  #endif
>  
> 
> So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If
> yes then we can probably get this patches into shape.

Eventually, yes, we (or at least I) will want to build 4.9.x with gcc
9.x.  We went through this same process for gcc 8.x as all of my builder
test machines switched their default version of gcc...

thanks,

greg k-h