Stephen Hemminger wrote: > On Mon, 12 Apr 2010 12:38:57 +0200 > Eric Dumazet <[email protected]> wrote: > >> Le lundi 12 avril 2010 à 18:37 +0800, Cong Wang a écrit : >>> Stephen Hemminger wrote: >>>> There is no protection on dev->priv_flags for SMP access. >>>> It would better bit value in dev->state if you are using it as control >>>> flag. >>>> >>>> Then you could use >>>> if (unlikely(test_and_clear_bit(__IN_NETPOLL, >>>> &skb->dev->state))) >>>> netpoll_send_skb(...) >>>> >>>> >>> Hmm, I think we can't use ->state here, it is not for this kind of purpose, >>> according to its comments. >>> >>> Also, I find other usages of IFF_XXX flags of ->priv_flags are also using >>> &, | to set or clear the flags. So there must be some other things >>> preventing >>> the race... >> Yes, its RTNL that protects priv_flags changes, hopefully... >> > > The patch was not protecting priv_flags with RTNL. > For example.. > > > @@ -308,7 +312,9 @@ static void netpoll_send_skb(struct netp > tries > 0; --tries) { > if (__netif_tx_trylock(txq)) { > if (!netif_tx_queue_stopped(txq)) { > + dev->priv_flags |= IFF_IN_NETPOLL; > status = ops->ndo_start_xmit(skb, dev); > + dev->priv_flags &= ~IFF_IN_NETPOLL; > if (status == NETDEV_TX_OK) > txq_trans_update(txq);
Hmm, but I checked the bonding case (IFF_BONDING), it doesn't hold rtnl_lock. Strange. _______________________________________________ Bridge mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/bridge
