netdev - Re: [PATCH v2 4/4] bgmac: fix DMA rx corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACna6rzJ0dDhbF_-=Jwkni=0d+PzrMBpfJQfkKAPkWX7Eg7eFA@mail.gmail.com>
Date:	Sun, 12 Apr 2015 22:29:46 +0200
From:	Rafał Miłecki <zajec5@...il.com>
To:	Felix Fietkau <nbd@...nwrt.org>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Network Development <netdev@...r.kernel.org>,
	Hauke Mehrtens <hauke@...ke-m.de>
Subject: Re: [PATCH v2 4/4] bgmac: fix DMA rx corruption

On 12 April 2015 at 21:25, Felix Fietkau <nbd@...nwrt.org> wrote:
> On 2015-04-12 21:04, Eric Dumazet wrote:
>> On Sun, 2015-04-12 at 20:46 +0200, Felix Fietkau wrote:
>>> On 2015-04-12 20:09, Eric Dumazet wrote:
>>
>>> >
>>> > Given the fact that previous driver kind of worked, have you tried not
>>> > doing the modulo at all here ?
>>> The previous driver was causing reproducible DMA corruption issues under
>>> load. My patch fixes this, and I've verified this with hours of stress
>>> testing (previously I could reproduce the issue in minutes).
>>>
>>> > ring->end = desc_idx + 1;
>>> >
>>> > It looks like the hardware accepted setting BGMAC_DMA_RX_INDEX to
>>> > ring->index_base + ring->num_slots * sizeof(struct bgmac_dma_desc)
>>> The hardware accepts it, but with that value, it considers all rx slot
>>> entries filled, there's no CPU ownership bit in the descriptor.
>>> According to documentation, that register indicates the first *invalid*
>>> rx descriptor (i.e. one where the CPU hasn't posted a valid buffer yet).
>>>
>>> > So apparently the presence of BGMAC_DESC_CTL0_EOT in last rx desc was
>>> > enough to avoid any problem with this.
>>> EOT serves a completely different purpose. It simply indicates the end
>>> of the ring, telling the hardware to go back to the beginning for the
>>> next descriptor.
>>
>> Right, but after your patch, we program the hardware with end == start
>> == 0
>>
>> So I do not really understand how the hardware can still deliver first
>> frame.
>>
>> If it was really taking care of 'end' value, then it should not even
>> deliver one frame.
> Good point.
>
>> The dma corruption happened because hardware was simply reusing frames,
>> that driver already took to upper stack, since as you said, there is no
>> ownership bit.
>>
>> You might try your patch with BGMAC_RX_RING_SLOTS = 3 and check if it is
>> still working properly.
>>
>> I find BGMAC_RX_RING_SLOTS==511 very suspect, and a comment of why this
>> magic value is not 512 would be nice.
> I think it's probably a valid idea that was implemented in the wrong
> way. I'm pretty sure the idea was to only fill 511 descriptors in a ring
> with a size of 512. That would eliminate the issue you mentioned above.
> I'll send v3 with an extra patch to take care of this.

I don't recall differences between Broadcom's code and bgmac now.
However it could be that Broadcom used BGMAC_RX_RING_SLOTS==511 for
the same/similar purpose I did following:
/* Always keep one slot free to allow detecting bugged calls. */
if (--free_slots == 1)
        netif_stop_queue(net_dev);

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html