netdev - Re: [PATCH net-next 1/7] sfc: decouple TXQ type from label

lists.openwall.net		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 linux-cve-announce 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 <kuba@...nel.org>
To:     Edward Cree <ecree@...arflare.com>
Cc:     <linux-net-drivers@...arflare.com>, <davem@...emloft.net>,
        <netdev@...r.kernel.org>
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.