All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Jaswinder Singh Rajput <jaswinderrajput@gmail.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [mingo@elte.hu: [git pull] headers_check fixes]
Date: Wed, 28 Jan 2009 07:06:54 +0530	[thread overview]
Message-ID: <1233106614.3256.6.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.00.0901271441280.3123@localhost.localdomain>

On Tue, 2009-01-27 at 14:57 -0800, Linus Torvalds wrote:

> 
> The thing is, the headers_check stuff is just wrong if it causes these 
> things, and I'd rather just turn it off.
> 

Basic idea of headers_check is:
1. clean header files so that they do not export useless things in userspace, like:
    usr/include/linux/elf-fdpic.h:62: extern's make no sense in userspace

2. provide sufficient stuff like:
   usr/include/asm/swab.h:7: found __[us]{8,16,32,64} type without #include <linux/types.h>

3. warns about exporting kernel space defines which are not valid in userspace and is always false for userspace
   usr/include/asm/swab.h:10: leaks CONFIG_X86 to userspace where it is not valid

And by headers_check tools we also able to find blunder mistakes which are very difficult to find by naked eye like:
   usr/include/asm-generic/fcntl.h:127: leaks CONFIG_64BIT to userspace where it is not valid 
for userspace this will be always false.
and some files was totally covered with ifdefs CONFIG_* and exported which are useless like:
  usr/include/linux/if_frad.h:29: leaks CONFIG_DLCI to userspace where it is not valid


> If those 
> 
> 	#ifdef CONFIG_XYZ
> 
> things result in problems, then we should just make the rule be that we 
> turn that kind of string into
> 
> 	#if 0
> 

This will looks ugly in userspace with so many #if 0 and make impossible
to read the code.

> automatically when exporting the kernel headers. IOW, just about 
> _anything_ that headers_check complains about automatically is something 
> that should just be _fixed_ automatically at header install time rather 
> than make the code harder to read.
> 
> So I think it makes our headers worse. Code like
> 
> 	> +#ifdef __KERNEL__
> 	> +# ifdef CONFIG_X86_BSWAP
> 	> +# define __X86_BSWAP  
> 	> +# endif /* CONFIG_X86_BSWAP */
> 	> +#endif /* __KERNEL__ */
> 
> just doesn't make sense. It doesn't make sense _inside_ the kernel, and it 
> doesn't make sense _outside_ it either.
> 

my earlier patch was like this:

diff --git a/arch/x86/include/asm/swab.h b/arch/x86/include/asm/swab.h
index 306d417..613be68 100644
--- a/arch/x86/include/asm/swab.h
+++ b/arch/x86/include/asm/swab.h
@@ -1,12 +1,15 @@
 #ifndef _ASM_X86_SWAB_H
 #define _ASM_X86_SWAB_H
 
-#include <asm/types.h>
+#include <linux/types.h>
+#ifdef __KERNEL__
 #include <linux/compiler.h>
+#endif /* __KERNEL__ */
 
 static inline __attribute_const__ __u32 __arch_swab32(__u32 val)
 {
 #ifdef __i386__
+#ifdef __KERNEL__
 # ifdef CONFIG_X86_BSWAP
        asm("bswap %0" : "=r" (val) : "0" (val));
 # else
@@ -16,7 +19,13 @@ static inline __attribute_const__ __u32
__arch_swab32(__u32 val)
            : "=q" (val)
            : "0" (val));
 # endif
-
+#else /* __KERNEL__ */
+       asm("xchgb %b0,%h0\n\t" /* swap lower bytes     */
+           "rorl $16,%0\n\t"   /* swap words           */
+           "xchgb %b0,%h0"     /* swap higher bytes    */
+           : "=q" (val)
+           : "0" (val));
+#endif /* __KERNEL__ */
 #else /* __i386__ */
        asm("bswapl %0"
            : "=r" (val)
@@ -37,6 +46,7 @@ static inline __attribute_const__ __u64
__arch_swab64(__u64 val)
                __u64 u;
        } v;
        v.u = val;
+#ifdef __KERNEL__
 # ifdef CONFIG_X86_BSWAP
        asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
            : "=r" (v.s.a), "=r" (v.s.b)
@@ -48,6 +58,13 @@ static inline __attribute_const__ __u64
__arch_swab64(__u64 val)
            : "=r" (v.s.a), "=r" (v.s.b)
            : "0" (v.s.a), "1" (v.s.b));
 # endif
+#else /* __KERNEL__ */
+       v.s.a = __arch_swab32(v.s.a);
+       v.s.b = __arch_swab32(v.s.b);
+       asm("xchgl %0,%1"
+           : "=r" (v.s.a), "=r" (v.s.b)
+           : "0" (v.s.a), "1" (v.s.b));
+#endif /* __KERNEL__ */
        return v.u;
 #else /* __i386__ */
        asm("bswapq %0"

to get rid of multiple blocks so I used above technique.

If we do not want to export __arch_swab32 and __arch_swab64 then we can
put whole block in #ifdef __KERNEL__ then we will get rid of above
solution.

--
JSR


  parent reply	other threads:[~2009-01-28  1:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090127222825.GA27097@elte.hu>
2009-01-27 22:57 ` [mingo@elte.hu: [git pull] headers_check fixes] Linus Torvalds
2009-01-27 23:22   ` H. Peter Anvin
2009-01-27 23:29     ` Linus Torvalds
2009-01-28  0:12       ` H. Peter Anvin
2009-01-28  0:19         ` Linus Torvalds
2009-01-28  1:02           ` H. Peter Anvin
2009-01-27 23:31   ` Ingo Molnar
2009-01-27 23:43     ` Linus Torvalds
2009-01-27 23:51     ` Vegard Nossum
2009-01-30 14:01     ` Jaswinder Singh Rajput
2009-01-30 18:20       ` Ingo Molnar
2009-01-28  0:03   ` Harvey Harrison
2009-01-28  1:36   ` Jaswinder Singh Rajput [this message]
2009-01-28 12:37     ` Arnd Bergmann
2009-01-28 17:48       ` H. Peter Anvin
2009-01-28 19:22         ` Harvey Harrison
2009-01-28 19:44           ` Linus Torvalds
2009-01-28 20:03             ` Harvey Harrison
2009-01-28 21:25               ` H. Peter Anvin
2009-01-28 21:58                 ` [PATCH] x86: do not expose CONFIG_BSWAP to userspace Harvey Harrison
2009-01-28 22:13                   ` Linus Torvalds
2009-01-28 22:40                     ` Harvey Harrison
2009-01-30 20:37                       ` Pavel Machek
2009-01-28 22:15                   ` H. Peter Anvin
2009-01-28 22:38                     ` Harvey Harrison
2009-01-28 23:04                       ` Ben Pfaff
2009-01-30 18:20                         ` H. Peter Anvin
2009-01-28 23:27                       ` H. Peter Anvin
2009-01-28 23:36                         ` Harvey Harrison
2009-01-28 23:47                           ` H. Peter Anvin
2009-02-03 18:19                             ` Arnd Bergmann
2009-01-31 18:43                       ` Maciej W. Rozycki
2009-01-31 20:24                         ` H. Peter Anvin
2009-01-28 23:24                     ` Arnd Bergmann
2009-01-28 23:30                       ` H. Peter Anvin
2009-01-28 20:49             ` [mingo@elte.hu: [git pull] headers_check fixes] Sam Ravnborg
2009-01-28 21:23           ` H. Peter Anvin
2009-01-28 21:06   ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1233106614.3256.6.camel@localhost.localdomain \
    --to=jaswinder@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=jaswinderrajput@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.