Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp185189imm; Tue, 14 Aug 2018 16:50:52 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxVrd4tYUsS6iNM1wHtGqdDfdqOpNdQNpQe01Y6W7ycTGcUD1kGDEqKVEPfw8kW81yBbIT0 X-Received: by 2002:a62:5047:: with SMTP id e68-v6mr25769872pfb.157.1534290652841; Tue, 14 Aug 2018 16:50:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534290652; cv=none; d=google.com; s=arc-20160816; b=eaxgYCYwwLc72oSeOKnaQJc79ie+kb3py5pTiBAi2b+QEVrVLSykKHuVaJUIUy7TtB RDkx8jHfJEHyczTMNnmnhMQF9IzpPbW9VCg08WfoLoMpAzSYlZ1utZxVH7ltX5ACkF6k W72WLSIghw63y93YW97l3jNE2KyRNZnEedsVvKOs5nLTL6zfHva4UxuEE+cpjX04/znS u/SppraZq5OKqOYgqHX7DuplwJaZ3V5prpn2jZT7CLVGxWtDHtGP0ZM0HwXw1AV5M8S+ qyVcnofV7qwcLWb8C3WXYULsRKCswsHMKLGQ/zz9gobM9Qc6Tm439jxtuVd9uKDXI6MA SDiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=yIcA3r4M2pCSyN03AN6t+ISK2t+mtGESZdQgtcbz6+4=; b=Z/QEHIm3KShJ/OZY89ZZJSgNVGU96B4SQ274CGQ9TFBXiX1szJJ/5qp+DibXNkdIr9 SyGHKnwKhTq22Sp5lgv2/9TnqiHrgOw3uzNd/Nj0IT4k6e+ZTNX9lyOZLlCCmfm8edAo lb6JVn+6p5WvKHtNymx/iNsv6r83LX1N4sKSp5blWIhNajjGWqw0TrHJI1Yz7pMsCW5Y t/15gAKZhgeDj4LigwyKKta3EEZ8oQn9oE27DXxTl6j/4fbqFd7mxpEylyJ3v1sMbXDb pkmpZks2ycQzP+TRdX+5wczd6L/RsJ66e83QgX+/V+o6vcZ8f+Lb6WVO7dNLVevEZeA9 NbQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si17781278ply.483.2018.08.14.16.50.37; Tue, 14 Aug 2018 16:50:52 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728146AbeHOCi3 (ORCPT + 99 others); Tue, 14 Aug 2018 22:38:29 -0400 Received: from mga04.intel.com ([192.55.52.120]:37279 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726837AbeHOCi3 (ORCPT ); Tue, 14 Aug 2018 22:38:29 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2018 16:48:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,240,1531810800"; d="scan'208";a="254892378" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga006.fm.intel.com with ESMTP; 14 Aug 2018 16:48:55 -0700 Date: Tue, 14 Aug 2018 17:49:40 -0600 From: Keith Busch To: Linus Torvalds Cc: wnukowski@google.com, Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-nvme , Keith Busch , yigitfiliz@google.com, Christoph Hellwig Subject: Re: [PATCH] Bugfix for handling of shadow doorbell buffer. Message-ID: <20180814234940.GB3224@localhost.localdomain> References: <20180814221735.62804-1-wnukowski@google.com> <20180814225716.GA3224@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 14, 2018 at 04:16:41PM -0700, Linus Torvalds wrote: > On Tue, Aug 14, 2018 at 3:56 PM Keith Busch wrote: > > > > You just want to ensure the '*dbbuf_db = value' isn't reordered, right? > > The order dependency might be more obvious if done as: > > > > WRITE_ONCE(*dbbuf_db, value); > > > > if (!nvme_dbbuf_need_event(READ_ONCE(*dbbuf_ei), value, old_value)) > > return false; > > > > And 'volatile' is again redundant. > > Yes, using READ_ONCE/WRITE_ONCE obviates the need for volatile, but it > does *not* impose a memory ordering. > > It imposes an ordering on the compiler, but not on the CPU, so you > still want the "mb()" there I mistakenly recalled memory-barriers.txt mentioned order was enforced on the CPU, but that's true only for overlapping memory, which this is not. Thanks for the correction.