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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Mar 2022 08:43:24 -0700 From: Jakub Kicinski <kuba@...nel.org> To: Tomas Melin <tomas.melin@...sala.com>, Robert Hancock <robert.hancock@...ian.com> Cc: claudiu.beznea@...rochip.com, Nicolas.Ferre@...rochip.com, davem@...emloft.net, netdev@...r.kernel.org Subject: Re: [PATCH v3] net: macb: restart tx after tx used bit read On Wed, 23 Mar 2022 10:08:20 +0200 Tomas Melin wrote: > > From: <Claudiu.Beznea@...rochip.com> > > To: <Nicolas.Ferre@...rochip.com>, <davem@...emloft.net> > > Cc: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, > > <Claudiu.Beznea@...rochip.com> > > Subject: [PATCH v3] net: macb: restart tx after tx used bit read > > Date: Mon, 17 Dec 2018 10:02:42 +0000 [thread overview] > > Message-ID: <1545040937-6583-1-git-send-email-claudiu.beznea@...rochip.com> (raw) > > > > From: Claudiu Beznea <claudiu.beznea@...rochip.com> > > > > On some platforms (currently detected only on SAMA5D4) TX might stuck > > even the pachets are still present in DMA memories and TX start was > > issued for them. This happens due to race condition between MACB driver > > updating next TX buffer descriptor to be used and IP reading the same > > descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted. > > GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt > > is asserted TX must be restarted. Restart TX if used bit is read and > > packets are present in software TX queue. Packets are removed from software > > TX queue if TX was successful for them (see macb_tx_interrupt()). > > > > Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com> > > On Xilinx Zynq the above change can cause infinite interrupt loop leading > to CPU stall. Seems timing/load needs to be appropriate for this to happen, and currently > with 1G ethernet this can be triggered normally within minutes when running stress tests > on the network interface. > > The events leading up to the interrupt looping are similar as the issue described in the > commit message. However in our case, restarting TX does not help at all. Instead > the controller is stuck on the queue end descriptor generating endless TX_USED > interrupts, never breaking out of interrupt routine. > > Any chance you remember more details about in which situation restarting TX helped for > your use case? was tx_qbar at the end of frame or stopped in middle of frame? Which kernel version are you using? Robert has been working on macb + Zynq recently, adding him to CC.
Powered by blists - more mailing lists