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  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

Powered by blists - more mailing lists