Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp2501526pxy; Mon, 3 May 2021 01:11:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrxKAhDKACKDnfLLcv0ieSyf06qO5GWUlJOJ6CCNvveyEsYOsi5dD82axHKDzMhayjd35I X-Received: by 2002:a63:1e1e:: with SMTP id e30mr17065491pge.77.1620029508954; Mon, 03 May 2021 01:11:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620029508; cv=none; d=google.com; s=arc-20160816; b=sjfzC32cZaa5zFO01qOC1HjGTAEznH4vGZG7FzLTTm4wK10hbgmv7stH/AYJE9QrA4 BZw6PcyndSsVoIOSHQ+6Ltu/UI6uFcpMS3xZ/NjE7nmmTuyCbRLX5KqYhBo0Mu2xn2k8 G6U3+suxKW7OaA7okJ3QYUsVApwNw03kJ0Tnnp1XDF1Os0cmPOjjREJa01EMG3H4Ssrn GNnKb/2RkwfQ4RFSATCKXDNAMhQdI3kOfGrErI15k/Kk13F8rZ6W7S+TMBzGuyIqPz8r TaVW/ZSGTxkpAZ3BKVnHLWNXqfx55u0NDLY9RTbOJydZEi4qQ7VBKERzmFccsQ+IrpFz eOlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date; bh=mnhbPJDs3TIhb79wFucq1gmNi1+W/PsBb3DjukOQ32Y=; b=Ymno8urrJVxLBzHZJugt9nuCBIb7nd5jk6cVCbUyDWbl0yMeHHhNIYC/tFvfmdyhUf sC54p5IQbWRI74xYs+2H6UxI8Byq7s0fWn8ttC+fmDYwkwKoWYSTzKH2aiapq3Z/US+E 614Ud5c1UKEfth7kOAoEssC4z08CaOTihA5xV0C2zj1fj7rKO3VFuKJxjmjEM/4EIeJV aXkS8/RQw9DxWA02AQg1FLDWP7ubjzHED1WTH6y7homc7Sv0eBu9cJXkrvwazNNlmoKy pxD8WxLtvV56d49RiLXIz0SNBHELt8XBe7+ehywFC7O+F4OuwW4Je0IVkDHhb8zVKTqC i8kA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w7si13613001plc.2.2021.05.03.01.11.25; Mon, 03 May 2021 01:11:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230186AbhECILI (ORCPT + 99 others); Mon, 3 May 2021 04:11:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:54350 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229817AbhECILH (ORCPT ); Mon, 3 May 2021 04:11:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C6390B157; Mon, 3 May 2021 08:10:13 +0000 (UTC) Date: Mon, 3 May 2021 10:10:12 +0200 From: Petr Vorel To: NeilBrown Cc: "J . Bruce Fields" , linux-nfs@vger.kernel.org, Steve Dickson , Chuck Lever , Alexey Kodanev Subject: Re: Re: [RFC PATCH 1/1] mount.nfs: Fix mounting on tmpfs Message-ID: Reply-To: Petr Vorel References: <20210422191803.31511-1-pvorel@suse.cz> <20210422202334.GB25415@fieldses.org> <20210423142329.GB10457@fieldses.org> <20210423181345.GE10457@fieldses.org> <162000848714.10466.9299093696289919822@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <162000848714.10466.9299093696289919822@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org > On Sat, 24 Apr 2021, J . Bruce Fields wrote: > > On Fri, Apr 23, 2021 at 07:04:41PM +0200, Petr Vorel wrote: > > > Hi Bruce, > > > > On Fri, Apr 23, 2021 at 04:17:52AM +0200, Petr Vorel wrote: > > > > > Hi, > > > > > > On Thu, Apr 22, 2021 at 09:18:03PM +0200, Petr Vorel wrote: > > > > > > > LTP NFS tests (which use netns) fails on tmpfs since d4066486: > > > > > > > mount -t nfs -o proto=tcp,vers=4.2 10.0.0.2:/tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/tcp /tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/0 > > > > > > > mount.nfs: mounting 10.0.0.2:/tmp/ltp.nfs01.nfs-4.2/LTP_nfs01.UF6gRZCy3O/4.2/tcp failed, reason given by server: No such file or directory > > > > > > We should figure out the reason for the failure. A network trace might > > > > > > help. > > > > > Anything specific you're looking for? > > > > Actually I was thinking of capturing the network traffic, something > > > > like: > > > > tcpdump -s0 -wtmp.pcap -i > > > > then try the mount, then kill tcpdump and look at tmp.pcap. > > > I don't see anything suspicious, can you please have a look? > > > https://gitlab.com/pevik/tmp/-/raw/master/nfs.v3.pcap > > > https://gitlab.com/pevik/tmp/-/raw/master/nfs.v4.pcap > > > https://gitlab.com/pevik/tmp/-/raw/master/nfs.v4.1.pcap > > > https://gitlab.com/pevik/tmp/-/raw/master/nfs.v4.2.pcap > > It might be the "hide" option, that's odd: > Nup. I think "hide" is ignored for NFSv4 anyway. > Problem is that a subdirectory of a tmpfs filesystem is being exported. > That requires (for NFSv4), the top of the tmpfs filesystem to be > exported with NFSEXP_V4ROOT so that an NFSv4 client can navigate down to > it. > But when mountd creates that V4ROOT export, it doesn't provide the fsid. > So the kernel rejects the export request. > We need to fix mountd to set the fsid on all exports within a filesystem > for which it was specified, particularly the NFSEXP_V4ROOT ancestors. > I might see if I how easy that is later. Hi Neil, Thanks a lot for analysis. Right, mount.nfs is not to blame, but the server part (nfs-kernel-server). Kind regards, Petr > NeilBrown