Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 28 Mar 2020 19:21:48 +0100
From:   Andrea Parri <parri.andrea@gmail.com>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>
Cc:     linux-kernel@vger.kernel.org,
        "K . Y . Srinivasan" <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>, linux-hyperv@vger.kernel.org,
        Michael Kelley <mikelley@microsoft.com>,
        Dexuan Cui <decui@microsoft.com>,
        Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [RFC PATCH 03/11] Drivers: hv: vmbus: Replace the per-CPU
 channel lists with a global array of channels
Message-ID: <20200328182148.GA11210@andrea>
References: <20200325225505.23998-1-parri.andrea@gmail.com>
 <20200325225505.23998-4-parri.andrea@gmail.com>
 <87y2rn4287.fsf@vitty.brq.redhat.com>
 <20200326170518.GA14314@andrea>
 <87pncz3tcn.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87pncz3tcn.fsf@vitty.brq.redhat.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> Correct me if I'm wrong, but currently vmbus_chan_sched() accesses
> per-cpu list of channels on the same CPU so we don't need a spinlock to
> guarantee that during an interrupt we'll be able to see the update if it
> happened before the interrupt (in chronological order). With a global
> list of relids, who guarantees that an interrupt handler on another CPU
> will actually see the modified list? 

Thanks for pointing this out!

The offer/resume path presents implicit full memory barriers, program
-order after the array store which should guarantee the visibility of
the store to *all* CPUs before the offer/resume can complete (c.f.,

  tools/memory-model/Documentation/explanation.txt, Sect. #13

and assuming that the offer/resume for a channel must complete before
the corresponding handler, which seems to be the case considered that
some essential channel fields are initialized only later...)

IIUC, the spin lock approach you suggested will work and be "simpler";
an obvious side effect would be, well, a global synchronization point
in vmbus_chan_sched()...

Thoughts?

Thanks,
  Andrea