netdev - Re: [PATCH 0/3] net: macb: DMA race condition fixes

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: <284d5c20-7acd-625f-cabc-b1ba0a7f3136@microchip.com>
Date:   Mon, 10 Dec 2018 11:32:04 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <Nicolas.Ferre@...rochip.com>, <anssi.hannula@...wise.fi>,
        <davem@...emloft.net>
CC:     <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/3] net: macb: DMA race condition fixes

On 10.12.2018 12:58, Nicolas Ferre - M43238 wrote:
> On 07/12/2018 at 13:04, Anssi Hannula wrote:
>> On 5.12.2018 22:35, David Miller wrote:
>>> From: Anssi Hannula <anssi.hannula@...wise.fi>
>>> Date: Fri, 30 Nov 2018 20:21:34 +0200
>>>
>>>> Here are a couple of race condition fixes for the macb driver. The first
>>>> two are issues observed on real HW.
>>> It looks like there is still an active discussion about the memory
>>> barriers in patch #3 being excessive.
>>>
>>> Once that is sorted out to everyone's satisfaction, would you
>>> please repost this series with appropriate ACKs, reviewed-by's,
>>> tested-by's, etc. added?
>>>
>>> Thank you.
>>
>>
>> OK, I'll do that once everything is sorted.
>>
>> Nicolas, were Claudiu's tests the ones you wanted to wait for or are we
>> waiting for more tests?
> 
> Claudiu will report on our tests. The discussion is still progress from 
> what I can tell. Thanks a lot for continuing in participating to this 
> thread!

As I said, I tested this series on heavy traffic load and in the setup we
observed the issue with TX used bit read interrupt (see patch "net: macb:
restart tx after tx used bit read" I submitted these days) on our SAMA5D2
Xplained and SAMA5D4 Xplained boards. With patches 1 & 2 from this series I
can say the "not whole frame pointed by descriptor" issue is not present
anymore.

The idea with tests was to see if this series has any impact on "tx used
bit read" issue we faced with. The result is no, the "net: macb: restart tx
after tx used bit read" patch is needed. I asked for postponing of this to
run more tests on my side (independent of this series with memory barriers).

Thank you,
Claudiu Beznea

> 
> Best regards,
>