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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 11 Sep 2020 13:26:19 -0700
From:   Jakub Kicinski <>
To:     Edward Cree <>
Cc:     <>, <>,
Subject: Re: [PATCH net-next 1/7] sfc: decouple TXQ type from label

On Fri, 11 Sep 2020 18:36:04 +0100 Edward Cree wrote:
> >> +		/* We don't have a TXQ of the right type.
> >> +		 * This should never happen, as we don't advertise offload
> >> +		 * features unless we can support them.
> >> +		 */
> >> +		return NETDEV_TX_BUSY;  
> > You should probably drop this packet, right? Next time qdisc calls the
> > driver it's unlikely to find a queue it needs.  
> Hmm, the comment at the top of efx_hard_start_xmit() claims that
>  "returning anything other than NETDEV_TX_OK will cause the OS to free
>  the skb".  Is that not in fact true?

Old drivers routinely return TX_BUSY when their queue fills up,
so the skb is put back in the qdisc to wait for the driver to restart
its queues.

> Should I instead do what the error path of __efx_enqueue_skb() does -
>  free the skb, kick pending TX, and return NETDEV_TX_OK?  I have to
>  admit I've never 100% understood the netdev_tx_t semantics.

Yeah, I'm not sure what all of them do either. But in modern drivers
which stop their queues before they fill up really the only return
value which makes sense is NETDEV_TX_OK - either after successful
submission to HW, or error and freeing the skb.

Powered by blists - more mailing lists