From patchwork Tue Jan 24 19:30:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 4471 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2335281wrn; Tue, 24 Jan 2023 11:31:20 -0800 (PST) X-Google-Smtp-Source: AMrXdXsCXMHtkar/K58TAa9eIlvZT4yhWDICKNlz5mJKXKl15acJTAlM3XQF/Q40BpQ86h0Tubpi X-Received: by 2002:a05:6a20:1a9d:b0:b6:3708:7be7 with SMTP id ci29-20020a056a201a9d00b000b637087be7mr23700610pzb.34.1674588680267; Tue, 24 Jan 2023 11:31:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674588680; cv=none; d=google.com; s=arc-20160816; b=RKjMjMxIpi3H2aYiFwn4FXMJEJLKig4Rdo9O9495CSmnAOx9riwaVZIJ3Usj4gJPrB +THX4bYfoRBtAH2rzUTUCJhvqBFLja1T8UcYdZ9EPNLWD39lWE1XnXJvV1r8liH2BdsR m4PhNDD3wZpcNR/HPUL7HKYwnsLiNVT4gNXvPi4ifOAgfOTlzc68IFcgcGHiHWK0FPT9 aOV1k47B2U6UBpms7d+XpX7tImpZWMybkY4Xma3j1nvrhqBcLunSHLLxht5Quu0IhSnh VoUtoo01zqv6QPNnlFKD7Dm21EpLWR+HViANK1MK0Y7/TccgmKbr+qcAuNuPRYMI8YVm r9gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=/KA8o7V28OI9YBlvx+6utOr/28oH77ymDIGFLi+dCvg=; b=MAh3HJE8X5rGF/m8+1lZEdI/TGAwPN6HFml5oaqhY01T0H7NWtFFTCYtTHm1ZijuI/ hkKmbvfH9HhueylnyY0JknZvCXDGYhatONXUVxw1gEu2BYU9qiLn15TfzbD0s+mNm85s 5Uas6BBz9AIOp+5brMiTKlgnwHjHkQo8BpnXsLZ1KXtAuVmw/nEzj8R5BAg5Gz7wSG0V j16/7ADUoyegbqNx7iZjXiV0Y3mbE2l9PXeQ1h8QdEhf2+9m1OjWULpmb/u0fVfmgSxG P1HFKZQtPYKp9/ZlXTinBs8E/3TtGC11IZlCsyu7LZokg16QXhIMtOauIk2UMi4jrnoL 6+cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Oq1fgOAv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w12-20020a63a74c000000b004960bccc53esi2881920pgo.698.2023.01.24.11.31.07; Tue, 24 Jan 2023 11:31:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Oq1fgOAv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234091AbjAXTaf (ORCPT + 99 others); Tue, 24 Jan 2023 14:30:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232952AbjAXTad (ORCPT ); Tue, 24 Jan 2023 14:30:33 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C5614DBDC; Tue, 24 Jan 2023 11:30:30 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E23866132C; Tue, 24 Jan 2023 19:30:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C702C433EF; Tue, 24 Jan 2023 19:30:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674588629; bh=vp0vqry2/AY0zb9xuGn4mOcoj9OvZ/inpse2FNVpqBI=; h=From:To:Cc:Subject:Date:From; b=Oq1fgOAvloQhlKFMsUavNC5pfqfY+THTTPrx5v8fc8B/UiuEChO4F4Ko8COr+On1Z nwj3yF3nKBIIdXf8ovX6RRVvFfV3kTuyLA+rGZCxRzNiRWHpQT2Nl3Vr5MJDPw2p9B vvzFgOJBXMYg7ARNBK7bvQblMMhqZHBRJKRVEg8A4unGw0qmIbSFLfyq14bYKhdaFk bQqYGnaccCUoQ0dyCv0zAs8Zdbaqw41mt3wgK2mbnnY0EGhtA5D9OVcOR4Bs03VgRN 44MUutfnQgaDajRpEHQjS7oGw8anySs8tLBtiyUFU58t6GNz0yp2NVR9IvrMiLOo89 1kcsW3Ky8XpQA== From: Jeff Layton To: tytso@mit.edu, adilger.kernel@dilger.ca, djwong@kernel.org, david@fromorbit.com, trondmy@hammerspace.com, neilb@suse.de, viro@zeniv.linux.org.uk, zohar@linux.ibm.com, xiubli@redhat.com, chuck.lever@oracle.com, lczerner@redhat.com, jack@suse.cz, bfields@fieldses.org, brauner@kernel.org, fweimer@redhat.com Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, ceph-devel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org Subject: [PATCH v8 RESEND 0/8] fs: clean up internal i_version handling Date: Tue, 24 Jan 2023 14:30:17 -0500 Message-Id: <20230124193025.185781-1-jlayton@kernel.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755933500072148257?= X-GMAIL-MSGID: =?utf-8?q?1755933500072148257?= I had inteded to send a PR for this for v6.2, but I got sidetracked with different issues, and didn't get it together in time. This set has been sitting in linux-next since October, and it seems to be behaving, so I intend to send a PR when the v6.3 merge window opens. Though nothing has really changed since last year, I'm resending now in the hopes I can collect a few more Reviewed-bys (ones from Al, Trond and Anna would be particularly welcome). The main consumer of i_version field (knfsd) has to jump through a number of hoops to fetch it, depending on what sort of inode it is. Rather than do this, we want to offload the responsibility for presenting this field to the filesystem's ->getattr operation, which is a more natural way to deal with a field that may be implemented differently. The focus of this patchset is to clean up these internal interfaces. This should also make it simple to present this attribute to userland in the future, which should be possible once the semantics are a bit more consistent across different backing filesystems. Thanks! Jeff Layton (8): fs: uninline inode_query_iversion fs: clarify when the i_version counter must be updated vfs: plumb i_version handling into struct kstat nfs: report the inode version in getattr if requested ceph: report the inode version in getattr if requested nfsd: move nfsd4_change_attribute to nfsfh.c nfsd: use the getattr operation to fetch i_version nfsd: remove fetch_iversion export operation fs/ceph/inode.c | 16 +++++++---- fs/libfs.c | 36 ++++++++++++++++++++++++ fs/nfs/export.c | 7 ----- fs/nfs/inode.c | 16 ++++++++--- fs/nfsd/nfs4xdr.c | 4 ++- fs/nfsd/nfsfh.c | 42 ++++++++++++++++++++++++++++ fs/nfsd/nfsfh.h | 29 +------------------- fs/nfsd/vfs.h | 7 ++++- fs/stat.c | 17 ++++++++++-- include/linux/exportfs.h | 1 - include/linux/iversion.h | 59 ++++++++++++++-------------------------- include/linux/stat.h | 9 ++++++ 12 files changed, 156 insertions(+), 87 deletions(-)