> +/* > + * The higher levels take care of making this non-reentrant (it's > + * called with bh's disabled). > + */ > +static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev) You have this comment, but then... > + dev->features = NETIF_F_FRAGLIST > + | NETIF_F_HIGHDMA > + | NETIF_F_LLTX; you set LLTX, which means that the upper layers _don't_ make sure that your xmit routine is not reentrant. It looks like the impact of multiple simultaneous xmit calls is just the possibility of screwing up the statistics, but still I think you want to drop the LLTX feature (since you have no lock of your own to try and take). _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
Roland Dreier <rdreier@cisco.com> writes: > > +/* > > + * The higher levels take care of making this non-reentrant (it's > > + * called with bh's disabled). > > + */ > > +static int etun_xmit(struct sk_buff *skb, struct net_device *tx_dev) > > You have this comment, but then... > > > + dev->features = NETIF_F_FRAGLIST > > + | NETIF_F_HIGHDMA > > + | NETIF_F_LLTX; > > you set LLTX, which means that the upper layers _don't_ make sure that > your xmit routine is not reentrant. > > It looks like the impact of multiple simultaneous xmit calls is just > the possibility of screwing up the statistics, but still I think you > want to drop the LLTX feature (since you have no lock of your own to > try and take). Yup. That is an inconsistency and probably a bug. I have to think through what makes most sense in this case. Though the cheap answer is clearly to remove NETIF_F_LLTX. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers