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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1295110048.5973.36.camel@mulgrave.site>
Date:	Sat, 15 Jan 2011 10:47:28 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"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, 2011-01-15 at 16:59 +0100, Andrea Arcangeli wrote:
> 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).

Andrea, what you say above isn't true, you're not thinking broadly
enough: the kernel is a complex set of code interactions.  For instance,
you caused this build break on parisc (which is a regression even though
parisc has no transparent huge pages at all):

http://marc.info/?l=linux-arch&m=129504371532124

That was just from a simple code rearrangement (independent of any of
the config options).

One of the points of getting stuff through linux-next is that all of
these problems get sorted out long before the code hits mainline.  This
happens because linux-next gets a wide range of config randomisation
testing plus quite a few different architecture builds and runs.

The problem is very often not in the actual code, but in the side
effects the code causes.  This is what linux-next integration helps
mitigate. So, please use it next time.  Just testing on x86 in your own
configuration isn't sufficient to pick up the problems.

James


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