From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC2EA53370 for ; Thu, 4 Jul 2024 06:00:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720072829; cv=none; b=cN4sSkMva4wXnY7xR6a6ognD4CZVFyVbZ/aVtwUsTCuVjZ0m2rVJ0EVRE7PX4J6toskEZ/zofbiBmrTnbOm84BH/bz4Zykx5rPsfPfQUFvDOi4QGXWvBV8SCJ61QGoWh1sk48J/OlFcduxjl2fCuuI955V0kyF20IyNFqJqojqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720072829; c=relaxed/simple; bh=jcttPxu901sc/ahVdWKQsPlOw3NmLFs3Oz81a12uPSk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l0l5KJwZrV3S50rYBVfmKg5NtBO0aG7c8tNTkM+4bXBGVVtobRXZZwz+K+/IOOT0NqQ3h7due0MyZSlYmje56DtPEa6xjMBNdaU2zjmBUJOyMhXL1SeAbPAXpdBbi9Zlldg4CWkdcZH3R9I5zQIKZy/Nyjsyl5In8jHP6vqpBWU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=xlb9zJY4; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="xlb9zJY4" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=qrawXIH8jMpJvtKdZWoFlRIsdBjEfFxl2OPLPmhUdhc=; b=xlb9zJY44ycoCpm3Q0fZWhhCo0 ZscoNtM+XOhD2uuZVtLAUd5Ou2e0iR69ECLsO3ot8P3aK0sG78u0bi7O78Wr0kmeePpfyB4HYOJB8 eT2IM7nlsrRVDAVGOboYd/LUTl7jdNpLvd+b0oYO3XzLRgbzr1s22SXPuCdD4gd4H7D+fo2le3xYk CenMWMp0GvTFZDWwv86hL11aL0uTveL4EIr3yOeQFcOj3G4vVeYXamHMxcNnTZQDmCOOP8ti51XRJ 9srCINTKJ51ET6hn8gqoTjiVjuJ5/s2RL7FJDOUnO+tXn/4Nfmt+uRbmjEW7THGE/hvsBBPr0AnQW ftACls6g==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sPFW7-0000000CHCz-0Qye; Thu, 04 Jul 2024 06:00:27 +0000 Date: Wed, 3 Jul 2024 23:00:27 -0700 From: Christoph Hellwig To: Jeff Layton Cc: Mike Snitzer , Chuck Lever III , Christoph Hellwig , Linux NFS Mailing List , Anna Schumaker , Trond Myklebust , Neil Brown , Dave Chinner Subject: Re: [PATCH v11 00/20] nfs/nfsd: add support for localio Message-ID: References: <20240702162831.91604-1-snitzer@kernel.org> <3A583EDC-519C-4820-87E9-F4DC164656DB@oracle.com> <4486ee80a487c174ec88c7e12705d99e22ae812a.camel@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4486ee80a487c174ec88c7e12705d99e22ae812a.camel@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Jul 03, 2024 at 01:06:51PM -0400, Jeff Layton wrote: > The other problem with doing this is that if a server is running in a > container, how is it to know that the client is in different container > on the same host, and hence that it can give out a localio layout? We'd > still need some way to detect that anyway, which would probably look a > lot like the localio protocol. We'll need some way to detect that client and server are capable of the bypass. And from all it looks that's actually the hard and complicated part, and we'll need that for any scheme. And then we need a way to bypass the server for I/O, which currently is rather complex in the patchset and would be almost trivial with a new pNFS layout. > Can the client use its localio access to bypass that since it's not > going across the network anymore? Maybe by using open_by_handle_at on > the NFS share on a guessed filehandle? I think we need to ensure that > that isn't possible. If a file system is shared by containers and users in containers have the capability to use open_by_handle_at the security model is already broken without NFS or localio involved. > I wonder if it's also worthwhile to gate localio access on an export > option, just out of an abundance of caution. export and mount option. We're speaking a non-standard side band protocol here, there is no way that should be done without explicit opt-in from both sides.