linux-kernel - Re: [PATCH] FRV: Fix the section attribute on UP DECLARE_PER

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: <20090415140959.GD12760@elte.hu>
Date:	Wed, 15 Apr 2009 16:09:59 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Howells <dhowells@...hat.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, tj@...nel.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] FRV: Fix the section attribute on UP DECLARE_PER_CPU()


* David Howells <dhowells@...hat.com> wrote:

> > There's three too 'thick' headers: linux/percpu.h, 
> > linux/prefetch.h and asm/processor.h.
> 
> Yes, I noticed.
> 
> linux/percpu.h needs to be split three ways for instance: 
> definitions, access methods, and alocators.

yeah. Often a super-header has to be split into several basic 
headers or header pairs.

> linux/prefetch.h isn't too bad: what it needs is the prefetch 
> stuff splitting out of asm/processor.h into asm/prefetch.h.

yeah.

> > Please create include/linux/percpu_types.h for basic data types 
> > and simple, self-sufficient primitives. Also have an 
> > include/linux/percpu_api.h or include/linux/percpu.h include 
> > file for convenience/speedup inlines. The latter will only be 
> > included in .c files, where 'combination' of type spaces is not 
> > a problem.
> 
> Not so.  The problem is that various header files make use of 
> per-cpu variable accessors (asm/current.h and asm/thread_info.h to 
> name a couple) to build inline asm.

Hm, what portion did you mark with 'not so'?

inline asm is used in inline functions there, and that is what 
'instantiates' the types in a 'mixed' manner and way below their 
proper hierarchic level as well - creating both a mess and, as mess 
increases above a critical threshold an inevitable circular 
dependency as well.

> Anyway, here are a pair of patches on top of the one I've already 
> sent to Linus.  The second breaks a number of header files into 
> pieces and rearranges the percpu headers to put the DECLARE and 
> DEFINE macros together.
> 
> The first patch could potentially be applied immediately.  It adds 
> #inclusions and forward refs that are required to iron out compile 
> errors from the second patch.
> 
> Note that these only work for the configuration I routinely use on 
> my x86_64 test machine.  It will break all other arches and many 
> other i386 and x86_64 configurations.

I dont disagree, but i'd like to warn that such patches need _way_ 
more testing, these are never same-day obvious patches.

We have split up one big x86 header in this development cycle 
(asm/pgtable.h) and that alone was highly non-trivial and needed 
about a week to settle down, even with intense development and 
testing.

	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/