netdev - Re: [PATCH] Revert "macb: support the two tx descriptors on at91rm9200"

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20201210.133301.321052044098459280.davem@davemloft.net>
Date:   Thu, 10 Dec 2020 13:33:01 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     w@....eu
Cc:     kuba@...nel.org, netdev@...r.kernel.org,
        nicolas.ferre@...rochip.com, claudiu.beznea@...rochip.com,
        daniel@...f.com, alexandre.belloni@...tlin.com
Subject: Re: [PATCH] Revert "macb: support the two tx descriptors on
 at91rm9200"

From: Willy Tarreau <w@....eu>
Date: Wed,  9 Dec 2020 19:47:40 +0100

> This reverts commit 0a4e9ce17ba77847e5a9f87eed3c0ba46e3f82eb.
> 
> The code was developed and tested on an MSC313E SoC, which seems to be
> half-way between the AT91RM9200 and the AT91SAM9260 in that it supports
> both the 2-descriptors mode and a Tx ring.
> 
> It turns out that after the code was merged I could notice that the
> controller would sometimes lock up, and only when dealing with sustained
> bidirectional transfers, in which case it would report a Tx overrun
> condition right after having reported being ready, and will stop sending
> even after the status is cleared (a down/up cycle fixes it though).
> 
> After adding lots of traces I couldn't spot a sequence pattern allowing
> to predict that this situation would happen. The chip comes with no
> documentation and other bits are often reported with no conclusive
> pattern either.
> 
> It is possible that my change is wrong just like it is possible that
> the controller on the chip is bogus or at least unpredictable based on
> existing docs from other chips. I do not have an RM9200 at hand to test
> at the moment and a few tests run on a more recent 9G20 indicate that
> this code path cannot be used there to test the code on a 3rd platform.
> 
> Since the MSC313E works fine in the single-descriptor mode, and that
> people using the old RM9200 very likely favor stability over performance,
> better revert this patch until we can test it on the original platform
> this part of the driver was written for. Note that the reverted patch
> was actually tested on MSC313E.
> 
> Cc: Nicolas Ferre <nicolas.ferre@...rochip.com>
> Cc: Claudiu Beznea <claudiu.beznea@...rochip.com>
> Cc: Daniel Palmer <daniel@...f.com>
> Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>
> Link: https://lore.kernel.org/netdev/20201206092041.GA10646@1wt.eu/
> Signed-off-by: Willy Tarreau <w@....eu>

Applied, thanks.