qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] linux-user: do setrlimit selectively


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] linux-user: do setrlimit selectively
Date: Mon, 17 Sep 2018 18:02:12 +0100

On 5 September 2018 at 17:18, Max Filippov <address@hidden> wrote:
> setrlimit guest calls that affect memory resources
> (RLIMIT_{AS,DATA,STACK}) may interfere with QEMU internal memory
> management. They may result in QEMU lockup because mprotect call in
> page_unprotect would fail with ENOMEM error code, causing infinite loop
> of SIGSEGV. E.g. it happens when running libstdc++ testsuite for xtensa
> target on x86_64 host.
>
> Don't call host setrlimit for memory-related resources.
>
> Signed-off-by: Max Filippov <address@hidden>
> ---
> Changes v1->v2:
> - don't limit change to 32-bit guest on 64-bit host case
>
>  linux-user/syscall.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index bb42a225eb58..a9cace49dad8 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -9275,7 +9275,13 @@ abi_long do_syscall(void *cpu_env, int num, abi_long 
> arg1,
>              rlim.rlim_cur = target_to_host_rlim(target_rlim->rlim_cur);
>              rlim.rlim_max = target_to_host_rlim(target_rlim->rlim_max);
>              unlock_user_struct(target_rlim, arg2, 0);
> -            ret = get_errno(setrlimit(resource, &rlim));
> +            if (resource != RLIMIT_AS &&
> +                resource != RLIMIT_DATA &&
> +                resource != RLIMIT_STACK) {
> +                return get_errno(setrlimit(resource, &rlim));
> +            } else {
> +                return 0;
> +            }
>          }

Can we have a comment here explaining why we don't enforce these limits?
Something like
    /*
     * If we just passed through resource limit settings for memory then
     * they would also apply to QEMU's own allocations, and QEMU will
     * crash or hang or die if its allocations fail. Ideally we would
     * track the guest allocations in QEMU and apply the limits ourselves.
     * For now, just tell the guest the call succeeded but don't actually
     * limit anything.
     */

Otherwise
Reviewed-by: Peter Maydell <address@hidden>

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]