Le lundi 20 juin 2011 à 19:19 +0200, Eric Dumazet a écrit : > Le lundi 20 juin 2011 à 18:33 +0200, Lennert Buytenhek a écrit : > > On Mon, Jun 20, 2011 at 09:48:07AM +0200, Richard Cochran wrote: > > > > > Because the socket buffer is freed in the completion interrupt, it > > > is not safe to access it after submitting it to the hardware. > > > > Maybe I'm missing something here, but mv643xx_eth TX reclaim is done > > from NAPI poll, under __netif_tx_lock(), while mv643xx_eth_xmit() also > > runs under __netif_tx_lock(). > > See my previous answer. Its true this driver _currently_ holds tx queue > lock in its TX completion. But that might/should change. > > Goal is to make tx completion not use tx queue lock in fast path, like > its done in tg3, bnx2, bnx2x ... and other recent drivers. > > Its obviously correct to move skb->len access in start_xmit() before > starting the IO, even if not a bug fix, it makes all drivers behave the > same : When reviewing them, its easier not to worry about these possible > use after free. > >
One random example found in drivers/staging/hv/netvsc_drv.c Is the "net->stats.tx_bytes += skb->len;" found in line 188 is correct ? Who knows ? I believe its not correct ;) _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
