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
| ||
|
Date: Sun, 28 Apr 2013 12:31:56 +0800 From: Frank Li <lznuaa@...il.com> To: Francois Romieu <romieu@...zoreil.com> Cc: Robert Schwebel <r.schwebel@...gutronix.de>, David Miller <davem@...emloft.net>, Lucas Stach <l.stach@...gutronix.de>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Frank.Li@...escale.com" <Frank.Li@...escale.com>, Fabio Estevam <festevam@...il.com>, Shawn Guo <shawn.guo@...aro.org> Subject: Re: [PATCH resend 1/3] Revert "net: fec: fix missing napi_disable call" 2013/4/28 Frank Li <lznuaa@...il.com>: > 2013/4/28 Francois Romieu <romieu@...zoreil.com>: >> Frank Li <lznuaa@...il.com> : >>> 2013/4/27, Francois Romieu <romieu@...zoreil.com>: >> [...] >>> > napi_disable may sleep. >>> > >>> > fec_restart can be called with spinlock held in fec_enet_adjust_link >>> >>> You are right. Spin lock in FEC enet adjust link can be removed when >>> remove spinlock in tx and RX. >> >> fec_restart is also called from the netdev watchdog handler (fec_timeout) >> and tasklet can't sleep either. You should imho schedule_work from >> fec_timeout. > > I will add delay_work to fix this issue. > >> >> How is the driver supposed to avoid the napi context >> fec_enet_tx:netif_queue_stopped vs fec_enet_start_xmit:netif_stop_queue >> race since both can run on different cpu without any read/write ordering >> enforcement between one thread netif_* and its peer {dirty/cur}_tx ? > > This is lockless design if only one read and one write. It likes kfifo. > > Assume CPU1 run xmit. CPU2 run napi fec_enet_tx > > (1) if (fep->cur_tx == fep->dirty_tx) > (2) netif_stop_queue(ndev); > > if CPU2 update fep->dirty_tx before CPU1 run (1). the condition is false. > if CPU2 update fep->dirty_tx after (1) before (2), netif_stop_queue > will be called. There are not problem at this time even though queue > is not full here. queue is not empty for sure here. fec_enet_tx will > be called again when NAPI trigger by one frame finished transfer, > fec_enet_tx will wake up send queue. > > Most worse case is waste one BD script. I just send out a patch to try to fix your problem. Can you help test it in your sit? > >> >> -- >> Ueimor -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists