Message ID | 20230705190309.579783-10-jlayton@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp2096393vqx; Wed, 5 Jul 2023 12:42:24 -0700 (PDT) X-Google-Smtp-Source: APBJJlHqmxbQ4aytocLT8GJVLbr4rjCLgbndn1LjRAJAmotoySqXsPPAPnTGtEx3Y3rdJLX0BkTF X-Received: by 2002:a05:6a00:a10:b0:682:b6c8:2eb with SMTP id p16-20020a056a000a1000b00682b6c802ebmr2547663pfh.1.1688586144674; Wed, 05 Jul 2023 12:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688586144; cv=none; d=google.com; s=arc-20160816; b=WMcYWQo3Ohxb50XoakH9YE9nQ5DwlBDWEfCtevREQ6WweobjRsWGU2U3I9x7l8l2ds 58UCZyYduQxxqOWImTUBpLuS1W8JWufcfCbIPRiKzB40nkRoILL5IgQN4WE6R8DMspT4 G6PAI/N/xKGlZ+RNwit/E6OkdERVqSywoExSIK2ve4gkRNBgmzNBnR287mjXMHYByN34 1HdNnEIWBwzvvX1z+0Z+ZTaAtG8lydrfO/N3Pl/sRph6GAO5+izzUJCO7f/yl02adt+1 vVgYBoZVkdLPk4kgD4rSDsJwCNCCwd/MzLpt7/5eJsEgdx22WgNfpRwqzINHY7eMYMIP XX+A== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kTcn6PeUAQVRDy6dYWBUimmoT6wzp+NDLDHnkeFcdKY=; fh=Nk/0tMRLb8D+wJo4Zmm3v7/GPXN2K9PAwHUJV3gzhLs=; b=AgQa1Y2kCD5kZ0wtClR+hIxbl2n2VOZvib4MNdvPjVg1BsqD+psZakP0Z35hjByU3V MRSkoX+DeMiwYvspnBD82zol8cSlGZJniH+2GSH6+LmME1wDsvMPlMt4rjknnc+kmkss ewt3lJEaGUSKObMDthjBB3n8iGlmkqTAsOAhL9W7+20dW5KUT09kydQAxsRcVRePYWn/ 2ckSYXpxYNldIfumYWlSk3NBjZtRRw63wEZXDhqrbCv1AkFvyPYP3r2e29AF71tiMIf1 SE4etk/GuqjdrvRcs+71FSiJVjmdW8OaunChRjeguOm51oOQkv3UaBURnAJV1KFdv58N L6mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=StuSvgMi; 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 cp22-20020a056a00349600b00643c4345942si22565759pfb.134.2023.07.05.12.42.10; Wed, 05 Jul 2023 12:42:24 -0700 (PDT) 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=StuSvgMi; 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 S233593AbjGETD5 (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Wed, 5 Jul 2023 15:03:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42804 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233499AbjGETDb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 5 Jul 2023 15:03:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 262EA1BC8; Wed, 5 Jul 2023 12:03:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B9C3C616EE; Wed, 5 Jul 2023 19:03:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E5FBC433C8; Wed, 5 Jul 2023 19:03:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688583805; bh=J50IkY8hwE4QTdi0JMbfyXssVuP1VqMJJNGL0hjOLIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=StuSvgMioLeO2MnU4FKLpR57Lq9joplYJ/hH+vDNtOQre9Z2gxqUVPf4nO7z3zuqP Sejb0izI8q7txVYTFwFQ2gcblCAas/UBidU3vMW/44Ahvb68XOP7WQts7Y29V5MFcU 7CBQfeUGYUibnKvuI3WmZaI5AVxSbqLrXI4hmaJYfHNVCXbxXiH0LFbCQKdtSNgChI 7XMQo2YOLiS1XfVbPoBjKz1S4ll5bj0+U4m+arMmGWMkbX2WZsxKY0Pw5wmmaDuhs8 0ilLHK5yFYLOGERBrQWqD9v9VEHhqGW5fq1XyK83ge5awm0gY5s9nfh9DbP3jIWlfi Oqfz8Jt7zb4lQ== From: Jeff Layton <jlayton@kernel.org> To: Christian Brauner <brauner@kernel.org>, Namjae Jeon <linkinjeon@kernel.org>, Sungjong Seo <sj1557.seo@samsung.com> Cc: Al Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 12/92] exfat: convert to simple_rename_timestamp Date: Wed, 5 Jul 2023 15:00:37 -0400 Message-ID: <20230705190309.579783-10-jlayton@kernel.org> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230705190309.579783-1-jlayton@kernel.org> References: <20230705185755.579053-1-jlayton@kernel.org> <20230705190309.579783-1-jlayton@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770610904931507106?= X-GMAIL-MSGID: =?utf-8?q?1770610904931507106?= |
Series |
[v2,01/92] ibmvmc: update ctime in conjunction with mtime on write
|
|
Commit Message
Jeff Layton
July 5, 2023, 7 p.m. UTC
A rename potentially involves updating 4 different inode timestamps.
Convert to the new simple_rename_timestamp helper function.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/exfat/namei.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Comments
On Wed 05-07-23 15:00:37, Jeff Layton wrote: > A rename potentially involves updating 4 different inode timestamps. > Convert to the new simple_rename_timestamp helper function. > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > --- > fs/exfat/namei.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c > index d9b46fa36bff..e91022ff80ef 100644 > --- a/fs/exfat/namei.c > +++ b/fs/exfat/namei.c > @@ -1312,8 +1312,8 @@ static int exfat_rename(struct mnt_idmap *idmap, > goto unlock; > > inode_inc_iversion(new_dir); > - new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime = > - EXFAT_I(new_dir)->i_crtime = current_time(new_dir); > + simple_rename_timestamp(old_dir, old_dentry, new_dir, new_dentry); > + EXFAT_I(new_dir)->i_crtime = current_time(new_dir); Hum, you loose atime update with this. Not that it would make sense to have it but it would probably deserve a comment in the changelog. Also why you use current_time(new_dir) here instead of say inode->i_ctime? > exfat_truncate_atime(&new_dir->i_atime); > if (IS_DIRSYNC(new_dir)) > exfat_sync_inode(new_dir); > @@ -1336,7 +1336,6 @@ static int exfat_rename(struct mnt_idmap *idmap, > } > > inode_inc_iversion(old_dir); > - old_dir->i_ctime = old_dir->i_mtime = current_time(old_dir); > if (IS_DIRSYNC(old_dir)) > exfat_sync_inode(old_dir); > else Also there is: new_inode->i_ctime = EXFAT_I(new_inode)->i_crtime = current_time(new_inode); in exfat_rename() from which you can remove the ctime update? Honza
On Thu, 2023-07-06 at 12:39 +0200, Jan Kara wrote: > On Wed 05-07-23 15:00:37, Jeff Layton wrote: > > A rename potentially involves updating 4 different inode timestamps. > > Convert to the new simple_rename_timestamp helper function. > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > > --- > > fs/exfat/namei.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c > > index d9b46fa36bff..e91022ff80ef 100644 > > --- a/fs/exfat/namei.c > > +++ b/fs/exfat/namei.c > > @@ -1312,8 +1312,8 @@ static int exfat_rename(struct mnt_idmap *idmap, > > goto unlock; > > > > inode_inc_iversion(new_dir); > > - new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime = > > - EXFAT_I(new_dir)->i_crtime = current_time(new_dir); > > + simple_rename_timestamp(old_dir, old_dentry, new_dir, new_dentry); > > + EXFAT_I(new_dir)->i_crtime = current_time(new_dir); > > Hum, you loose atime update with this. Not that it would make sense to have > it but it would probably deserve a comment in the changelog. > > Also why you use current_time(new_dir) here instead of say inode->i_ctime? > I think the atime update there is a mistake. A rename is not a "read" operation. I'll note it in the changelog. The i_crtime in exfat is the creation time (aka btime). I don't think it matters much which source that ultimately comes from, but now I'm wondering why it gets set here at all. Does exfat create a new inode during a rename? If not, then the i_crtime updates here should probably be removed. > > exfat_truncate_atime(&new_dir->i_atime); > > if (IS_DIRSYNC(new_dir)) > > exfat_sync_inode(new_dir); > > @@ -1336,7 +1336,6 @@ static int exfat_rename(struct mnt_idmap *idmap, > > } > > > > inode_inc_iversion(old_dir); > > - old_dir->i_ctime = old_dir->i_mtime = current_time(old_dir); > > if (IS_DIRSYNC(old_dir)) > > exfat_sync_inode(old_dir); > > else > > Also there is: > > new_inode->i_ctime = EXFAT_I(new_inode)->i_crtime = > current_time(new_inode); > > in exfat_rename() from which you can remove the ctime update? > Yeah, that should be removed too. I'll fix that in my tree. The i_crtime update here looks pretty suspicious too, fwiw. Thanks!
diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c index d9b46fa36bff..e91022ff80ef 100644 --- a/fs/exfat/namei.c +++ b/fs/exfat/namei.c @@ -1312,8 +1312,8 @@ static int exfat_rename(struct mnt_idmap *idmap, goto unlock; inode_inc_iversion(new_dir); - new_dir->i_ctime = new_dir->i_mtime = new_dir->i_atime = - EXFAT_I(new_dir)->i_crtime = current_time(new_dir); + simple_rename_timestamp(old_dir, old_dentry, new_dir, new_dentry); + EXFAT_I(new_dir)->i_crtime = current_time(new_dir); exfat_truncate_atime(&new_dir->i_atime); if (IS_DIRSYNC(new_dir)) exfat_sync_inode(new_dir); @@ -1336,7 +1336,6 @@ static int exfat_rename(struct mnt_idmap *idmap, } inode_inc_iversion(old_dir); - old_dir->i_ctime = old_dir->i_mtime = current_time(old_dir); if (IS_DIRSYNC(old_dir)) exfat_sync_inode(old_dir); else