Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp7621644imm; Thu, 28 Jun 2018 06:50:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJreiyAjXtzy283we87MV4FNcBmBej07HYw8Ezlj+us8bXAeIDrmF1tIwR9JgrD0Xckrq9m X-Received: by 2002:a65:64cf:: with SMTP id t15-v6mr8920088pgv.79.1530193829603; Thu, 28 Jun 2018 06:50:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530193829; cv=none; d=google.com; s=arc-20160816; b=BSCF6vu5TYB5MpB7JYSfviUmYbxs9WuXkPezRaSP68Nh8MvmLvoMS6lXig3AnVqqA9 ZHvoi6EowuaqbiekJoCkNpZwU4/+TlNdka7RSrp97p1v4ZRy9FHmvjA1eiq6vq8akNq8 C8fd25+Hc/5LRT6kvVpNB1eOm6Or3nHXmg7E5xFrLzCF/Iq4w2PS0+02iexDK6A7NeSI Y5IYxwnAK4283e1FlU5oT6IQUG53PYVRKLIy8uGI5t4AcbS926/GLRPd4Sr6bjJ4Bfc4 sjVI/NcIjBbws7B0p99dZnUoMpT8PQyoZ8qqAEhKbyfBACxJLx9QIa+stN/6Xl34weTs CRfw== 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=6M6XnjJIxxjpcQyunb8XmoQwHZLH1Hr9Ga6WT2cQZjA=; b=EnBbvOHr91P9qpY6f4nbVyl4uqpztQf2Q1twOJQCrl2Ft3bldQuPMQ04JmlqutUtAW U/0rctRj7BJQzFBzcDs8/mZX/aga88Dpde43dHYnEo40S+JnKWB/Ozol+DOQsgZ08QfC 5YEXARO3ccJ/2582xmtLJSmP/9X3BfLbgs7qkjypmtTXxyHHWLNhVwX/KIzs6SJfOeU4 VFEogq/DECiB+/SHoUyjfIYXgguGzDCqK2noyZ4DXPm8Gfdd2HhtrdJcWTMnUuRP7WBb AxLaQgvZcNozXWw1/dWP1IajyBkF6qgNYXeSiIrNwRTgLl+fxB7AE2/zM6RT7/QaJo2a kOsA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 63-v6si5989192pgi.229.2018.06.28.06.50.14; Thu, 28 Jun 2018 06:50:29 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966295AbeF1NsI (ORCPT + 99 others); Thu, 28 Jun 2018 09:48:08 -0400 Received: from nautica.notk.org ([91.121.71.147]:33391 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966279AbeF1NsG (ORCPT ); Thu, 28 Jun 2018 09:48:06 -0400 X-Greylist: delayed 441 seconds by postgrey-1.27 at vger.kernel.org; Thu, 28 Jun 2018 09:48:06 EDT Received: by nautica.notk.org (Postfix, from userid 1001) id 5DB86C009; Thu, 28 Jun 2018 15:40:44 +0200 (CEST) Date: Thu, 28 Jun 2018 15:40:29 +0200 From: Dominique Martinet To: Matthew Wilcox Cc: v9fs-developer@lists.sourceforge.net, Latchesar Ionkov , Eric Van Hensbergen , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Ron Minnich Subject: Re: [V9fs-developer] [PATCH 4/6] 9p: Remove an unnecessary memory barrier Message-ID: <20180628134029.GA24673@nautica> References: <20180628132629.3148-1-willy@infradead.org> <20180628132629.3148-5-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180628132629.3148-5-willy@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Matthew Wilcox wrote on Thu, Jun 28, 2018: > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -436,13 +436,9 @@ void p9_client_cb(struct p9_client *c, struct p9_req_t *req, int status) > { > p9_debug(P9_DEBUG_MUX, " tag %d\n", req->tc->tag); > > - /* > - * This barrier is needed to make sure any change made to req before > - * the other thread wakes up will indeed be seen by the waiting side. > - */ > - smp_wmb(); > req->status = status; > > + /* wake_up is an implicit write memory barrier */ Nope. Please note the wmb is _before_ setting status, basically it protects from cpu optimizations where status could be set before other fields, then other core opportunistically checking and finding status is good so other thread continuing. I could only reproduce this bug with infiniband network, but it is very definitely needed. Here is the commit message of when I added that barrier: ----- 9P: Add memory barriers to protect request fields over cb/rpc threads handoff We need barriers to guarantee this pattern works as intended: [w] req->rc, 1 [r] req->status, 1 wmb rmb [w] req->status, 1 [r] req->rc Where the wmb ensures that rc gets written before status, and the rmb ensures that if you observe status == 1, rc is the new value. ----- It might need an update to the comment though, if you thought about removing it... -- Dominique Martinet | Asmadeus