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:	Fri, 06 Feb 2009 19:48:42 +0530
From:	Jaswinder Singh Rajput <jaswinder@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	hskinnemoen@...el.com, cooloney@...nel.org, ralf@...ux-mips.org,
	dhowells@...hat.com, matthew@....cx, chris@...kel.net,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull -tip] headers_check fixes for other architectures

On Fri, 2009-02-06 at 03:20 +0100, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
> 
> > On Thu, 2009-02-05 at 20:19 +0100, Ingo Molnar wrote:
> > 
> > > Jaswinder, because they can break the build we should proactively drop all 
> > > architecture patches that do asm/types.h conversions.
> > > 
> > > I did build all the affected architectures via their defconfigs and they 
> > > built just fine - but i cannot do wide coverage testing of them.
> > > 
> > > So i think we should drop these bits:
> > > 
> > >  earth4:~/tip> gll --grep='asm/types.h' linus..core/header-fixes
> > >  1ff8f73: headers_check fix: xtensa, swab.h
> > >  4810987: headers_check fix: powerpc, swab.h
> > >  9f2cd96: headers_check fix: powerpc, kvm.h
> > >  785857f: headers_check fix: powerpc, elf.h
> > >  4be2c7f: headers_check fix: powerpc, bootx.h
> > >  726da1e: headers_check fix: parisc, swab.h
> > >  bef53ca: headers_check fix: mn10300, swab.h
> > >  a9f6acc: headers_check fix: mips, swab.h
> > >  d8cbec1: headers_check fix: m32r, swab.h
> > >  040c92b: headers_check fix: ia64, swab.h
> > >  6ce7950: headers_check fix: ia64, kvm.h
> > >  fa9ea6c: headers_check fix: ia64, fpu.h
> > >  295803e: headers_check fix: h8300, swab.h
> > >  dacd762: headers_check fix: frv, swab.h
> > >  350eb8b: headers_check fix: blackfin, swab.h
> > >  1c6ce70: headers_check fix: avr32, swab.h
> > >  e42ec24: headers_check fix: arm, swab.h
> > >  4af3bf6: headers_check fix: arm, setup.h
> > >  f100e6d: headers_check fix: arm, a.out.h
> > >  3fd5906: headers_check fix: alpha, swab.h
> > > 
> > > and send the rest to Linus if all outstanding observations have been 
> > > addressed. What do you think?
> > > 
> > 
> > The problem is if we include linux/types.h in assembly file we will get
> > error.
> > 
> > We can solve this problem by four options (or may be more):
> > 1. by wrapping #ifndef __ASSEMBLY__ files which are used by assembly
> > code as suggested by Tony.
> > 
> > 2. fix linux/types.h so that assembly file can also use it
> > 
> > 3. drop patches which are used by assembly files
> > 
> > 4. drop all architecture patches as you suggested.
> 
> hm, the highest quality approach seems to be #2, right?
> 

Is this safe OR we can make it more safer:

Subject: [PATCH] make linux/types.h as assembly safe

Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@...il.com>
---
 include/linux/types.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/include/linux/types.h b/include/linux/types.h
index 712ca53..c30973a 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_TYPES_H
 #define _LINUX_TYPES_H
 
+#ifndef __ASSEMBLY__
 #ifdef	__KERNEL__
 
 #define DECLARE_BITMAP(name,bits) \
@@ -212,5 +213,5 @@ struct ustat {
 };
 
 #endif	/* __KERNEL__ */
-
+#endif /*  __ASSEMBLY__ */
 #endif /* _LINUX_TYPES_H */
-- 
1.6.0.6



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

Powered by Openwall GNU/*/Linux Powered by OpenVZ