From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE87EECAAA1 for ; Fri, 9 Sep 2022 21:03:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B7FB8D0003; Fri, 9 Sep 2022 17:03:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0683C8D0002; Fri, 9 Sep 2022 17:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E723E8D0003; Fri, 9 Sep 2022 17:03:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D28AD8D0002 for ; Fri, 9 Sep 2022 17:03:46 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AD1B01A0627 for ; Fri, 9 Sep 2022 21:03:46 +0000 (UTC) X-FDA: 79893773652.28.2AC85DA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 4B7CE20083 for ; Fri, 9 Sep 2022 21:03:46 +0000 (UTC) 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 75884620D4; Fri, 9 Sep 2022 21:03:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 036A5C433D6; Fri, 9 Sep 2022 21:03:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1662757425; bh=pukS0Y1Nko6S/uhOJVBC7Y1eyhfAEWbe8HwZnC6UtXQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DnjHda/yP6A7uS7EmT5gALCLLb+Behr5+rCSh4ky9cCnpH9GN9SW/5HZBMKQbipUl 7/iF9KSjAVAHshQN/w3kmARUMj9UM7HkO6eWBTf65fihqoKR8+PNZqTQ79yZvvJaIA pHuOZXAeaVjjGT/ywuWs/O+RW/Touhxao8s/kTE8= Date: Fri, 9 Sep 2022 14:03:44 -0700 From: Andrew Morton To: Jeff Layton Cc: hughd@google.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, Chuck Lever Subject: Re: [PATCH] tmpfs: add support for an i_version counter Message-Id: <20220909140344.16f2bf7fbc11a5ac62b932bc@linux-foundation.org> In-Reply-To: <20220909130031.15477-1-jlayton@kernel.org> References: <20220909130031.15477-1-jlayton@kernel.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662757426; a=rsa-sha256; cv=none; b=sTQLrFOV3UPPx/L8Sge7t6Q8X31BAysZje3zV8mfVWmMl2pUOm5ypkxmU+ZWioLkg4sI0r oOtuErIUQGCy8G/VTVFG+s70Rygr9J7T3RfdlCuoA5UK+a7WzBVznhT3fHa9OVw1TnvbZh f5VnKLyB4fxEyYagCjDkM5Krwv/9KwQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="DnjHda/y"; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662757426; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RPBL0l2AVkZ/9UpCV9aafeqY9Set3r3n2rtz5RDMuls=; b=SSsiag6zLBdBQe4RV2pDGbXv6LHxT56/cYx6dPNO2tuS3Om52z8v2jAWqfjUaZHm3iJUY3 k+9eow2/Ucr8XtYEzLYPfyNR5O79Qj9gOI44d/Hn8FUO0f0d0vr4FJlJMUQc0friHQi74N jGCMJq2RbKR9R6HuB2iRVM3uJYJCh3E= Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="DnjHda/y"; spf=pass (imf13.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-Stat-Signature: wisqyguyao335pt1tzcbij6xf7mhrau1 X-Rspamd-Queue-Id: 4B7CE20083 X-Rspamd-Server: rspam01 X-HE-Tag: 1662757426-513076 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 9 Sep 2022 09:00:31 -0400 Jeff Layton wrote: > NFSv4 mandates a change attribute to avoid problems with timestamp > granularity, which Linux implements using the i_version counter. This is > particularly important when the underlying filesystem is fast. > > Give tmpfs an i_version counter. Since it doesn't have to be persistent, > we can just turn on SB_I_VERSION and sprinkle some inode_inc_iversion > calls in the right places. > > Also, while there is no formal spec for xattrs, most implementations > update the ctime on setxattr. Fix shmem_xattr_handler_set to update the > ctime and bump the i_version appropriately. > > ... > > --- a/fs/posix_acl.c > +++ b/fs/posix_acl.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > static struct posix_acl **acl_by_type(struct inode *inode, int type) > { > @@ -1073,6 +1074,8 @@ int simple_set_acl(struct user_namespace *mnt_userns, struct inode *inode, > } > > inode->i_ctime = current_time(inode); > + if (IS_I_VERSION(inode)) > + inode_inc_iversion(inode); > set_cached_acl(inode, type, acl); > return 0; > } adds a kilobyte of text to shmem.o because the quite large inode_maybe_inc_iversion() get inlined all over the place. Why oh why. Is there any reason not to do the obvious? --- a/include/linux/iversion.h~a +++ a/include/linux/iversion.h @@ -177,56 +177,7 @@ inode_set_iversion_queried(struct inode I_VERSION_QUERIED); } -/** - * inode_maybe_inc_iversion - increments i_version - * @inode: inode with the i_version that should be updated - * @force: increment the counter even if it's not necessary? - * - * Every time the inode is modified, the i_version field must be seen to have - * changed by any observer. - * - * If "force" is set or the QUERIED flag is set, then ensure that we increment - * the value, and clear the queried flag. - * - * In the common case where neither is set, then we can return "false" without - * updating i_version. - * - * If this function returns false, and no other metadata has changed, then we - * can avoid logging the metadata. - */ -static inline bool -inode_maybe_inc_iversion(struct inode *inode, bool force) -{ - u64 cur, old, new; - - /* - * The i_version field is not strictly ordered with any other inode - * information, but the legacy inode_inc_iversion code used a spinlock - * to serialize increments. - * - * Here, we add full memory barriers to ensure that any de-facto - * ordering with other info is preserved. - * - * This barrier pairs with the barrier in inode_query_iversion() - */ - smp_mb(); - cur = inode_peek_iversion_raw(inode); - for (;;) { - /* If flag is clear then we needn't do anything */ - if (!force && !(cur & I_VERSION_QUERIED)) - return false; - - /* Since lowest bit is flag, add 2 to avoid it */ - new = (cur & ~I_VERSION_QUERIED) + I_VERSION_INCREMENT; - - old = atomic64_cmpxchg(&inode->i_version, cur, new); - if (likely(old == cur)) - break; - cur = old; - } - return true; -} - +bool inode_maybe_inc_iversion(struct inode *inode, bool force); /** * inode_inc_iversion - forcibly increment i_version --- a/fs/libfs.c~a +++ a/fs/libfs.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include /* sync_mapping_buffers */ #include @@ -1529,3 +1530,53 @@ void generic_set_encrypted_ci_d_ops(stru #endif } EXPORT_SYMBOL(generic_set_encrypted_ci_d_ops); + +/** + * inode_maybe_inc_iversion - increments i_version + * @inode: inode with the i_version that should be updated + * @force: increment the counter even if it's not necessary? + * + * Every time the inode is modified, the i_version field must be seen to have + * changed by any observer. + * + * If "force" is set or the QUERIED flag is set, then ensure that we increment + * the value, and clear the queried flag. + * + * In the common case where neither is set, then we can return "false" without + * updating i_version. + * + * If this function returns false, and no other metadata has changed, then we + * can avoid logging the metadata. + */ +bool inode_maybe_inc_iversion(struct inode *inode, bool force) +{ + u64 cur, old, new; + + /* + * The i_version field is not strictly ordered with any other inode + * information, but the legacy inode_inc_iversion code used a spinlock + * to serialize increments. + * + * Here, we add full memory barriers to ensure that any de-facto + * ordering with other info is preserved. + * + * This barrier pairs with the barrier in inode_query_iversion() + */ + smp_mb(); + cur = inode_peek_iversion_raw(inode); + for (;;) { + /* If flag is clear then we needn't do anything */ + if (!force && !(cur & I_VERSION_QUERIED)) + return false; + + /* Since lowest bit is flag, add 2 to avoid it */ + new = (cur & ~I_VERSION_QUERIED) + I_VERSION_INCREMENT; + + old = atomic64_cmpxchg(&inode->i_version, cur, new); + if (likely(old == cur)) + break; + cur = old; + } + return true; +} +EXPORT_SYMBOL(inode_maybe_inc_iversion); _