Thread (8 messages) flat view 8 messages, 3 authors, 2018-01-20

Re: net: r8169: a question of memory barrier in the r8169 driver

From: Jia-Ju Bai <hidden>
Date: 2018-01-19 01:25:23
Also in: lkml

On 2018/1/19 9:11, Francois Romieu wrote:
Jia-Ju Bai [off-list ref] :
[...]
quoted
The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
     if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
         netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
         goto err_stop_0;
     }
But there is no memory barrier around this code.

Is there a possible data race here?
This code would not even be needed if rtl8169_start_xmit was only your
usual ndo_start_xmit handler: Realtek {ab / re}used it for GSO handling
(see r8169_csum_workaround).

If the test is not a no-op in this GSO context, it's racy.
Thanks for reply.
I didn't clearly understand your meaning...
I wonder whether there is a possible data race and whether a "smp_mb" is 
needed before this code?
By the way, do you mean that this code can be removed?


Thanks,
Jia-Ju Bai
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help