Received: by 10.223.176.46 with SMTP id f43csp1086083wra; Fri, 19 Jan 2018 06:44:41 -0800 (PST) X-Google-Smtp-Source: ACJfBosSMf2h/EiXMAH4wRv9tG8MJFYo7tzwyCgo/0unTsdnr1lK2n73HQUiiOp27wHwAViVVzT5 X-Received: by 10.99.99.199 with SMTP id x190mr36420444pgb.193.1516373081349; Fri, 19 Jan 2018 06:44:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516373081; cv=none; d=google.com; s=arc-20160816; b=Kc2ZILBbDrbEFNj7QXqx2FDgvY54tVBJgYuXfXdqEGin/y36CGqEZ/Ls3XGM2V89u0 Urh0RPHvjdTv8ejeXr1QjHQNcHsPPgw3qwiDnCqZ/LtzwJZmL17CBMNI4bFPyP9z/QIc GAQ1xAaO3fsPSXbasp/DyyOjaT1A/M27blInAD65J1hMNzjftZlIbkVsDKyhxgliqYAA RPLGiDRNjd3c3C4EzLCDLJLEM3ku0PrpXoEjNSJ/Jb/3ts/gcPI2fSrzyNeYjdDJL8T3 1SIZaDqTyfO7fE1hZ5XIHeICaXUx4JZ6vtkL7awxk8K0mHzbyJ6MIeMA9efrP6blX6aQ DySw== 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=+z39o3gu1xuYOnuZ2DR04mTuq1CX4Gnp8rw5U3ZniZk=; b=QreccKGjudanF6OzSE5qzyU4KC/CmJaAjVEWSK2z+nXOJA2HAtC0fL2juC0xWBm29x wBuJbqiiIbDqbnJCWWwOQouIwOY66gmBociiuAkha0+y5KZ9jNSGH8MUIbSRx8D27Rkn 4US2XEcUwiqBckZAKOTc/AT5ejDfwGN/7Yl9vzoWzVIO1Y0y+Mr9C5nk8GlLpOr7N1BN S5KxVPfCIMvsFCnDtK7p6HajkGRylZGsN5XeibfkEaEGJZiL0godhbEI1wL9NWaIoviG szqqSWumfsl7u7ACLXYZCQPaHUFtP+0A5kC0yu5LhpRAsuzVk5cMSWmiySNAI5A6s9fI iBRQ== 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 g4si8187843pgs.673.2018.01.19.06.44.26; Fri, 19 Jan 2018 06:44:41 -0800 (PST) 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 S1755600AbeASOn7 (ORCPT + 99 others); Fri, 19 Jan 2018 09:43:59 -0500 Received: from fieldses.org ([173.255.197.46]:51322 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753332AbeASOnv (ORCPT ); Fri, 19 Jan 2018 09:43:51 -0500 Received: by fieldses.org (Postfix, from userid 2815) id 15F41189; Fri, 19 Jan 2018 09:43:51 -0500 (EST) Date: Fri, 19 Jan 2018 09:43:51 -0500 From: "J. Bruce Fields" To: Jeff Layton Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org, neilb@suse.de, jack@suse.de, linux-ext4@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, linux-xfs@vger.kernel.org, darrick.wong@oracle.com, david@fromorbit.com, linux-btrfs@vger.kernel.org, clm@fb.com, jbacik@fb.com, dsterba@suse.com, linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com, dmitry.kasatkin@gmail.com, linux-afs@lists.infradead.org, dhowells@redhat.com, jaltman@auristor.com, krzk@kernel.org Subject: Re: [PATCH v5 02/19] fs: don't take the i_lock in inode_inc_iversion Message-ID: <20180119144351.GA11735@fieldses.org> References: <20180109141059.25929-1-jlayton@kernel.org> <20180109141059.25929-3-jlayton@kernel.org> <20180118214534.GB5299@fieldses.org> <1516372594.3588.11.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516372594.3588.11.camel@kernel.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 On Fri, Jan 19, 2018 at 09:36:34AM -0500, Jeff Layton wrote: > Shrug...we have that problem with the spinlock in place too. The bottom > line is that reads of this value are not serialized with the increment > at all. OK, so this wouldn't even be a new bug. > I'm not 100% thrilled with this patch, but I think it's probably better > not to add the i_lock all over the place, even as an interim step in > cleaning this stuff up. Makes sense to me. I've got no comments on the rest of the series, except that I'm all for it. Thanks for persisting--it turned out to be more involved than I'd imagined! --b.