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

From	Johannes Berg <johannes@sipsolutions.net>
Newsgroups	linux.debian.bugs.dist, linux.debian.kernel
Subject	Bug#940820: linux-image-5.2.0-2-amd64: breaks UML all versions, both debian stock and compiled from source.
Date	2019-09-20 20:20 +0200
Message-ID	<yIvFD-6nW-1@gated-at.bofh.it> (permalink)
References	<yIoE9-1qT-5@gated-at.bofh.it> <yItNv-56U-3@gated-at.bofh.it> <yItNv-56U-1@gated-at.bofh.it> <yIoE9-1qT-5@gated-at.bofh.it> <yItNv-56U-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw

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

Back to linux.debian.kernel | Previous | Next | Find similar | Unroll thread

Thread

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> - 2019-09-20 20:20 +0200

csiph-web