All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH net] net: Use this_cpu_inc() to increment net->core_stats
Date: Thu, 21 Apr 2022 18:51:31 +0200	[thread overview]
Message-ID: <YmGLkz+dIBb5JjFF@linutronix.de> (raw)
In-Reply-To: <CANn89iKjSmnTSzzHdnP-HEYMajrz+MOrjFooaMFop4Vo43kLdg@mail.gmail.com>

On 2022-04-21 09:06:05 [-0700], Eric Dumazet wrote:
> On Thu, Apr 21, 2022 at 7:00 AM Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
> >
> 
> >                 for_each_possible_cpu(i) {
> >                         core_stats = per_cpu_ptr(p, i);
> > -                       storage->rx_dropped += local_read(&core_stats->rx_dropped);
> > -                       storage->tx_dropped += local_read(&core_stats->tx_dropped);
> > -                       storage->rx_nohandler += local_read(&core_stats->rx_nohandler);
> > +                       storage->rx_dropped += core_stats->rx_dropped;
> > +                       storage->tx_dropped += core_stats->tx_dropped;
> > +                       storage->rx_nohandler += core_stats->rx_nohandler;
> 
> I think that one of the reasons for me to use  local_read() was that
> it provided what was needed to avoid future syzbot reports.

syzbot report due a plain read of a per-CPU variable which might be
modified?

> Perhaps use READ_ONCE() here ?
> 
> Yes, we have many similar folding loops that are  simply assuming
> compiler won't do stupid things.

I wasn't sure about that and added PeterZ to do some yelling here just
in case. And yes, we have other sites doing exactly that. In
   Documentation/core-api/this_cpu_ops.rst
there is nothing about remote-READ-access (only that there should be no
writes (due to parallel this_cpu_inc() on the local CPU)). I know that a
32bit write can be optimized in two 16bit writes in certain cases but a
read is a read.
PeterZ? :)

Sebastian

  reply	other threads:[~2022-04-21 16:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 14:00 [PATCH net] net: Use this_cpu_inc() to increment net->core_stats Sebastian Andrzej Siewior
2022-04-21 15:32 ` Eric Dumazet
2022-04-21 15:48   ` Sebastian Andrzej Siewior
2022-04-21 16:06 ` Eric Dumazet
2022-04-21 16:51   ` Sebastian Andrzej Siewior [this message]
2022-04-21 17:11     ` Eric Dumazet
2022-04-23  9:24     ` Peter Zijlstra
2022-04-23 13:45       ` Eric Dumazet
2022-04-24  8:33       ` Sebastian Andrzej Siewior
2022-04-22 19:56 ` Jakub Kicinski

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=YmGLkz+dIBb5JjFF@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.