From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752357AbdLFP53 (ORCPT ); Wed, 6 Dec 2017 10:57:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61442 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752270AbdLFP51 (ORCPT ); Wed, 6 Dec 2017 10:57:27 -0500 Date: Wed, 6 Dec 2017 17:57:25 +0200 From: "Michael S. Tsirkin" To: "Cherian, George" Cc: "linux-kernel@vger.kernel.org" , "davem@davemloft.net" , "jasowang@redhat.com" , "edumazet@google.com" , "netdev@vger.kernel.org" , "virtualization@lists.linux-foundation.org" Subject: Re: [PATCH] ptr_ring: Add barriers to fix NULL-pointer exception Message-ID: <20171206175023-mutt-send-email-mst@kernel.org> References: <1512554261-5030-1-git-send-email-george.cherian@cavium.com> <20171206153349-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 06 Dec 2017 15:57:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 06, 2017 at 02:08:54PM +0000, Cherian, George wrote: > > @@ -275,6 +281,13 @@ static inline void *__ptr_ring_consume(struct ptr_ring > *r) > > if (ptr) > > __ptr_ring_discard_one(r); > > > > + /* > > + * This barrier is necessary in order to prevent race condition with > > + * with __ptr_ring_produce(). Make sure all the elements of ptr is > > + * in sync with the earlier writes which was done prior to pushing > > + * it to ring > > + */ > > + rmb(); > > return ptr; > > } > > You are trying to synchronise two CPUs so non-smp barriers make no > sense. wmb/rmb are for synchronising with MMIO. > > What happens when CONFIG_SMP is not set. smp_wmb/rmb becomes compiler barriers > (atleast for arm64). And that is because all read and writes always appear in order when done from the same CPU. In case of reads, we do not need a barrier at all (except on dec alpha) because a read through a pointer can't bypass a read of a pointer. > I guess that is not what we need. Maybe, but I don't yet see why not. > An SMP barrier cannot > replace a mandatory barrier, but a mandatory barrier can replace an SMP > barrier. This does imply that you can always replace a weak barrier with a strong one, but does not mean you should. > I will try out your patch too and update the results. > But I would need couple of days time. Sorry for the delay. Thanks for the testing. -- MST