linux-kernel - Re: ia64 broken by transparent huge pages

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110115155925.GT9506@random.random>
Date:	Sat, 15 Jan 2011 16:59:25 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arch@...r.kernel.org
Subject: Re: ia64 broken by transparent huge pages - other arches too?

On Sat, Jan 15, 2011 at 06:21:36PM +1100, Benjamin Herrenschmidt wrote:
> This is insane. Having such a massively invasive change to the whole mm,
> barely tested on most architecture, and last I heard still generally
> controversial being merged like that without even some integration
> testing via -next makes no sense.

This is 99% a noop for all archs but x86.. Really if you worry about
the testing you should worry about x86 only! Only x86 is affected by
the brainer part of the code, and only if TRANSPARENT_HUGEPAGE=y
(which is set to N by default).

Not x86 archs can't possibly have a regression because of this. The
reason there's this compile trouble is that I cleaned up some bad code
in include/asm-generic/pgtable.h while adding the pmd methods, and I
tried to keep everything as a static inline as requested by Mel for
better gcc compile time validation than what the preprocessor can
do. Otherwise if it was a macro I may not have had to return
anything and I could just BUG() in this pmd method that requires the
__pmd macro to be implemented by all archs (I think it's better off if
__pmd is available considering __pte seems already available).

The below can't introduce regressions, if it builds it'll work, so the
testing on -next for the other archs isn't really necessary at all. I
don't think you can worry about a one liner change to make ia64 build,
when the brainer part of the code is a noop for the other archs
(including x86 when the config option is off).
--
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/