From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [RFC] virtio_net: add local_bh_disable() around
 u64_stats_update_begin
Date: Tue, 16 Oct 2018 20:42:07 +0200
Message-ID: <20181016184206.coukhtgmlr32hyl7@linutronix.de>
References: <20181016165545.guksrl23ulcudxrk@linutronix.de>
 <20181016110114.73e2b248@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
        tglx@linutronix.de,
        Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Jason Wang <jasowang@redhat.com>,
        "David S. Miller" <davem@davemloft.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <netdev-owner@vger.kernel.org>
Received: from Galois.linutronix.de ([146.0.238.70]:58709 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727006AbeJQCd5 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 16 Oct 2018 22:33:57 -0400
Content-Disposition: inline
In-Reply-To: <20181016110114.73e2b248@xeon-e3>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 2018-10-16 11:01:14 [-0700], Stephen Hemminger wrote:
> On Tue, 16 Oct 2018 18:55:45 +0200
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > Also, ptr->var++ is not an atomic operation even on 64bit CPUs. Which
> > means if try_fill_recv() runs on CPU0 (via virtnet_receive()) then the
> > worker might run on CPU1.
> 
> On modern CPU's increment of native types is atomic but not locked.
> u64_stats_update_begin is a no-op on UP and also if BIT_PER_LONG != 32

On ARM64 you have load, inc, store. So if two CPUs increment the counter
simultaneously we might lose one increment. That is why I asked if we
care or not.

Sebastian