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 E76D7EE7FE0 for ; Fri, 8 Sep 2023 12:10:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 015BB6B00B6; Fri, 8 Sep 2023 08:10:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F06F06B00B7; Fri, 8 Sep 2023 08:10:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA6D06B00B8; Fri, 8 Sep 2023 08:10:20 -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 C743C6B00B6 for ; Fri, 8 Sep 2023 08:10:20 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9C5041A03CA for ; Fri, 8 Sep 2023 12:10:20 +0000 (UTC) X-FDA: 81213312600.08.ACF612D Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf28.hostedemail.com (Postfix) with ESMTP id 8D109C000C for ; Fri, 8 Sep 2023 12:10:18 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ffcypC1C; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=kBww0jG4; spf=pass (imf28.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694175018; 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=XyAJOe4IIc4u4PsIgJoECbVObRSruBJdgdnnkoMkWpc=; b=2kIZN9i8YFLLNofvHQZrLxFtWETj0RoZvEfVrlYIHXt0CkcBCPazBmiYqJs6Q3z/F72xi9 sRfMSUrILOlfjje1ytkSN1J9kvJ3eSQ/HxtFI7d4sxuSuFm1tXawNo97oVKLWutQpSsVeY kMmgdjR8qaOqqXgg0dIZs+Wx66QMnuY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=ffcypC1C; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=kBww0jG4; spf=pass (imf28.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694175018; a=rsa-sha256; cv=none; b=M4+zZzArC4Qn/IJSRk65U1ob0vHACuhxZ61KaH0/3bj6mP6pBOhTVNoOgcEjgcW2mbQys2 hKrlEOr9kEfXJqgK/h+DVQ/t7Eed/P0kxUQHnvyl39oWENodIFtwTt+D28juAKOJrM+w7k jdhxZ+6dPhoX04jpaV3hPD/jwmYmK90= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 2A5621FE19; Fri, 8 Sep 2023 12:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1694175016; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XyAJOe4IIc4u4PsIgJoECbVObRSruBJdgdnnkoMkWpc=; b=ffcypC1C+MqUG8/Hn5L3CMDJzLEBNb9hCp2fG6HfXPJ4yJmXUmT08ZYq0yBtf+N43GV8ph /c8aD84SlH7XveWi5DVNXy71HqnrBZThe+iunyHnwnNF+8rqPXSfrVu9ezRq5Y1SaLL8bK 0Kk44lT3LlCNk/ufrQip3EF2y4zXW+g= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1694175016; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XyAJOe4IIc4u4PsIgJoECbVObRSruBJdgdnnkoMkWpc=; b=kBww0jG4zHOMXYIuFz6j4ucOkxulX/N1eGfJWY4Kij3JJQXPOKxOt1my+3UekQpk2gUmBF sR1dRImfMA5TjSDA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 18E65132F2; Fri, 8 Sep 2023 12:10:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id H/MNBigP+2SDMAAAMHmgww (envelope-from ); Fri, 08 Sep 2023 12:10:16 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 806FBA0774; Fri, 8 Sep 2023 14:10:15 +0200 (CEST) Date: Fri, 8 Sep 2023 14:10:15 +0200 From: Jan Kara To: Jeff Layton Cc: Jan Kara , Alexander Viro , Christian Brauner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel test robot Subject: Re: [PATCH 1/2] fs: initialize inode->__i_ctime to the epoch Message-ID: <20230908121015.k2xmkbiw7dljj24g@quack3> References: <20230907-ctime-fixes-v1-0-3b74c970d934@kernel.org> <20230907-ctime-fixes-v1-1-3b74c970d934@kernel.org> <20230908104229.5tsr2sn7oyfy53ih@quack3> <0716e97eadc834ac4be97af5d6bbab82c5dc4ac9.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0716e97eadc834ac4be97af5d6bbab82c5dc4ac9.camel@kernel.org> X-Rspamd-Queue-Id: 8D109C000C X-Rspam-User: X-Stat-Signature: zawzz8xi84d37f8h7cpo5cmdotr8hdcy X-Rspamd-Server: rspam01 X-HE-Tag: 1694175018-263451 X-HE-Meta: U2FsdGVkX1/UYAMo9pclJQoqMeV8ZVj0yH1w+YAdI+msmLyqH+3HNlEE+0C8ZUjvBlUynPessQTo2lDATDjKQHw80tAVnI8rJslEM0F9OhyCrj0wwxIwMZPfCoUNO/lU2VKeftqiicImVllTIcE8hIWSKqqSMdaJIf7aEjD/KDFRdd4OoH0yDUL03y2gcuZ6vltEMSvljAHHhrm0MYceDKcAS++SFs7SYtoLUxSl8UkqWM4m9YHZ9ok5FRUhaChTSVt6uDKVwIXWy73kUc1+X8GYUmaRTJzQ+38UDSxlBU31rDeIbin91RT2sSSlcpq7rHGfK6aiERAi8d5XOmAZ2PL+5qZuq5h2jFyhNUaNX/SIUlL+X2aBmFzegSTviBSBNY047v2WAK2tX+b346eZ1rCo6VPcXi73lQ7rY0rrS5Y8k3TjlKg+JWY6q4tpQ0U9/FA5ZCV5iyl38Etv/+EjnrwTZYaAh1lFxVMQpR/h02tXk6UtynmTEyniU0kcxxWyghP/zSAOiNwgAGYTmvrcT0ukV+Osb78Gq+4J2nr8aoWN1w50HpboCgYfaCzL16q3nP3qZjZUOdgb/bdtFpKQATLAEoeybfisXdNLKZeaYuKxTH7atmyzmO01u5fxmn58sNPC9jELplk00zlEWKBjFGhJOxBGLsscw2qRONEvigPkTCbu/UQlBsgf4jxjkFTUDJfNkadbnoebM8Tj8ogFW+eYWxoCo5NVD8JQKLPsIHPxRnZPHf+hN/rZBAinKqMQBZBMD3UYZcW/PIgdVO2mYLrFxwfnIvf92WcCHpm3FKyfDa+T3p1NzzM05Xvq0SkL+h4tj/rbEN20KOF/ZDNjpQeE6fGI8FINwJVSJzgleU66z7WKHneXXM/cjVAY1o9F/7BkeZpH09gzhxrokcpFGGgLAaHvhNyZ+EexY60rfISqZiF9gAX2ytti6iwkLvcre08uV3ks5guX26JhyKQ ArBoipW6 770DiHrdXHEWA4/FnYAwT+YrBCF62lDus6B/x6Gs/qmNL/Q8n6HL2lTHQbwS9OzVqKtW46hquKG/OwG2bhLw7a6QLOs5RNnvbs72DvggPEgEGZxwAiMDQdRaCvh7ug/Y2LrBKjSE7SbJMsWffxd0IhzivPqUm5Lg8vq0reBt6TsWGPxdiyRnu8YDzF1vLX7JsxreX4ea6kOuKNt2514O4R2OXnfeguCjPc1EwCsrgiAJp4T3xV7bJkUleWj4ohVykez+3AjcdW5LRFc/hFAU8cpYLZKsPw8Gl45TNx7/u8lllH4a8tI8WUCiYqUSe4xNPu7RWGRKTMH7FHnvBqnLHwlO2lJSYQvrziafflYmaU01LKXLdjAcCw4nuqF//Wgt2dFD+ 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 08-09-23 07:41:45, Jeff Layton wrote: > On Fri, 2023-09-08 at 12:42 +0200, Jan Kara wrote: > > On Thu 07-09-23 12:33:47, Jeff Layton wrote: > > > With the advent of multigrain timestamps, we use inode_set_ctime_current > > > to set the ctime, which can skip updating if the existing ctime appears > > > to be in the future. Because we don't initialize this field at > > > allocation time, that could prevent the ctime from being initialized > > > properly when the inode is instantiated. > > > > > > Always initialize the ctime field to the epoch so that the filesystem > > > can set the timestamps properly later. > > > > > > Reported-by: kernel test robot > > > Closes: https://lore.kernel.org/oe-lkp/202309071017.a64aca5e-oliver.sang@intel.com > > > Signed-off-by: Jeff Layton > > > > Looks good but don't you need the same treatment to atime after your patch > > 2/2? > > > > > > I don't think so. Most filesystems are doing something along the lines > of this when allocating a new inode: > > inode->i_atime = inode->i_mtime = inode_set_ctime_current(inode); > > ...and I think they pretty much all have to initialize i_atime properly, > since someone could stat the inode before an atime update occurs. Ah, right. Feel free to add: Reviewed-by: Jan Kara Honza > > > --- > > > fs/inode.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/fs/inode.c b/fs/inode.c > > > index 35fd688168c5..54237f4242ff 100644 > > > --- a/fs/inode.c > > > +++ b/fs/inode.c > > > @@ -168,6 +168,8 @@ int inode_init_always(struct super_block *sb, struct inode *inode) > > > inode->i_fop = &no_open_fops; > > > inode->i_ino = 0; > > > inode->__i_nlink = 1; > > > + inode->__i_ctime.tv_sec = 0; > > > + inode->__i_ctime.tv_nsec = 0; > > > inode->i_opflags = 0; > > > if (sb->s_xattr) > > > inode->i_opflags |= IOP_XATTR; > > > > > > -- > > > 2.41.0 > > > > > -- > Jeff Layton -- Jan Kara SUSE Labs, CR