Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7325862rdb; Wed, 3 Jan 2024 11:53:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHTGR15E5rjJSzyEqkjB+RZddJyvxcZwXCe58Y+xZdE6WgtrMS0N6JbzwjWaldu0vmlphvP X-Received: by 2002:a17:90a:2b46:b0:28b:ffa6:3165 with SMTP id y6-20020a17090a2b4600b0028bffa63165mr6218146pjc.65.1704311583769; Wed, 03 Jan 2024 11:53:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704311583; cv=none; d=google.com; s=arc-20160816; b=BclXUkmyrzMuEjbpc5asj0DmNbXZTY18FPIPMlnQmJoVsI8wqVe8mqMy6OLb8aJO1f b4ojt5aPgwntGKeQ/MDwuMhSOpH8cxK/PeIjXakOXZ2OJ1kSrdLamTv/f6fDgYDuoWzh DqW/S6uqx9sGYW4T46ZB0ZkQkpoj9n5O1luqWf/oVKAhigJMhQC+NgvHmzlE4aLw8yPY KQzi3BBIlJcLjiKZu6h+9ZvavJjzuUhjqgzva8K4WkdBQlDddzGvvNZTIK35sQsjLuYG nESmslT9pnKh3xRimp3kxj4R592qu6yGF88oqFWNaubGyg4v/L4njWUSrljr+1wgwbqW lDeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ZIab+jOpJ/PRavoEEHzUmrn/7DcVo+2bgEEpSP01YKA=; fh=oc7pd5iFrMEGaWG2WCCsstuj7P4c3gjN66aHpp7oCoM=; b=kycBZBlKN+zqQ94IxsN1eVdlLxEFuHulf0ULeukH3lH7gVsUQ1qrVRJcH987dqE59Y XRVZxWsZqHEBtudoRsgkSK7pCOu+gK+DswQO/Ts+XCj2tVuG560hi4uF4YuvaOpa7SIT MHDZ+qRJIsRGwwFjrsA3oKCeld0u0NG4SksknbEVa66RE8puSOflGtUXv/YwxT09CLP4 GkGSJNxnhZ40FrUbzJBR0ViGbUtItPiJEIz0yCf4ZlHrTewQHDpi1nfYjUMyVcHavBCU JfRxNFQW1IE2YpqtqPrHElFKx4CS9NR0jAWICsiBfHt/Mt8EW3i1xMy6QuO68Z87pPvY TsnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JUpU0ytY; spf=pass (google.com: domain of linux-nfs+bounces-902-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-902-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id x3-20020a17090abc8300b0028b88f8669fsi1660293pjr.24.2024.01.03.11.53.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 11:53:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs+bounces-902-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JUpU0ytY; spf=pass (google.com: domain of linux-nfs+bounces-902-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-902-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3D0802874B2 for ; Wed, 3 Jan 2024 19:53:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 226D11CFAC; Wed, 3 Jan 2024 19:52:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JUpU0ytY" X-Original-To: linux-nfs@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DF6DB1CF91; Wed, 3 Jan 2024 19:52:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C276C433C7; Wed, 3 Jan 2024 19:52:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704311578; bh=AGxGXJZa41oa0ZBFIkl3/sSNflvf5FcKlcCCl5qT46A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JUpU0ytYwAjqQ9Kmu6iuW4yOWPjAEv6QR2Bm0uQMeNdd/7EGUhaAe9asYTlUN7ub+ o4cx/VBQ8P0kzZGCZ2AhPKrnIueuZPzE3UOQE7RqPsK/y3QQeIomvTSS4W7mdktl1T KsOaldTfqSsZVbHpi+jSNgHE3ufTJgjHzAXZ8WNWD6AVoVPJtsdDn769V7KEwS3/Fb 8Em38nhwWOoz/WQ4LRIPYfErPlkuSsSJHvFYN+LNEN4cafX0e23octvhGxUkRVMlxs M8kAkhKgKb/1ICpZk+vpfF7yWUYvKwun430g3axWj6wKZxYgv6IFkEkx9XNe9jzQg0 +6Ko/cnkkgb/Q== Date: Wed, 3 Jan 2024 13:52:53 -0600 From: Eric Van Hensbergen To: Dominique Martinet Cc: David Howells , Jeff Layton , Steve French , Matthew Wilcox , Marc Dionne , Paulo Alcantara , Shyam Prasad N , Tom Talpey , Ilya Dryomov , Christian Brauner , linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Latchesar Ionkov , Christian Schoenebeck Subject: Re: [PATCH v5 40/40] 9p: Use netfslib read/write_iter Message-ID: References: <20231221132400.1601991-1-dhowells@redhat.com> <20231221132400.1601991-41-dhowells@redhat.com> 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: On Wed, Jan 03, 2024 at 04:22:29PM +0900, Dominique Martinet wrote: > David Howells wrote on Thu, Dec 21, 2023 at 01:23:35PM +0000: > > I've noticed we don't cache xattrs are all, so with the default mount > options on a kernel built with 9P_FS_SECURITY we'll get a gazillion > lookups for security.capabilities... But that's another problem, and > this is still an improvement so no reason to hold back. > This is a big problem and already on my backlog list since some things default to this even if the remote file system doesn't support xattrs. The quick fix is to disable on a mount when we detect the host side isn't supporting them (of course this could be weird for exports that cross file system boundries) -- at the very least we could keep this info on an inode basis and not request as long as the inode info is cached. Caching the actual properties is also a step, but given this is a security feature, I imagine we don't want to trust our cache and will always have to ask server unless we can come up with something clever to indicate xattr changes (haven't looked into that much yet). > > (I'd still be extremly thanksful if Christian and/or Eric would have > time to check as well, but I won't push back to merging it this merge > window next week if they don't have time... I'll also keep trying to run > some more tests as time allows) > I'll try to run through my regression tests as well, but sure we can fix things up after the merge window if we miss things. -eric