On Thu, 2008-08-07 at 16:08 -0700, Linus Torvalds wrote:
quoted text
> 
> On Thu, 7 Aug 2008, H. Peter Anvin wrote:
> >
> > Just moving it down by 4 MB doesn't help, since the VMI guys want as much as
> > 64 MB, which is half the standard vmalloc area and hence too much address
> > space lost.  We can't put it at the bottom of the vmalloc area, since that
> > boundary is not fixed, either.
> 
> Yeah, ok. Since this is a 32-bit only issue, 64MB is actually a fair chunk
> of our already limited virtual space.
> 
> > The one remaining fixed boundary in the machine is the kernel-userspace
> > boundary.  Hence moving the 1:1 area up by one PDE unit and sticking the
> > fixmap area in that region.
> 
> Yeah, ok, but I'd be more nervous about the validation issues there. There
> might be a lot of code that assumes that TASK_SIZE is the start of the 1:1
> area. It does sound like a good approach, it just makes me worry about the
> test coverage.

Well, here's an idea from outer space.  The fixmap can't possibly be
used until it's got a backing page table and initial mappings installed.
One can imagine a world where references to the fixmap are left as
unresolved, and then those unresolved symbols are linked to the fixmap
area when it gets set up in the kernel page table.  Voilla!

The requisite foodling required to massage various gcci and lds into
compliance with this scheme, not to mention the required module loading
changes might be a bit of headache, and even then, I'm not sure that gcc
will be smart enough to allow all the required relocations to generate
optimal code.

But the upshot would be the potential for dynamic registration of fixmap
areas, yet still keeping direct pointers into the thing, and also
removing all the ifdefs from the fixmap definitions for the various
platform specific fixmap pages.  Just leave dangling references to some
fixed bad address (fixmap_hole) for things unused.  And even allow
kernel modules to register new fixmap types!

All it requires is a well thought out strategy for naming fixmap pages
and then two sprinkles of linker magic.  You could even randomize the
non-randomized VDSO location at boot-time.  Whee!

Zach

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/