netdev - RE: [EXT] 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:   Sun, 15 Nov 2020 07:48:40 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Kegl Rohit <keglrohit@...il.com>
CC:     David Laight <David.Laight@...lab.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [EXT] Re: Fwd: net: fec: rx descriptor ring out of order

From: Kegl Rohit <keglrohit@...il.com> Sent: Sunday, November 15, 2020 1:37 AM
> On Sat, Nov 14, 2020 at 2:58 AM Andy Duan <fugang.duan@....com> wrote:
> >
> > From: Kegl Rohit <keglrohit@...il.com> Sent: Friday, November 13, 2020
> > 8:21 PM
> > > On Fri, Nov 13, 2020 at 8:33 AM Kegl Rohit <keglrohit@...il.com> wrote:
> > > >
> > > > > 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?
> > >
> > > Yes, after tests I think it is caused by the disabled CMA.
> > >
> > > @Andy
> > > I could find this mail and the attached "i.MX6 dma memory bufferable
> > > issue.pptx" in the archive
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > rc.info
> > > %2F%3Fl%3Dlinux-netdev%26m%3D140135147823760&amp;data=04%7C
> 01
> > > %7Cfugang.duan%40nxp.com%7C121e73ec66684a125e2a08d887cea578%
> 7C
> > >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637408668924362983
> > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJ
> > >
> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=e7Cm24Ay1Ay52UKtzT
> > > BiX9KlhuublndP30vnwxAaugM%3D&amp;reserved=0
> > > Was this issue solved in some kernel versions later on?
> > > Is CMA still necessary with a 5.4 Kernel?
> >
> > Yes, CMA is required. Otherwise it requires one patch for L2 cache.
> 
> Where can I find the patch / is the patch already mainline?
No, the patch is not in mainline. CMA can fix the issue.

The original patch is: set shared override bit in PL310 AUX_CTRL register

> Is it some development patch or already well tested?
> Or would you recommend enabling CMA instead?
> Are other components affected apart from the already mentioned peripherals
> (ENET, Audio, USB) in the attachment?
Yes,  recommend CMA that can fix the cache issue for all components.