Bug#940820: linux-image-5.2.0-2-amd64: breaks UML all versions, both debian stock and compiled from source.

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2019-09-20 at 16:57 +0100, Anton Ivanov wrote:
> Looks like the culprit is a different default elf start address on 5.x
> 
> What changes is not the sbrk(0) or _end - these are pretty much 
> identical as in 4.x. It is the START which after some "fixups" in 
> arch/um/kernel/uml.lds.S becomes __binary_start

Doesn't this just use sbrk(0) to basically detect the end of the
"regular" part of the binary that's mapped by the loader, i.e. basically
"uml_reserved"? At least that's what I thought when I looked.

And if so, perhaps we could detect all this differently? Or even place
the (mmap'ed) physical memory somewhere else? I'd think nothing really
should care if it's contiguous or not?

If we did that we wouldn't have the whole thing contiguous in memory,
but do we really need to? Hmm. Maybe we do, so we don't have huge page
tables or something?

But then again, isn't the difference basically where the binary is
mapped, maybe we could mark it as non-relocatable?

johannes