netdev - Re: Fwd: net: fec: rx descriptor ring out of order

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]

Date:   Fri, 13 Nov 2020 08:33:36 +0100
From:   Kegl Rohit <keglrohit@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Fwd: net: fec: rx descriptor ring out of order

> What are the addresses of the ring entries?
> I bet there is something wrong with the cache coherency and/or
> flushing.
>
> So the MAC hardware has done the write but (somewhere) it
> isn't visible to the cpu for ages.

CMA memory is disabled in our kernel config.
So the descriptors allocated with dma_alloc_coherent() won't be CMA memory.
Could this cause a different caching/flushing behaviour?

> I've seen a 'fec' ethernet block in a freescale DSP.
> IIRC it is a fairly simple block - won't be doing out-of-order writes.
>
> The imx6q seems to be arm based.
> I'm guessing that means it doesn't do cache coherency for ethernet dma
> accesses.
> That (more or less) means the rings need to be mapped uncached.
> Any attempt to just flush/invalidate the cache lines is doomed.
>
> ...

> > > I could only think of skipping/dropping the descriptor when the
> > > current is still busy but the next one is ready.
> > > But it is not easily possible because the "stuck" descriptor gets
> > > ready after a huge delay.
>
> I bet the descriptor is at the end of a cache line which finally
> gets re-read.
I stumbled across FEC ethernet issues [Was: PL310 errata workarounds]
https://www.spinics.net/lists/arm-kernel/thrd312.html#315574.
Changes to the PL310 cache driver (used in imx6q) were made, to also
fix fec issues.
This PL310 cleanup/fixes are not contained in the 3.10.108 kernel.
So maybe i have to look also there.