[PATCH v2 0/5] linux-user: Rewrite target_shmat

Richard Henderson posted 5 patches 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20240228202518.33180-1-richard.henderson@linaro.org
Maintainers: Laurent Vivier <laurent@vivier.eu>, "Alex Bennée" <alex.bennee@linaro.org>
linux-user/loongarch64/target_syscall.h      |   7 -
linux-user/mmap.c                            | 172 +++++++++++++++----
linux-user/strace.c                          |  23 +++
linux-user/syscall.c                         |  16 ++
tests/tcg/multiarch/linux/linux-shmat-maps.c |  55 ++++++
linux-user/strace.list                       |   2 +-
6 files changed, 231 insertions(+), 44 deletions(-)
create mode 100644 tests/tcg/multiarch/linux/linux-shmat-maps.c
[PATCH v2 0/5] linux-user: Rewrite target_shmat
Posted by Richard Henderson 9 months ago
There are multiple issues with the implementation of shmat().

(1) With reserved_va, which is the default for 32-on-64-bit, we mmap the
    entire guest address space.  Unlike mmap, shmat refuses to replace an
    existing mapping without setting SHM_REMAP.  This is the original
    subject of issue #115, though it quicky gets distracted by
    something else.

(2) With target page size > host page size, and a shm area
    that is not a multiple of the target page size, we leave
    an unmapped hole that the target expects to be mapped.
    This is the subject of 

	https://lore.kernel.org/qemu-devel/2no4imvz2zrar5kchz2l3oddqbgpj77jgwcuf7aritkn2ok763@i2mvpcihztho/

    wherein qemu itself expects a mapping to exist, and
    dies in open_self_maps_2.

So: reimplement the thing.

Changes for v2:
  - Include Ilya's test case, which caught extra errors: Yay!
  - Include x86_64 /proc/self/maps fix, which the test triggers.
  - Dropped r-b for the shmat rewrite due to number of changes.


r~


Based-on: <20240222204323.268539-1-richard.henderson@linaro.org>
("[PULL 00/39] tcg and linux-user patch queue")
(Which is technically now out of date, waiting on the coredump
rewrite to solve -Wvla werrors.)




Ilya Leoshkevich (1):
  tests/tcg: Check that shmat() does not break /proc/self/maps

Richard Henderson (4):
  linux-user/x86_64: Handle the vsyscall page in open_self_maps_{2,4}
  linux-user/loongarch64: Remove TARGET_FORCE_SHMLBA
  linux-user: Add strace for shmat
  linux-user: Rewrite target_shmat

 linux-user/loongarch64/target_syscall.h      |   7 -
 linux-user/mmap.c                            | 172 +++++++++++++++----
 linux-user/strace.c                          |  23 +++
 linux-user/syscall.c                         |  16 ++
 tests/tcg/multiarch/linux/linux-shmat-maps.c |  55 ++++++
 linux-user/strace.list                       |   2 +-
 6 files changed, 231 insertions(+), 44 deletions(-)
 create mode 100644 tests/tcg/multiarch/linux/linux-shmat-maps.c

-- 
2.34.1
Re: [PATCH v2 0/5] linux-user: Rewrite target_shmat
Posted by Richard Purdie 9 months ago
On Wed, 2024-02-28 at 10:25 -1000, Richard Henderson wrote:
> There are multiple issues with the implementation of shmat().
> 
> (1) With reserved_va, which is the default for 32-on-64-bit, we mmap
> the
>     entire guest address space.  Unlike mmap, shmat refuses to
> replace an
>     existing mapping without setting SHM_REMAP.  This is the original
>     subject of issue #115, though it quicky gets distracted by
>     something else.
> 
> (2) With target page size > host page size, and a shm area
>     that is not a multiple of the target page size, we leave
>     an unmapped hole that the target expects to be mapped.
>     This is the subject of 
> 
> 	
> https://lore.kernel.org/qemu-devel/2no4imvz2zrar5kchz2l3oddqbgpj77jg
> wcuf7aritkn2ok763@i2mvpcihztho/
> 
>     wherein qemu itself expects a mapping to exist, and
>     dies in open_self_maps_2.
> 
> So: reimplement the thing.
> 
> Changes for v2:
>   - Include Ilya's test case, which caught extra errors: Yay!
>   - Include x86_64 /proc/self/maps fix, which the test triggers.
>   - Dropped r-b for the shmat rewrite due to number of changes.

I tested these against our problem with webkitgkt and an happy to
report it does solve the segfault we were seeing, thanks!

Cheers,

Richard