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 B5CF6C3064D for ; Tue, 2 Jul 2024 12:09:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C44E6B009A; Tue, 2 Jul 2024 08:09:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 474EE6B009D; Tue, 2 Jul 2024 08:09:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 315E26B009F; Tue, 2 Jul 2024 08:09:57 -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 0E0946B009A for ; Tue, 2 Jul 2024 08:09:57 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BBA851A2200 for ; Tue, 2 Jul 2024 12:09:56 +0000 (UTC) X-FDA: 82294693992.10.E851D09 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 4ECBA40017 for ; Tue, 2 Jul 2024 12:09:53 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZENpaXzx; spf=pass (imf07.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jlayton@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=1719922172; 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=8Brn84QoXwrd1aJBtQbCdp1Z6giOxAHgDkEPgnW4hPc=; b=v7RF2zS0q/HYg5u8RcwGzsjlvCN+Fw6l0A8+pbxy9J3Tas0frquhcTkuzIqGbaxTudau1Y lJvQOAdRm22WgFUgRFPsJw/4aupU6SxcHdDDwdifOPN54Qcc+QHZWZFTZflHkvEVdbeZgz C8lEmHhkxVIvc6ETpdku89cgFuE+Qf4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719922172; a=rsa-sha256; cv=none; b=6IF0ft2E3jD92j0T/7u6dLtu/105BsK7sag+OPrve6Q7X9eRuplHvMVYAuZRYaa4a+QDHr vi4gxkCaGzwt9W/XGSsCAMd/8I//Jptwr5P+Oo6F3+AUZfBmbDFPybzu5yRAxWmv1PaXMb hvoKwLGzylKwyNDQ6TziDS+gBoa2tjk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZENpaXzx; spf=pass (imf07.hostedemail.com: domain of jlayton@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 68F6FCE1673; Tue, 2 Jul 2024 12:09:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8EB95C116B1; Tue, 2 Jul 2024 12:09:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719922189; bh=8Brn84QoXwrd1aJBtQbCdp1Z6giOxAHgDkEPgnW4hPc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=ZENpaXzxDvd3J5U9Aqe8+r042fRCsO1KHdlbzIl01QG6pp9VVqz0qImYX65PDjFbc hjhYhVfNQzy1i79hScMb0RYJaFPyg8/vhug974+MNibgHN0aEHYXpZAXCtg5LQetG8 rZF/PasY3U04pKt8JiMWTvf/W2z41KijYx+fQ5GKdT1M0F70s/+sFXtwRjkn6X3J3M y5d33EtAecj6hqyyc/EV+sE2oydiSq3VLHsiEtRPIgeDFaKipAZyjqoQhqKIv3dcZJ lfXLJtgvJaUEl+m5+yAUKw1SCw2PB4X4Hksqc6fRC16YtihVMbVf+rRdo0chV5h6F7 XZLl/Vj1xxNew== Message-ID: <09ad82419eb78a2f81dda5dca9caae10663a2a19.camel@kernel.org> Subject: Re: [PATCH 01/10] fs: turn inode ctime fields into a single ktime_t From: Jeff Layton To: Christoph Hellwig Cc: Jan Kara , "Darrick J. Wong" , Alexander Viro , Christian Brauner , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Chandan Babu R , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Date: Tue, 02 Jul 2024 08:09:46 -0400 In-Reply-To: References: <20240626-mgtime-v1-0-a189352d0f8f@kernel.org> <20240626-mgtime-v1-1-a189352d0f8f@kernel.org> <20240701224941.GE612460@frogsfrogsfrogs> <3042db2f803fbc711575ec4f1c4a273912a50904.camel@kernel.org> <20240702101902.qcx73xgae2sqoso7@quack3> <958080f6de517cf9d0a1994e3ca500f23599ca33.camel@kernel.org> Autocrypt: addr=jlayton@kernel.org; prefer-encrypt=mutual; keydata=mQINBE6V0TwBEADXhJg7s8wFDwBMEvn0qyhAnzFLTOCHooMZyx7XO7dAiIhDSi7G1NPxwn8jdFUQMCR/GlpozMFlSFiZXiObE7sef9rTtM68ukUyZM4pJ9l0KjQNgDJ6Fr342Htkjxu/kFV1WvegyjnSsFt7EGoDjdKqr1TS9syJYFjagYtvWk/UfHlW09X+jOh4vYtfX7iYSx/NfqV3W1D7EDi0PqVT2h6v8i8YqsATFPwO4nuiTmL6I40ZofxVd+9wdRI4Db8yUNA4ZSP2nqLcLtFjClYRBoJvRWvsv4lm0OX6MYPtv76hka8lW4mnRmZqqx3UtfHX/hF/zH24Gj7A6sYKYLCU3YrI2Ogiu7/ksKcl7goQjpvtVYrOOI5VGLHge0awt7bhMCTM9KAfPc+xL/ZxAMVWd3NCk5SamL2cE99UWgtvNOIYU8m6EjTLhsj8snVluJH0/RcxEeFbnSaswVChNSGa7mXJrTR22lRL6ZPjdMgS2Km90haWPRc8Wolcz07Y2se0xpGVLEQcDEsvv5IMmeMe1/qLZ6NaVkNuL3WOXvxaVT9USW1+/SGipO2IpKJjeDZfehlB/kpfF24+RrK+seQfCBYyUE8QJpvTZyfUHNYldXlrjO6n5MdOempLqWpfOmcGkwnyNRBR46g/jf8KnPRwXs509yAqDB6sELZH+yWr9LQZEwARAQABtCBKZWZmIExheXRvbiA8amxheXRvbkBrZXJuZWwub3JnPokCOAQTAQIAIgUCWe8u6AIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQAA5oQRlWghUuCg/+Lb/xGxZD2Q1oJVAE37uW308UpVSD2tAMJUvFTdDbfe3zKlPDTuVsyNsALBGclPLagJ5ZTP+Vp2irAN9uwBuacBOTtmOdz4ZN2tdvNgozzuxp4CHBDVzAslUi2idy+xpsp47DWPxYFIRP3M8QG/aNW052L aPc0cedY xp8+9eiVUNpxF4SiU4i9JDfX/sn9XcfoVZIxMpCRE750zvJvcCUz9HojsrMQ1NFc7MFT1z3MOW2/RlzPcog7xvR5ENPH19ojRDCHqumUHRry+RF0lH00clzX/W8OrQJZtoBPXv9ahka/Vp7kEulcBJr1cH5Wz/WprhsIM7U9pse1f1gYy9YbXtWctUz8uvDR7shsQxAhX3qO7DilMtuGo1v97I/Kx4gXQ52syh/w6EBny71CZrOgD6kJwPVVAaM1LRC28muq91WCFhs/nzHozpbzcheyGtMUI2Ao4K6mnY+3zIuXPygZMFr9KXE6fF7HzKxKuZMJOaEZCiDOq0anx6FmOzs5E6Jqdpo/mtI8beK+BE7Va6ni7YrQlnT0i3vaTVMTiCThbqsB20VrbMjlhpf8lfK1XVNbRq/R7GZ9zHESlsa35ha60yd/j3pu5hT2xyy8krV8vGhHvnJ1XRMJBAB/UYb6FyC7S+mQZIQXVeAA+smfTT0tDrisj1U5x6ZB9b3nBg65ke5Ag0ETpXRPAEQAJkVmzCmF+IEenf9a2nZRXMluJohnfl2wCMmw5qNzyk0f+mYuTwTCpw7BE2H0yXk4ZfAuA+xdj14K0A1Dj52j/fKRuDqoNAhQe0b6ipo85Sz98G+XnmQOMeFVp5G1Z7r/QP/nus3mXvtFsu9lLSjMA0cam2NLDt7vx3l9kUYlQBhyIE7/DkKg+3fdqRg7qJoMHNcODtQY+n3hMyaVpplJ/l0DdQDbRSZi5AzDM3DWZEShhuP6/E2LN4O3xWnZukEiz688d1ppl7vBZO9wBql6Ft9Og74diZrTN6lXGGjEWRvO55h6ijMsLCLNDRAVehPhZvSlPldtUuvhZLAjdWpwmzbRIwgoQcO51aWeKthpcpj8feDdKdlVjvJO9fgFD5kqZQiErRVPpB7VzA/pYV5Mdy7GMbPjmO0IpoL0tVZ8JvUzUZXB3ErS/dJflvboAAQeLpLCk QjqZiQ/D CmgJCrBJst9Xc7YsKKS379Tc3GU33HNSpaOxs2NwfzoesyjKU+P35czvXWTtj7KVVSj3SgzzFk+gLx8y2Nvt9iESdZ1Ustv8tipDsGcvIZ43MQwqU9YbLg8k4V9ch+Mo8SE+C0jyZYDCE2ZGf3OztvtSYMsTnF6/luzVyej1AFVYjKHORzNoTwdHUeC+9/07GO0bMYTPXYvJ/vxBFm3oniXyhgb5FtABEBAAGJAh8EGAECAAkFAk6V0TwCGwwACgkQAA5oQRlWghXhZRAAyycZ2DDyXh2bMYvI8uHgCbeXfL3QCvcw2XoZTH2l2umPiTzrCsDJhgwZfG9BDyOHaYhPasd5qgrUBtjjUiNKjVM+Cx1DnieR0dZWafnqGv682avPblfi70XXr2juRE/fSZoZkyZhm+nsLuIcXTnzY4D572JGrpRMTpNpGmitBdh1l/9O7Fb64uLOtA5Qj5jcHHOjL0DZpjmFWYKlSAHmURHrE8M0qRryQXvlhoQxlJR4nvQrjOPMsqWD5F9mcRyowOzr8amasLv43w92rD2nHoBK6rbFE/qC7AAjABEsZq8+TQmueN0maIXUQu7TBzejsEbV0i29z+kkrjU2NmK5pcxgAtehVxpZJ14LqmN6E0suTtzjNT1eMoqOPrMSx+6vOCIuvJ/MVYnQgHhjtPPnU86mebTY5Loy9YfJAC2EVpxtcCbx2KiwErTndEyWL+GL53LuScUD7tW8vYbGIp4RlnUgPLbqpgssq2gwYO9m75FGuKuB2+2bCGajqalid5nzeq9v7cYLLRgArJfOIBWZrHy2m0C+pFu9DSuV6SNr2dvMQUv1V58h0FaSOxHVQnJdnoHn13g/CKKvyg2EMrMt/EfcXgvDwQbnG9we4xJiWOIOcsvrWcB6C6lWBDA+In7w7SXnnokkZWuOsJdJQdmwlWC5L5ln9xgfr/4mOY38B0U= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) MIME-Version: 1.0 X-Stat-Signature: ynn139e6zu5caj17wd85dbtiquxq7cei X-Rspamd-Queue-Id: 4ECBA40017 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719922193-87076 X-HE-Meta: U2FsdGVkX19nCbSq0nHV8VTeXEwOE0J38Jt2J342j3yHu7jcJ/HghB5rmX5GSf+eIb0xEvqpG2IEETzQ/uWujUkf/ICu7CbYkPf+Yu7F41Yd5P3iB4CQi2/Ge4tPuzbDDdwwk9H21NlKfD8YfyvrQ/O0yajpDjyLJeoj8/x2GWphn34Sp4sFqZmjAYEK7eGgqLDSUn2YAd+5xkvutzlDly93i6zL4N7zIhD5pcm2CL2UVPdSCC9CCX7hAZ4Yl9WfTNRvwB4XYGRxXwzZ6ol8ilH/YVvQ7ZFt5HWGnuK1K12F2VKso6aj9WKUNH9vFSK3zzjqVxrjL3Se/mLa/pQrfbd6gvQ4QaYGrnRqeMBp3Rgvenb6HOrHlK3+t/HdalPk1pOQLJczfMmh6chnWYHdrtR7LmDbNIDAKxWu3/f4U6bl1kAdbCz2JfiIooDONnAND07a7ukmDGQMNh+0043gKEyulIhrExHnAxTjlSKJQmU6U/y7DXuytZCbMwsyC2OAnwyI6TlutJKfbXVmC7jNEWiO0hbdHfggZM2/7m+JFIwwEacLiKxUyPUzr0sM3iA6zDzgxd1Jeh48Z+7Fcr3hNBYEGp8ifGQFS8cMhPG2Lo68DjMTNtOpnfv8+e0CbSqA3v1LxaIebPzERXEbsLJkJ31U92+hQ1w5FCOdg8bAnQVl0chzbMw66sg7QXYTtIG8cH0tn5kShQ59dD2uMDO3wNXUcxvnNpu3eVRe0wJ1BZjf+iT62M6xLyHeNUH+pO3utNRoTbiNO8kxz2CnT9cJ3QXtsZe3TZCQtNJn5IHdYz2nulQcmXD1o6Mp6ArEBh8nnnIfhohX99q8NJZD9SHV6T4vW+q8UkKCyxWv1nMZqlErEGfXlP8/vhIm8YLZWkegzJkDw+JMfF8+a2NvpaRb/RTYUPZrnVbTZnlt3KlP1ct7EvXZWtxJcwRJ0eQVSpcMk9dmxUr0Kbv0Qh7p8Ri mbgF3wRj aPY/bPvQ3KT22gMcfs/Awjjbr2Sqcpp3ZInWy0fsCxduV/3ANBuqZfoClSJwFZCCWmNbzk8emC2CNH7Sgons3pvGuPrUpkSIwSxkDHbioiYYQX3LneEr+Z35UbzKLwA0k7BtbvJaH+Gxk31epgrTTkrp2Fks2oLOjCgHabkujvUHxaYL5gMWuVWUHcqYwnLeCt78Et0a327r7r65pUqReTZBSChMkffYKYkkzeLe2Cy8VYtkTd34bVWK+NVMzttDFRc+eTZ4azxAByHtmzSwKkilkJ6du0C18yzdb 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: List-Subscribe: List-Unsubscribe: On Tue, 2024-07-02 at 05:04 -0700, Christoph Hellwig wrote: > On Tue, Jul 02, 2024 at 07:44:19AM -0400, Jeff Layton wrote: > > Complaining about it is fairly simple. We could just throw a pr_warn in > > inode_set_ctime_to_ts when the time comes back as KTIME_MAX. This might > > also be what we need to do for filesystems like NFS, where a future > > ctime on the server is not necessarily a problem for the client. > >=20 > > Refusing to load the inode on disk-based filesystems is harder, but is > > probably possible. There are ~90 calls to inode_set_ctime_to_ts in the > > kernel, so we'd need to vet the places that are loading times from disk > > images or the like and fix them to return errors in this situation. > >=20 > > Is warning acceptable, or do we really need to reject inodes that have > > corrupt timestamps like this? >=20 > inode_set_ctime_to_ts should return an error if things are out of range. Currently it just returns the timespec64 we're setting it to (which makes it easy to do several assignments), so we'd need to change its prototype to handle this case, and fix up the callers to recognize the error. Alternately it may be easier to just add in a test for when __i_ctime =3D=3D KTIME_MAX in the appropriate callers and have them error out. I'll have a look and see what makes sense. > How do we currently catch this when it comes from userland? >=20 Not sure I understand this question. ctime values should never come from userland. They should only ever come from the system clock. --=20 Jeff Layton