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

[Max Filippov]

On Tue, Sep 4, 2018 at 3:55 PM, Peter Maydell <address@hidden> wrote:
> On 4 September 2018 at 23:26, Max Filippov <address@hidden> wrote:
>> On Tue, Sep 4, 2018 at 3:10 PM, Peter Maydell <address@hidden> wrote:
>>> On 4 September 2018 at 23:02, Max Filippov <address@hidden> wrote:
>
>>> You could make a case for always ignoring setrlimit calls: if we
>>> ever hit the limit it's as likely to be by failing a QEMU internal
>>> allocation as a guest one, so not to imposing the limit at all
>>> would avoid QEMU failing then. But that would apply in both the
>>> 32-on-64 and also 32-on-32 and 64-on-64 cases too.
>>
>> That's what I did initially, but it feels somewhat unsafe in 64-on-64 case.
>> My expectation is that limits set by 64-bit guest should be somewhat
>> suitable for the 64-bit host, is it wrong?
>
> It doesn't matter what the limit the guest sets is -- the
> problem is that if we hit it then chances are good it'll cause
> a QEMU allocation to fail and then we'll deadlock. The limit
> might be entirely reasonable for the guest program (which
> presumably has a plan for handling the failure) but QEMU
> itself can't cope with hitting the limit.

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

-- 
Thanks.
-- Max