Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp972488ybl; Fri, 24 Jan 2020 12:59:44 -0800 (PST) X-Google-Smtp-Source: APXvYqwfEJURtKJyDlyV6t+eMdEugwhq41YSgUtlTy+x6EcdFbbjz06TL5p0tJysoTr40ejgvU+z X-Received: by 2002:aca:c452:: with SMTP id u79mr510644oif.89.1579899584794; Fri, 24 Jan 2020 12:59:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579899584; cv=none; d=google.com; s=arc-20160816; b=gGxxOI/Y6BYT1AO7WB3FfHidZSrVcwuPXz4/py+rYZWOb9eOVwOlNW1xfNKpy6u34S YKTiFZjXWnt1hfTvi7VOTCAqabQ7fkil99g5f0xwENJSTZKrGnNlnKGlZFZCpYY4yVXg AddTtfEgbxQ/Gmr9xqIHvN+E/ecksJc5zvHv57XUcLVXWwfBQJxno2YogpbG/+guo9dl H8Mh8z+/So8J+yhRhOpngauNf+1lZ7QoONT/kYMcJQ/8Ll0Hy4/Kic4DxMhC4m37swXQ 5wfafP5idaTQolx7l08ItaU/+bZCivy0q14iwAiWBqx5JflT15NY9WrGJcnQlG3vXhMJ eBaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/WLEg1m9kfC6ZJ507mX96SPdg1lNtEJFPo5i4esDCzE=; b=v09lPznRo/SkttsJPvXfJDufZHvrzTv2PjYP6MshdGP4iQ2k5NMly85zl8fCrmZj4M QJxtuzWKzwculL5fx8y58EPlIOaOPxP09LAzNoByoX32imtn7zW3cDC/g/Zrd4TCMHn+ dcAH0QCXX/ugNH0bc1K6KIjqdJNVb/6SvnHyh+9CkA8hJepws4HVsV1753pLPTfCzZR/ xoPXL/pXcJhu/Ael5NERfa3n+sHKdJYPve1IU6wHxbLnMpyxW5yNP2VSR7Fi8CsWlf3c jFefOx//2x8cPXOVH54BJYcYuZox+RDo7p3SIeS3pyRIvMuaa9hogFCgXuluteg+JmsE pEvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 i2si3379566otc.130.2020.01.24.12.59.33; Fri, 24 Jan 2020 12:59:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391365AbgAXSbI (ORCPT + 99 others); Fri, 24 Jan 2020 13:31:08 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:47020 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389707AbgAXSbH (ORCPT ); Fri, 24 Jan 2020 13:31:07 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iv3jT-00237c-6W; Fri, 24 Jan 2020 18:31:03 +0000 Date: Fri, 24 Jan 2020 18:31:03 +0000 From: Al Viro To: Eric Biggers Cc: Gao Xiang , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Daniel Rosenberg , Gabriel Krisman Bertazi Subject: Re: [PATCH] ext4: fix race conditions in ->d_compare() and ->d_hash() Message-ID: <20200124183103.GJ23230@ZenIV.linux.org.uk> References: <20200124041234.159740-1-ebiggers@kernel.org> <20200124050423.GA31271@hsiangkao-HP-ZHAN-66-Pro-G1> <20200124051601.GB832@sol.localdomain> <20200124053415.GC31271@hsiangkao-HP-ZHAN-66-Pro-G1> <20200124054256.GC832@sol.localdomain> <20200124061525.GA2407@hsiangkao-HP-ZHAN-66-Pro-G1> <20200124181253.GA41762@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200124181253.GA41762@gmail.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Jan 24, 2020 at 10:12:54AM -0800, Eric Biggers wrote: > > Thanks for your web reference, I will look into it. I think there > > is no worry about dentry->d_parent here because of this only one > > dereference on dentry->d_parent. > > > > You could ignore my words anyway, just my little thought though. > > Other part of the patch is ok. > > > > While that does make it really unlikely to cause a real-world problem, it's > still undefined behavior to not properly annotate a data race, it would make the > code harder to understand as there would be no indication that there's a data > race, and it would confuse tools that try to automatically detect data races. > So let's keep the READ_ONCE() on d_parent. *nod* Note that on everything except alpha it'll generate the same code, unless the compiler screws up an generates multiple loads. On alpha it adds a barrier and I really don't want to sit down and check if its absense could lead to anything unpleasant.