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 87DEEC76196 for ; Tue, 11 Apr 2023 14:54:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23A416B0075; Tue, 11 Apr 2023 10:54:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E9F96B0078; Tue, 11 Apr 2023 10:54:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B20E900002; Tue, 11 Apr 2023 10:54:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EFCA66B0075 for ; Tue, 11 Apr 2023 10:54:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C244AC0DC2 for ; Tue, 11 Apr 2023 14:54:50 +0000 (UTC) X-FDA: 80669407140.28.0FA4AB8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id 028BD8001F for ; Tue, 11 Apr 2023 14:54:48 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DXugew4H; spf=pass (imf30.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681224889; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BGlVt+c0htqp2gl2ZEP+PqakH/M1FrOboJgxH1gMbFA=; b=SQ+A/s+j8FDjtczQ+Abem+ZPjO91QBqGNDcaLWh4xz17iA1ibr+wYcOOvF9orAcpZsrnOn M94TpN6HCbC7Ledp1zMnWhkg2xdvlX0rt3KDWrjbOhPMh33nM9Ijs5tiJ46HbiCX+/3wwj YYk7eoieirTsrs/R/iuPdD2j04J3pwI= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DXugew4H; spf=pass (imf30.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681224889; a=rsa-sha256; cv=none; b=aa5fiHLmpqPbLQ1smRfs3NpXc53iGMM/tzoy7wKPMUFHeZJXVPClgILfIuHCQa0AcvfmI+ cnEWSR64VXDPlPqaKkuPw2R4Lx0M+xmoYB8TUoiZ7VxPaezxeaF1pOXCCz3VH34dSpa9aX KRUrvyCdbx/4YRKyEczvmCqsWwgvUiY= 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 0A22162800; Tue, 11 Apr 2023 14:54:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 697C0C433D2; Tue, 11 Apr 2023 14:54:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681224887; bh=CGAs5krnbEkxPgaPAZs8JvQBrcDCyRJbtDmkf6pgqFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DXugew4HthDAgFBFPE2Y+YeHKjqPLkIIGT0qU6/HO3aO4Mlj6uYdN9LcO8i/ixePo b17IMExYNJJyPkedoCq7nAeOFjJXKgbVuyMBBE5hL0QBBoXV4qsMq2Xk7XVbtUq82/ d16gGqvrGJYhXonPCK+e8YHiVR1INUlReTP5qrB6vFS2imX16R84fAdb0PE1ovk+F2 yNEbfo2qlZPy4GCMEcjXhMl3u089fP98Z85p7WasnlVS+Lch/IrirJhZNFcOzRtEZK JkggJUZbUQvse4WIrd0ZI8yu0iwo0c8w8H0q0HU9u+29p5bR8wWT8FUAqQUNteoRhJ qi1OQcDHA2fIA== Date: Tue, 11 Apr 2023 07:54:46 -0700 From: "Darrick J. Wong" To: Jeff Layton Cc: Alexander Viro , Christian Brauner , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [RFC PATCH 3/3][RESEND] xfs: mark the inode for high-res timestamp update in getattr Message-ID: <20230411145446.GG360895@frogsfrogsfrogs> References: <20230411143702.64495-1-jlayton@kernel.org> <20230411143702.64495-4-jlayton@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230411143702.64495-4-jlayton@kernel.org> X-Stat-Signature: hrhuzy14znfipmip8uhfccxhmz5dx8z5 X-Rspam-User: X-Rspamd-Queue-Id: 028BD8001F X-Rspamd-Server: rspam06 X-HE-Tag: 1681224888-897623 X-HE-Meta: U2FsdGVkX19Lf2gRhyFYfC0HU+2AVeKMpFQEGvTXxdGTM+bLBYsOmDVEfLYCahg8kTty+3+MUI8l/12wTD0QCsxIcM0dO55QeLcD49NNRVN7cZpoZ7I4kW8rQzYA5i7e27hwI+yc8MTxAh0Jw09uIQj4e1HihkhGfvxcSNGvl55sp8Zo0rrJS9QWKwIc3jIX7GB0NwIYcqj9Cosiztj3ugDnCvYFua2Aq15VyltTmhML/YkS43AWS7ga8MW0mNCMzvfjy+vLVJ12XZoX30DFIoOINsnUWnZ60eAo4kUs+CavjfZ61S5t3JXxZrefuJBErlka0195RVD/k1AKHqDA3m6H+c9Y1rwxqaEueXMd6p1Ig8J3xYGG38x8bfPbsfFCF6ab40/eC12DH/aqkhsSuRAv85CbV6ZqqZaJaJ4rQFWYW2ngpZ5g7rob8uo4BtBW0xhroWVqwGZnVclIAB6L5UP7UPRmEqGazNvKCKo5v6lRN4tn8aaJ+tUFE077vvB1qghomX77onDZ5yjfqFSDLbpnvfLV9nRBDUe49BSfzF3GlBZv072ew8NAPyfNbiYyiYnhGT75NxeYe02BCFi4+GzzES2PeFje4PXCJBvPFNA6L+KK12ssjxmX8j8zhY3wcGCjvLqmrV68d5SkmXftiFjfL7DDy752z7UcSJz++oIMFYK9FT5Gm6Ax1s6a51cw7K8huwToJbLrUSxNsvCZXlGvqnfTn4I2g+7wqlXo1WAXMJo+b+EV2vDgkJv3qYbiIWeX1rWqIcQkDtIddDMJkxJir04Pe/xwiwyoH3Pf54uQayk3ihGV+vNmaJSZrNBo8Ko2R3ovaRceLhIUm2l4B16X5GwH5OypHcb/qpu/LAeYqYRIW24+zUZ4R7txMJ15MOEInbDW9f/4wTV+E9d2Xb6y41irX7kpNc3Qov16lcuOv/pCbCL+DIQB5bvBuQN/wOGmOs40f4ajPqEcvqU MY7GtN9y DZfH4duR+wGWs7Bld7CBOfgR4PXqGNSts8vV0Ykh2n0Ar4BOimLWdeypfQEg2rKIJ92ui6mtLZDn1dSIWzraaHRJzU5FuR52lZsS3k59PAinK/wuzcQjgpyGSS6P37yXi5Ku2lHacnXGhWSRQwsJOQXm5fb5vCxh3k1mirTvywmXL2KEInkJGYVBIIevpCmMF9S7Zir2h6EH0ZLeb1oFcctRWAP48nDhdRsAKlfzXsjchZIQktJuYkAcoO+CIyN3k2V3aymGhLq6pkiRK9oygj/wnnb1bH4i/EvRyQXh5iiuW0+vqZ9c9LUfKkn8U/rzWGoIdwIjW0tyyrnRl02h3B5w1c9AfyWG2OIceAG731OQ2BCKrVNtKoS/Wj3SiG53PQUxaetH8gyyeDgVIKP7kNtLwNQ== 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 Tue, Apr 11, 2023 at 10:37:02AM -0400, Jeff Layton wrote: > When the mtime or ctime is being queried via getattr, ensure that we > mark the inode for a high-res timestamp update on the next pass. Also, > switch to current_cmtime for other c/mtime updates. > > With this change, we're better off having the NFS server just ignore > the i_version field and have it use the ctime instead, so clear the > STATX_CHANGE_COOKIE flag in the result mask in ->getattr. > > Signed-off-by: Jeff Layton > --- > fs/xfs/libxfs/xfs_trans_inode.c | 2 +- > fs/xfs/xfs_acl.c | 2 +- > fs/xfs/xfs_inode.c | 2 +- > fs/xfs/xfs_iops.c | 15 ++++++++++++--- > 4 files changed, 15 insertions(+), 6 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_trans_inode.c b/fs/xfs/libxfs/xfs_trans_inode.c > index 8b5547073379..9ad7c229c617 100644 > --- a/fs/xfs/libxfs/xfs_trans_inode.c > +++ b/fs/xfs/libxfs/xfs_trans_inode.c > @@ -63,7 +63,7 @@ xfs_trans_ichgtime( > ASSERT(tp); > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL)); > > - tv = current_time(inode); > + tv = current_cmtime(inode); > > if (flags & XFS_ICHGTIME_MOD) > inode->i_mtime = tv; > diff --git a/fs/xfs/xfs_acl.c b/fs/xfs/xfs_acl.c > index 791db7d9c849..461adc58cf8c 100644 > --- a/fs/xfs/xfs_acl.c > +++ b/fs/xfs/xfs_acl.c > @@ -233,7 +233,7 @@ xfs_acl_set_mode( > xfs_ilock(ip, XFS_ILOCK_EXCL); > xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); > inode->i_mode = mode; > - inode->i_ctime = current_time(inode); > + inode->i_ctime = current_cmtime(inode); Hmm, now we're adding a spinlock to all these updates. Does lockdep have anything exciting to say about this? (I don't think it will, just wondering aloud...) > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > > if (xfs_has_wsync(mp)) > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > index 5808abab786c..80f9d731e261 100644 > --- a/fs/xfs/xfs_inode.c > +++ b/fs/xfs/xfs_inode.c > @@ -843,7 +843,7 @@ xfs_init_new_inode( > ip->i_df.if_nextents = 0; > ASSERT(ip->i_nblocks == 0); > > - tv = current_time(inode); > + tv = current_cmtime(inode); > inode->i_mtime = tv; > inode->i_atime = tv; > inode->i_ctime = tv; > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c > index 24718adb3c16..a0b07f90e16c 100644 > --- a/fs/xfs/xfs_iops.c > +++ b/fs/xfs/xfs_iops.c > @@ -565,6 +565,15 @@ xfs_vn_getattr( > if (xfs_is_shutdown(mp)) > return -EIO; > > + /* > + * XFS uses the i_version infrastructure to track any change to > + * the inode, including atime updates. This means that the i_version > + * returned by getattr doesn't conform to what the callers expect. > + * Clear it here so that nfsd will fake up a change cookie from the > + * ctime instead. > + */ > + stat->result_mask &= ~STATX_CHANGE_COOKIE; > + > stat->size = XFS_ISIZE(ip); > stat->dev = inode->i_sb->s_dev; > stat->mode = inode->i_mode; > @@ -573,8 +582,8 @@ xfs_vn_getattr( > stat->gid = vfsgid_into_kgid(vfsgid); > stat->ino = ip->i_ino; > stat->atime = inode->i_atime; > - stat->mtime = inode->i_mtime; > - stat->ctime = inode->i_ctime; > + if (request_mask & (STATX_CTIME|STATX_MTIME)) > + fill_cmtime_and_mark(inode, stat); Should we be setting STATX_[CM]TIME in the result_mask, just in case the caller asked for ctime and not mtime? --D > stat->blocks = XFS_FSB_TO_BB(mp, ip->i_nblocks + ip->i_delayed_blks); > > if (xfs_has_v3inodes(mp)) { > @@ -917,7 +926,7 @@ xfs_setattr_size( > if (newsize != oldsize && > !(iattr->ia_valid & (ATTR_CTIME | ATTR_MTIME))) { > iattr->ia_ctime = iattr->ia_mtime = > - current_time(inode); > + current_cmtime(inode); > iattr->ia_valid |= ATTR_CTIME | ATTR_MTIME; > } > > -- > 2.39.2 >