linux-kernel - Re: [PATCH 1/20] x86_64: Assembly safe page.h and pgtable.h

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: <20070308060139.GJ6000@in.ibm.com>
Date:	Thu, 8 Mar 2007 11:31:39 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Reloc Kernel List <fastboot@...ts.osdl.org>,
	ebiederm@...ssion.com, akpm@...ux-foundation.org, ak@...e.de,
	hpa@...or.com, magnus.damm@...il.com, lwang@...hat.com,
	dzickus@...hat.com, pavel@...e.cz, rjw@...k.pl
Subject: Re: [PATCH 1/20] x86_64: Assembly safe page.h and pgtable.h

On Wed, Mar 07, 2007 at 08:24:04PM +0100, Sam Ravnborg wrote:
> On Wed, Mar 07, 2007 at 12:29:20PM +0530, Vivek Goyal wrote:
> > 
> > 
> > This patch makes pgtable.h and page.h safe to include
> > in assembly files like head.S.  Allowing us to use
> > symbolic constants instead of hard coded numbers when
> > refering to the page tables.
> > 
> > This patch copies asm-sparc64/const.h to asm-x86_64 to
> > get a definition of _AC() a very convinient macro that
> > allows us to force the type when we are compiling the
> > code in C and to drop all of the type information when
> > we are using the constant in assembly.
> Should this file not live in asm-generic and be useable
> for all architectures?
> 

Hi Sam,

Thanks for the review. This makes sense to me. Move const.h into
asm-generic and let everybody use it.

This is more of a small cleanup issue and involves changing few header files
in asm-sparc64 and make sure nothing is broken on sparc64. This patchset
is already becoming big and complex. Is it ok if we let the patch 
remain unmodified for now and once this gets in and settles down, I can
post another patch to do above modification?

Thanks
Vivek
-
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/