Commit 5dfa88f7 authored by Max Filippov's avatar Max Filippov Committed by Laurent Vivier
Browse files

linux-user: do setrlimit selectively 



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.

Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
Message-Id: <20180917181314.22551-1-jcmvbkbc@gmail.com>
[lv: rebase on master]
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
parent 58cfa6c2

linux-user/syscall.c

+15 −1
Original line number Diff line number Diff line
@@ -7879,7 +7879,21 @@ static abi_long do_syscall1(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);

            /*

             * 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.

             */

            if (resource != RLIMIT_AS &&

                resource != RLIMIT_DATA &&

                resource != RLIMIT_STACK) {

                return get_errno(setrlimit(resource, &rlim));

            } else {

                return 0;

            }

        }

#endif

#ifdef TARGET_NR_getrlimit