linux-kernel - Re: [PATCH] x86/boot: use __noreturn instead of directly __attribute_

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: <20150407083527.GA9368@gmail.com>
Date:	Tue, 7 Apr 2015 10:35:27 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Alexander Kuleshov <kuleshovmail@...il.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86/boot: use __noreturn instead of directly
 __attribute__ definition


* Alexander Kuleshov <kuleshovmail@...il.com> wrote:

> arch/x86/boot/boot.h defines a couple functions as die and etc..., with
> 'noreturn' attribute. Let's use __noreturn macro instead of directly
> __attribute__ declaration from the <linux/compiler.h>.
> 
> We no need to include <linux/compiler.h> to the arch/x86/boot/boot.h,
> because boot.h already includes "bitops.h" which already includes
> <linux/compiler.h>.
> 
> Signed-off-by: Alexander Kuleshov <kuleshovmail@...il.com>
> ---
>  arch/x86/boot/boot.h | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
> index bd49ec6..3351528 100644
> --- a/arch/x86/boot/boot.h
> +++ b/arch/x86/boot/boot.h
> @@ -305,7 +305,7 @@ void console_init(void);
>  void query_edd(void);
>  
>  /* header.S */
> -void __attribute__((noreturn)) die(void);
> +void __noreturn die(void);
>  
>  /* mca.c */
>  int query_mca(void);
> @@ -314,11 +314,10 @@ int query_mca(void);
>  int detect_memory(void);
>  
>  /* pm.c */
> -void __attribute__((noreturn)) go_to_protected_mode(void);
> +void __noreturn go_to_protected_mode(void);
>  
>  /* pmjump.S */
> -void __attribute__((noreturn))
> -	protected_mode_jump(u32 entrypoint, u32 bootparams);
> +void __noreturn protected_mode_jump(u32 entrypoint, u32 bootparams);
>  
>  /* printf.c */
>  int sprintf(char *buf, const char *fmt, ...);

Please don't bother producing and sending me such trivial patches 
unless they:

  - fix a real bug (in which case they are not trivial patches anymore)

  - or are part of a larger (non-trivial!) series that does some real, 
    substantial work on this code that tries to:

         - fix existing code
         - speed up existing code
         - or expand upon existing code with new code

The reason I'm not applying your patch is that trivial patches with no 
substance following them up have more costs than benefits:

 - they lead to pointless churn:

    - they take up Git space for no good reason
    - they slow down bisection of real changes
    - they take up (valuable!) reviewer bandwidth
    - they take up maintainer bandwidth

there's literally a million pointless cleanup patches that could be 
done on the kernel, and we don't want to add a million commits to the 
kernel tree.

This applies for this patch but also for other future patches you 
might intend to send for code that I (co-)maintain.

My advice to you is to try to raise beyond newbie patches and write 
something more substantial that helps Linux:

 - take a look at the many bugs on bugzilla.kernel.org and try to 
   analyze, reproduce or fix them

 - go read kernel code, understand it and try to find real bugs.

 - go test the latest kernels and find bugs in it. The fresher the 
   code, the more likely it is that it has bugs.

 - go read kernel code and try to expand upon it

Fortunately it's not hard to contribute to the kernel: there's 
literally an infinite amount of work to be done on the kernel, and I 
welcome productive contributions - but churning out trivial patches 
with no substantial patches following them up is not productive and in 
fact they are harmful once you are not a totally fresh newbie kernel 
developer anymore...

Thanks,

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