mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Menzel <pmenzel@molgen.mpg.de>
To: David Yang <mmyangfl@gmail.com>
Cc: netdev@vger.kernel.org, Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Pavan Kumar Linga <pavan.kumar.linga@intel.com>,
	Phani Burra <phani.r.burra@intel.com>,
	Willem de Bruijn <willemb@google.com>,
	Alan Brady <alan.brady@intel.com>,
	Sridhar Samudrala <sridhar.samudrala@intel.com>,
	Joshua Hay <joshua.a.hay@intel.com>,
	intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH net] idpf: Fix data race in idpf_net_dim
Date: Tue, 20 Jan 2026 17:54:21 +0100	[thread overview]
Message-ID: <56bbd1d8-4ea7-41b9-beac-2e496bf81206@molgen.mpg.de> (raw)
In-Reply-To: <8cfba7ca-03d0-46fe-92fa-5d4a119fc31e@molgen.mpg.de>

[Cc: Remove bouncing alan.brady@intel.com and pavan.kumar.linga@intel.com]

Am 20.01.26 um 17:50 schrieb Paul Menzel:
> Dear David,
> 
> 
> Thank you for your patch.
> 
> Am 19.01.26 um 17:27 schrieb David Yang:
>> In idpf_net_dim(), some statistics protected by u64_stats_sync, are read
>> and accumulated in ignorance of possible u64_stats_fetch_retry() events.
>> The correct way to copy statistics is already illustrated by
>> idpf_add_queue_stats(). Fix this by reading them into temporary variables
>> first.
> 
> It’d be great if you also documented a test case.
> 
>> Fixes: c2d548cad150 ("idpf: add TX splitq napi poll support")
>> Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support")
>> Signed-off-by: David Yang <mmyangfl@gmail.com>
>> ---
>>   drivers/net/ethernet/intel/idpf/idpf_txrx.c | 16 +++++++++++-----
>>   1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>> index 97a5fe766b6b..66ba645e8b90 100644
>> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
>> @@ -3956,7 +3956,7 @@ static void idpf_update_dim_sample(struct idpf_q_vector *q_vector,
>>   static void idpf_net_dim(struct idpf_q_vector *q_vector)
>>   {
>>       struct dim_sample dim_sample = { };
>> -    u64 packets, bytes;
>> +    u64 packets, bytes, pkts, bts;
> 
> The new variable names are ambiguous. Would _tmp or so be better?
> 
>>       u32 i;
>>       if (!IDPF_ITR_IS_DYNAMIC(q_vector->tx_intr_mode))
>> @@ -3968,9 +3968,12 @@ static void idpf_net_dim(struct idpf_q_vector *q_vector)
>>           do {
>>               start = u64_stats_fetch_begin(&txq->stats_sync);
>> -            packets += u64_stats_read(&txq->q_stats.packets);
>> -            bytes += u64_stats_read(&txq->q_stats.bytes);
>> +            pkts = u64_stats_read(&txq->q_stats.packets);
>> +            bts = u64_stats_read(&txq->q_stats.bytes);
>>           } while (u64_stats_fetch_retry(&txq->stats_sync, start));
>> +
>> +        packets += pkts;
>> +        bytes += bts;
>>       }
>>       idpf_update_dim_sample(q_vector, &dim_sample, &q_vector->tx_dim,
>> @@ -3987,9 +3990,12 @@ static void idpf_net_dim(struct idpf_q_vector *q_vector)
>>           do {
>>               start = u64_stats_fetch_begin(&rxq->stats_sync);
>> -            packets += u64_stats_read(&rxq->q_stats.packets);
>> -            bytes += u64_stats_read(&rxq->q_stats.bytes);
>> +            pkts = u64_stats_read(&rxq->q_stats.packets);
>> +            bts = u64_stats_read(&rxq->q_stats.bytes);
>>           } while (u64_stats_fetch_retry(&rxq->stats_sync, start));
>> +
>> +        packets += pkts;
>> +        bytes += bts;
>>       }
>>       idpf_update_dim_sample(q_vector, &dim_sample, &q_vector->rx_dim,
> 
> 
> Kind regards,
> 
> Paul

  reply	other threads:[~2026-01-20 16:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-19 16:27 David Yang
2026-01-19 17:59 ` Eric Dumazet
2026-01-19 18:07   ` Yangfl
2026-01-20 16:50 ` [Intel-wired-lan] " Paul Menzel
2026-01-20 16:54   ` Paul Menzel [this message]
2026-01-20 19:09   ` Yangfl
2026-01-21  2:40 ` patchwork-bot+netdevbpf
2026-01-22 11:26 ` [Intel-wired-lan] " Loktionov, Aleksandr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56bbd1d8-4ea7-41b9-beac-2e496bf81206@molgen.mpg.de \
    --to=pmenzel@molgen.mpg.de \
    --cc=alan.brady@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=joshua.a.hay@intel.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmyangfl@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.kumar.linga@intel.com \
    --cc=phani.r.burra@intel.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sridhar.samudrala@intel.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®