netdev - Re: [PATCH net-next 1/5] sfc: add and use efx_tx_send

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 3 Sep 2020 17:48:39 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     David Miller <davem@...emloft.net>
CC:     <linux-net-drivers@...arflare.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/5] sfc: add and use efx_tx_send_pending in tx.c

On 02/09/2020 23:55, David Miller wrote:
> From: Edward Cree <ecree@...arflare.com>
> Date: Wed, 2 Sep 2020 15:35:53 +0100
> 
>> +	tx_queue->xmit_more_available = true;
> 
> I don't understand why you're setting xmit_more_available
> unconditionally to true now instead of setting it to 'xmit_more' as
> seen by this transmit attempt.  Why would you want to signal
> that xmit_more handling might be necessary when you haven't been
> given an xmit_more tx request?

After this patch xmit_more_available is something of a misnomer and
 really means "xmit pending" (I'll rename it in v2).  We unconditionally
 set it to true here so that efx_tx_send_pending() knows there is
 something to do on this queue; but then we only call efx_tx_send_pending
 if !xmit_more (per the __netdev_tx_sent_queue() call).  Then
 efx_tx_send_pending, via the efx->type->tx_write methods, sets
 xmit_more_available to false.
Thus xmit_more_available is only true on return from __efx_enqueue_skb()
 if we had xmit_more (and __netdev_tx_sent_queue didn't say "ring it
 anyway").

> If this change is in fact correct, it's something you need to explain
> in the commit message.
Will do so for v2, as it is indeed far from obvious.

-ed