linux-kernel - Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.

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:	Sun, 3 Feb 2008 07:46:45 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	benh@...nel.crashing.org, schwidefsky@...ibm.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables.

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > It's a sane patch and a helps going further, and a total pain to 
> > re-do later on. Besides, I may have some use for it on powerpc at 
> > some point too...
> 
> OK, I'll try to reestablish it.
> 
> Look: I can't fix *everyone's* stuff.  This was a consequence of 
> ongoing unbounded churn in the x86 tree. [...]

i've reviewed this patchset and the right model appears to me to do this 
change upstream right now, atomically. It is supposed to be a pure 
functional NOP, and any deviation from that is easy to spot.

  Acked-by: Ingo Molnar <mingo@...e.hu>

I dont think it's particular wise to maintain a change like this across 
all the arch churn, for months. This patch is a pure cleanup, it could 
have been merged two months ago. The author should get agreement that 
it's fine to do it, and if the timing happens to be unfortunate for 
immediate merging (we are within say 1 month window before stable 
release) then delay it and redo the cleanup right when it's about to be 
merged.

The worst thing to do is to prolong this for months - it is only 
unnecessary work for no particular good reason. It complicates -mm 
merging, keeps an API fork around for no good reason, etc., etc.

there's tons of past examples of much larger transformations than this 
done right: for example the recent irq_regs changes. (and that one wasnt 
even a pure NOP like this change.)

In general, we can pick up the x86 bits of any tree-wide change into 
x86.git no problem, and then maintain it against all the nuances of 
x86.git churn. (That requires them to be shaped in a way so that they 
can be applied to one architecture at a time - which is obviously a good 
thing anyway - but not always possible, such as in this case where a 
common API is extended.)

If anyone is feeling _any_ serious effects of x86.git churn then please 
talk to us maintainers and we can work out some technical solution. The 
only thing we cannot do is to stop 100 active contributors and the flow 
of 1000 patches until someone finds the time to get tree-wide changes 
upstream.

Roland was able to shape his utrace-enabler regset patches upstream this 
way, and it is two or three orders of magnitude more complex of a code 
transformation than the one we are talking about here.

	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/