From: Benjamin Berg
When loading the UML binary, the host kernel will place the stack at the
highest possible address. It will then map the program name and
environment variables onto the start of the stack.
As such, an easy way to figure out the host_task_size is to use the
highest pointer to a
From: Benjamin Berg
The larger memory space is useful to support more applications inside
UML. One example for this is ASAN instrumentation of userspace
applications which requires addresses that would otherwise not be
available.
Signed-off-by: Benjamin Berg
---
v2:
- Do not hide option behin
From: Benjamin Berg
Sorry for the noise, but I noticed that v3 has an issue on some host
kernels, so I changed the waitpid back to how it was before CLONE_VFORK.
This patchset fixes a few bugs, adds a new method of discovering the
host task size and finally adds four level page table support. Al
From: Benjamin Berg
We may have a TASK_SIZE from the host that is bigger than UML is able to
address with a three-level pagetable. Guard against that by clipping the
maximum TASK_SIZE to the maximum addressable area.
Signed-off-by: Benjamin Berg
---
arch/um/kernel/um_arch.c | 7 ++-
1 file
From: Benjamin Berg
Newer glibc versions are enabling rseq support by default. This remains
enabled in the cloned child process, potentially causing the host kernel
to write/read memory in the child.
It appears that this was purely not an issue because the used memory
area happened to be above T
From: Benjamin Berg
The calculation was wrong as it only subtracted one and then rounded
down for alignment. However, this is incorrect if host_task_size is not
already aligned.
This probably worked fine because on 64 bit the host_task_size is bigger
than returned by os_get_top_address.
Signed-
On Wed, Jun 12, 2024 at 05:00:30PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 12, 2024 at 10:01:18AM +0200, Roger Pau Monné wrote:
> > On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> > > blkfront always had a robust negotiation protocol for detecting a write
> > > cache. St
On Wed, Jun 12, 2024 at 10:01:18AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> > blkfront always had a robust negotiation protocol for detecting a write
> > cache. Stop simply disabling cache flushes when they fail as that is
> > a grave err
On Tue, 11 Jun 2024 at 07:24, Christoph Hellwig wrote:
>
> Move the cache control settings into the queue_limits so that they
> can be set atomically and all I/O is frozen when changing the
> flags.
>
> Add new features and flags field for the driver set flags, and internal
> (usually sysfs-contro
From: Benjamin Berg
Newer glibc versions are enabling rseq support by default. This remains
enabled in the cloned child process, potentially causing the host kernel
to write/read memory in the child.
It appears that this was purely not an issue because the used memory
area happened to be above T
From: Benjamin Berg
The larger memory space is useful to support more applications inside
UML. One example for this is ASAN instrumentation of userspace
applications which requires addresses that would otherwise not be
available.
Signed-off-by: Benjamin Berg
---
v2:
- Do not hide option behin
From: Benjamin Berg
When loading the UML binary, the host kernel will place the stack at the
highest possible address. It will then map the program name and
environment variables onto the start of the stack.
As such, an easy way to figure out the host_task_size is to use the
highest pointer to a
From: Benjamin Berg
We may have a TASK_SIZE from the host that is bigger than UML is able to
address with a three-level pagetable. Guard against that by clipping the
maximum TASK_SIZE to the maximum addressable area.
Signed-off-by: Benjamin Berg
---
arch/um/kernel/um_arch.c | 7 ++-
1 file
From: Benjamin Berg
This patchset fixes a few bugs, adds a new method of discovering the
host task size and finally adds four level page table support. All of
this means the userspace TASK_SIZE is much larger and in turns permits
userspace applications that need a lot of virtual addresses to work
From: Benjamin Berg
The calculation was wrong as it only subtracted one and then rounded
down for alignment. However, this is incorrect if host_task_size is not
already aligned.
This probably worked fine because on 64 bit the host_task_size is bigger
than returned by os_get_top_address.
Signed-
From: Benjamin Berg
The larger memory space is useful to support more applications inside
UML. One example for this is ASAN instrumentation of userspace
applications which requires addresses that would otherwise not be
available.
Signed-off-by: Benjamin Berg
---
v2:
- Do not hide option behin
From: Benjamin Berg
When loading the UML binary, the host kernel will place the stack at the
highest possible address. It will then map the program name and
environment variables onto the start of the stack.
As such, an easy way to figure out the host_task_size is to use the
highest pointer to a
From: Benjamin Berg
We may have a TASK_SIZE from the host that is bigger than UML is able to
address with a three-level pagetable. Guard against that by clipping the
maximum TASK_SIZE to the maximum addressable area.
Signed-off-by: Benjamin Berg
---
arch/um/kernel/um_arch.c | 7 ++-
1 file
From: Benjamin Berg
Newer glibc versions are enabling rseq support by default. This remains
enabled in the cloned child process, potentially causing the host kernel
to write/read memory in the child.
It appears that this was purely not an issue because the used memory
area happened to be above T
From: Benjamin Berg
This patchset fixes a few bugs, adds a new method of discovering the
host task size and finally adds four level page table support. All of
this means the userspace TASK_SIZE is much larger and in turns permits
userspace applications that need a lot of virtual addresses to work
From: Benjamin Berg
The calculation was wrong as it only subtracted one and then rounded
down for alignment. However, this is incorrect if host_task_size is not
already aligned.
This probably worked fine because on 64 bit the host_task_size is bigger
than returned by os_get_top_address.
Signed-
On Tue, Jun 11, 2024 at 07:19:10AM +0200, Christoph Hellwig wrote:
> blkfront always had a robust negotiation protocol for detecting a write
> cache. Stop simply disabling cache flushes when they fail as that is
> a grave error.
It's my understanding the current code attempts to cover up for the
22 matches
Mail list logo
