Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp5956031ybx; Mon, 11 Nov 2019 01:18:29 -0800 (PST) X-Google-Smtp-Source: APXvYqzpL+y0OtMN78AyufvKFyLLJP4fEWWsFwDM5Csg1mXj5kGSponkE0bRqCTrF5ppeBCV+8eE X-Received: by 2002:a17:907:20b8:: with SMTP id pw24mr9836868ejb.28.1573463909010; Mon, 11 Nov 2019 01:18:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573463909; cv=none; d=google.com; s=arc-20160816; b=cB9Fot3ocr7+YriToIM9eGTX+1Fli4e/7ftTAdwKDYCZG0Wxu2tTaghZRutYyHo5Rb h5Tj4zwUrmCYbYiVopA+5FSxEa2jZeT9+UzQSQtyb7KiTq7OqqCEXKSh9ZB897mLKogI 3HN0KjJG3YWmYQiDTI9tc/wHx3ns/vp/L3xJZVl3DnsiBSmzYCbggRmTES+hbJ/V0NoB qlHJ6Yw0Ix4J7osRQziCjyko0ImE7gB+r66mOPMz3wKFz70z0yecALWLNLFVJJge8ov7 YS46JqW2GcGC8WqTMPSemrJn3qSUhe/YYC2YjgsTYsmwx4OoujMSNe3ddbeWHVwUOrPU DOnQ== 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; bh=fjxgNTUK1XmxtzoFmZ+tLAeaG6Nhy0aqw6CufjYJzKk=; b=rVZ/pqOFnfYnr6oG0BA++yOTUlxoDUrANGQ/tRRtRgcEiYMEJ1JVcBddBU75vioH8t 7oefkbI+800MVO3dEmR7SFkeOfUpIQaMmm9QK6wqrviMLV0WA1hK00ElFNBpMKviHxwv B5QebR2ugGHecZaOeu8nU1P0K+RbqgKwFh7VIz5p4EyLgFkQG3l6AZVxvgghPVqNjHJl +4f5q8FtdOaY0ar4BRMPo9DUsRwCY6N7nRruKJDxMRZhezgRJN4Va3kMycsAK/b7LbG8 LxVZLwxTPXNcrdn+k07j1+ig4hHLkj/Nmi+VA4H2UCbk6zCO/dr4H9eptFaXZX3cRcTE Qpew== 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 p20si9151486edq.121.2019.11.11.01.18.05; Mon, 11 Nov 2019 01:18:28 -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 S1726957AbfKKJQs (ORCPT + 99 others); Mon, 11 Nov 2019 04:16:48 -0500 Received: from verein.lst.de ([213.95.11.211]:48230 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726768AbfKKJQs (ORCPT ); Mon, 11 Nov 2019 04:16:48 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 061B968BE1; Mon, 11 Nov 2019 10:16:45 +0100 (CET) Date: Mon, 11 Nov 2019 10:16:44 +0100 From: Christoph Hellwig To: Al Viro Cc: "J. Bruce Fields" , Ritesh Harjani , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, wugyuan@cn.ibm.com, jlayton@kernel.org, hsiangkao@aol.com, Jan Kara , Linus Torvalds , Christoph Hellwig Subject: Re: [PATCH][RFC] race in exportfs_decode_fh() Message-ID: <20191111091644.GA11108@lst.de> References: <20190927044243.18856-1-riteshh@linux.ibm.com> <20191015040730.6A84742047@d06av24.portsmouth.uk.ibm.com> <20191022133855.B1B4752050@d06av21.portsmouth.uk.ibm.com> <20191022143736.GX26530@ZenIV.linux.org.uk> <20191022201131.GZ26530@ZenIV.linux.org.uk> <20191023110551.D04AE4C044@d06av22.portsmouth.uk.ibm.com> <20191101234622.GM26530@ZenIV.linux.org.uk> <20191102172229.GT20975@paulmck-ThinkPad-P72> <20191102180842.GN26530@ZenIV.linux.org.uk> <20191109031333.GA8566@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191109031333.GA8566@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 09, 2019 at 03:13:33AM +0000, Al Viro wrote: > Does anyone see objections to the following patch? Christoph, that seems to > be your code; am I missing something subtle here? AFAICS, that goes back to > 2007 or so... This goes back to way before that, that series jut factored out proper export operations from the two inode or superblock methods we had before with the rest handled in core code somewhere that made a complete mess of file systems with 64-bit inode numbers. Otherwise this looks fine, although splitting the refactoring from the actual change would make for a much more readable series.