Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Since we allocate the maximum possible memory statically, I fail to
see how holes could make the situation any worse, or better.
No, we map enough space to map 4G (~4 pages), but we don't actually map
4G. If a hole happened to start within that 4 page mapping, then the
memory still wouldn't be available for allocation.
I think this is a bit of a spurious argument though, since if it were
really a problem we'd have to worry about holes hitting the kernel image
too. As far as I can see, that's not considered to be a problem.
I think the real point is that there's currently a subtle dependency
between head.S and bootmem allocation which happens between start_kernel
and pagetable_init. Your patch preventing over-mapping should make them
easier to smoke out as it currently stands, but eliminating the problem
by making alloc_bootmem create the mappings for itself does have
appeal. There would still be the dependency on head.S to map the kernel
itself and the bootmem allocator bitmap.
Agreed. However, saying that your patch shouldn't go into the mainline
kernel until that has been fixed is spurious and wrong. It fixes a real
problem with minimal risk.
-hpa
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
