linux-kernel - Re: [PATCH] [30/30] x86_64: Add missing !X86

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: <20070501130132.GL26598@holomorphy.com>
Date:	Tue, 1 May 2007 06:01:32 -0700
From:	Bill Irwin <bill.irwin@...cle.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Eric Dumazet <dada1@...mosbay.com>, ebiederm@...ssion.com,
	patches@...-64.org, linux-kernel@...r.kernel.org,
	bill.irwin@...cle.com
Subject: Re: [PATCH] [30/30] x86_64: Add missing !X86_PAE dependincy to the 2G/2G split.

On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>> Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change 
>> PAGE_OFFSET to 0x8000000 instead of 0x78000000 and keep 2G/2G split ?

On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
> I dropped the patch for now.

I'm more miffed about what it's cleaning up after than the patch itself.

On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>> [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE
>> When in PAE mode we require that the user kernel divide to be
>> on a 1G boundary.  We must therefore make sure PAGE_OFFSET is correctlty 
>> defined in the 2G/2G split and PAE mode.

On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
> Looks reasonable. Did you test both cases? wli, ok for you too?

Sorry about the delay in replying.

I don't mind so long as we're not letting doorstop configs through. I'd
probably do something more like

Index: sched/arch/i386/Kconfig
===================================================================
--- sched.orig/arch/i386/Kconfig	2007-05-01 04:35:47.065162310 -0700
+++ sched/arch/i386/Kconfig	2007-05-01 04:36:50.100754504 -0700
@@ -571,6 +571,9 @@
 		bool "3G/1G user/kernel split (for full 1G low memory)"
 	config VMSPLIT_2G
 		bool "2G/2G user/kernel split"
+	config VMSPLIT_2G_OPT
+		depends on !HIGHMEM
+		bool "2G/2G user/kernel split (for full 2G low memory)"
 	config VMSPLIT_1G
 		bool "1G/3G user/kernel split"
 endchoice
@@ -578,7 +581,8 @@
 config PAGE_OFFSET
 	hex
 	default 0xB0000000 if VMSPLIT_3G_OPT
-	default 0x78000000 if VMSPLIT_2G
+	default 0x80000000 if VMSPLIT_2G
+	default 0x78000000 if VMSPLIT_2G_OPT
 	default 0x40000000 if VMSPLIT_1G
 	default 0xC0000000

as a stopgap measure, but I'm not all that interested in grabbing patch
credits where others could do it easily enough. Either of the config
alterations is fine by me as they now stand; maybe Eric Dumazet might
care to do something like my suggestion at some point.

My interest here is in approaches that aren't really centered around
config options. Those are pmd handling for 1GB-unaligned PAGE_OFFSET
in PAE and dynamic vmallocspace reservation, the latter of which is
more complex than the first. I'd probably only do the pmd handling as
it's much easier than dynamic vmallocspace, which does substantial
violence to the core in order to reserve chunks of ZONE_NORMAL's
virtualspace so that no boot-time virtualspace reservations need to be
made for vmalloc(). Basically it would make vmalloc() proper use
physically contiguous memory and vmap() fiddle with ZONE_NORMAL
pagetables while reserving physical memory underlying the virtualspace
reserved for vmap() so that it's no longer necessary to carve
vmallocspace out of userspace to avoid highmem. That would occur at the
cost of runtime memory footprint of the rarely-called vmap() and
ZONE_NORMAL mapping updates. It would also alleviate pressure on
vmallocspace in configurations where it would be severely limited.

I'm doing a bit of thinking about this laptop-avoiding-highmem problem.
I've not come up with any better ideas than the dynamic vmallocspace
approach to avoid ABI damage while avoiding both highmem and sacrificing
memory for 1GB laptops, and slightly mitigating ABI damage for 2GB
laptops' highmem avoidance efforts. I'm thinking the applicability
isn't broad enough to merit the effort of dynamic vmallocspace. The pmd
fixup for 1GB-unaligned splits is not such a big deal in comparison.

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