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

[Peter Maydell]

On 5 September 2018 at 01:08, Max Filippov <address@hidden> wrote:
> Ok, the deadlock (and other weird behavior) is a separate problem:
> QEMU doesn't check results of resource allocation functions and
> then gets surprised. Errors must be handled and QEMU must be
> terminated properly.
>
> As to hitting the limit, I don't see anything wrong with it as long as
> the limits are relevant.

The limit is relevant *to the guest process*. It's not relevant
to QEMU's own allocations. If you're running directly under
the host kernel and you set a memory rlimit, it doesn't mean
that the kernel suddenly starts failing its own internal
allocations.

It would obviously be better if we fixed the problems of
allocations failing causing non-obvious problems (if nothing
else it would make debugging of things which triggered QEMU
asserts easier). But the guest should not be able to cause
QEMU's internal allocations to fail by setting the rlimit.

> What I've seen so far is application calling
> setrlimit to catch its own bugs and limit bug impact on the rest of
> the system. 64-on-64 would probably set up a relevant limit,
> 32-on-64 -- unlikely.

>> https://bugs.launchpad.net/qemu/+bug/1163034 is the bug I
>> mentioned in my earlier email, by the way.
>
> It looks like the proposed patch would fix the issue if it were
> 32-on-64 case without making it worse for the 64-on-64 case?

I still think 32-on-64 is a red herring here. If ignoring
client attempts to set the memory rlimits makes sense on
32-on-64 it makes sense for all configurations.

thanks
-- PMM