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:	Thu, 07 Aug 2008 18:14:05 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...nel.org>,
	Alok Kataria <akataria@...are.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH]Fix broken VMI in 2.6.27-rc..

On Thu, 2008-08-07 at 17:10 -0700, Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
> > Jeremy Fitzhardinge wrote:
> >> H. Peter Anvin wrote:
> >>> The fixmap area should never have been made movable.  It's utter
> >>> braindamage.
> >>
> >> Shrug.  It's been like that for a couple of years now.  It was one of
> >> the very first paravirt-ops patches.  It wasn't controversial then,
> >> and nobody seems to have noticed since.
> >
> > The Linux kernel was never a paragon of perfection - it was never
> > meant to be.  Just because a bit of cruft went unnoticed into the
> > kernel doesn't mean we shouldn't fix it.
> 
> I don't really see what the issue is.
> 
> Fixmaps are primarily used for things that need to be mapped early
> before we can allocate address space dynamically.  They're predominantly
> used for boot-time init, and rarely on any performance-critical path.
> The only vaguely regular use a fixmap gets during runtime is poking at
> apics, and that's dominated by IO time, and kmap_atomic.  Statically,
> there's only 100 references in the kernel.  And it only affects 32-bit.
> 
> Having fixmaps at link-time fixed addresses would be nice, I suppose,
> but hardly worth going to vast effort over.

Using my interplanetary ideas, linking the fixmap at runtime would allow
optimal placement of the fixmap, any hypervisor areas, vmalloc, and
pkmap space.  That might allow one to increase the amount of lowmem
available for direct mapping depending on some platform variables such
as hypervisor reserved space, physical memory size, APIC present.. those
aren't known until boot time.  Actually, NCPUs is a good one, since we
require atomic kmap space dependent on NCPUs, which could be given back
to linear memory map.

That might actually be more worthwhile than link time fixed addresses.

Zach

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ