qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Segfault using qemu-system-arm in smc91c111


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] Segfault using qemu-system-arm in smc91c111
Date: Sat, 5 Sep 2015 13:30:04 -0700

On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell <address@hidden> wrote:
> On 4 September 2015 at 18:20, Richard Purdie
> <address@hidden> wrote:
>> On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
>>> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
>>> > On 4 September 2015 at 12:24, Richard Purdie
>>> > <address@hidden> wrote:
>>> > > So just based on that, yes, seems that the rx_fifo looks to be
>>> > > overrunning. I can add the asserts but I think it would just confirm
>>> > > this.
>>> >
>>> > Yes, the point of adding assertions is to confirm a hypothesis.
>>>
>>> I've now confirmed that it does indeed trigger the assert in
>>> smc91c111_receive().
>>
>> I just tried an experiment where I put:
>>
>>     if (s->rx_fifo_len >= NUM_PACKETS)
>>         return -1;
>>
>> into smc91c111_receive() and my reproducer stops reproducing the
>> problem.

Does it just stop the crash or does it eliminate the problem
completely with a fully now-working network?

>> I also noticed can_receive() could also have a check on buffer
>> availability. Would one of these changes be the correct fix here?
>
> The interesting question is why smc91c111_allocate_packet() doesn't
> fail in this situation. We only have NUM_PACKETS worth of storage,
> shared between the tx and rx buffers, so how could we both have
> already filled the rx_fifo and have a spare packet for the allocate
> function to return?

Maybe this:

            case 5: /* Release.  */
                smc91c111_release_packet(s, s->packet_num);
                break;

The guest is able to free an allocated packet without the accompanying
pop of tx/rx fifo. This may suggest some sort of guest error?

The fix depends on the behaviour of the real hardware. If that MMIO op
is supposed to dequeue the corresponding queue entry then we may need
to patch that logic to do search the queues and dequeue it. Otherwise
we need to find out the genuine length of the rx queue, and clamp it
without something like Richards patch. There are a few other bits and
pieces that suggest the guest can have independent control of the
queues and allocated buffers but i'm confused as to how the rx fifo
length can get up to 10 in any case.

Regards,
Peter

>
> -- PMM
>



reply via email to

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