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 E91DCC30658 for ; Tue, 2 Jul 2024 12:21:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71AF16B0099; Tue, 2 Jul 2024 08:21:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CAF06B009D; Tue, 2 Jul 2024 08:21:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56B426B009F; Tue, 2 Jul 2024 08:21:50 -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 399826B0099 for ; Tue, 2 Jul 2024 08:21:50 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0E5CA141DE3 for ; Tue, 2 Jul 2024 12:21:49 +0000 (UTC) X-FDA: 82294723938.20.2BBAC90 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id 3C81E160021 for ; Tue, 2 Jul 2024 12:21:47 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MKLHYwhq; spf=pass (imf08.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 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=1719922895; 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=dlV/fAhfUmr253nJj9tCh33V0pYp49DfCChR4aJuxtc=; b=gfbqnUNhJDptewPQxv8valQO2oyDkMPzdxNN8KtptZY0DiZqa7astGZYcD4aaiGx5wGKX3 QGvULyvGN6INBhs4PZ1rO0x2o5aS5oPZi4eBcrKioHOj5TInrImTa283vGfSWOZ+xLCkHP 20rsPDx8dRtbMc4z20L7ybwNS2+USoU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MKLHYwhq; spf=pass (imf08.hostedemail.com: domain of jlayton@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719922895; a=rsa-sha256; cv=none; b=dRMbcs4yg1OZZx+1n/3gpJM6yKjOelYV0de9Iuz8wrLxKlSJ3FyWU94vWAUj1QQXoLv7gP vTlTWnKGKWOxtT6k/NPoS9YWqjjlZ0S+rIeQAj4GE9yLhQMZU7swk0+OmRCT+m8zJTPTwX rK4WZ2wFdC1TDuPijb/hJ1BlLicgz38= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3335661B41; Tue, 2 Jul 2024 12:21:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCA9DC116B1; Tue, 2 Jul 2024 12:21:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719922905; bh=dlV/fAhfUmr253nJj9tCh33V0pYp49DfCChR4aJuxtc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=MKLHYwhqixRE7NHHs+pKxnm2xM07FMEaKMpowL4BHrzYKeiJGQ7PFBYCjClgpBiI/ we8VYRV0kw10lMI7sISoJjvqh7TSpE0w5fQwI65uVz+DpmLUJKtU+bGfGyO8HoB8eu Q8xb14PfG29iDlbp7LbI8xzwGi7+RKZCngmMkIGhB/AXczJwUSFqC12fOCN19uDNgk 2/FfGop4RJTAY50Ssa2AsKoITX+awTNKshF8e1eRiatSXT2u9Jpebr5sWW5NWWeb0p RrA1mYttC4C2Ko6NBkhrN8WxRoQ5hUBL0djKrLRVIJ6rvTVQgB0mT2vP/X91Mj1fZv GzC10zOs4nEpg== Message-ID: 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:21:42 -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> <09ad82419eb78a2f81dda5dca9caae10663a2a19.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-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 3C81E160021 X-Stat-Signature: do1snksymc9sspsgaeihe535788co5ur X-Rspam-User: X-HE-Tag: 1719922907-399478 X-HE-Meta: U2FsdGVkX1+Kzzk3BtqHzZp1TbW7ArdvWJU8+SBezwvCj8vrVQQiCHhL+k+TClwznmslxKEzaoKIRVg2PLk+XPJyVr7GJAEu73RnDVqAw3xwLdaffNWm1lnQQk7JQ4Dx/5gVx+iO9iNZC+Dmgihh64P+YZiQHFBysCUyNbt5CKB8BJUsFzwTHgpJFzHJO/JEnGaTKBhRMRGCYhF73yGqbCfIqcaHg6Qk5flzdZqDyvoZRSbssEYf0fmuiubslLJybnG0oh107AiVTSQdpJ8NICqGSWBa9cfnJceWWbT0+ZMF6GPsH+nE0nDEm9qasYA3JktSGP1lloaqXMLWGI3v6+lGEp0/TJFQsvrKIA7WgMHG1pSHjTn3hFJDznxFhSf2VbOybODrnrEiJnbP6A0jch06xGGTI8WEdBEDoAIufFJHaTWfEG+0iywFhcFqC6kYns/jDTyrELttgGNvIVurCZgP9uWmAO1WKEo4GteoFwXVEuUEQErBS4AEJP/xNPVq5VJvgjye4Kx45MGjpC2T5d2jfiwrAwPVv0PGKY13q/Vgf24E0i0czJl2vnACAVXrOJUVphCqF4cOsCsL0/fVrbPL/2js5d/HVJPz2Ux5mvz+PFLqqQrTVdPdvErM6u4FylQVm4P1rp6RULQd3rM+V03CBsbSEH8wm+V1TAwUnRWV+97qV/Bc/qI8TCngMbiwZhyFrykZ5uMadh5kv1NLsVPcQ9VrqY4yDpWCnapCCRpr9eVVuRJPURMD6GcWx1v0kOL5gW91dm4ttyKPJbHwkbzD60aVnjrHDncBsfTcUxL9nOh1BS3f43Z5bs9diyG7lr9PDNg/V7qyKXT4QztcfaVmezvqtLP1AeYc3qCcU36pb+lu5PY+VI3M7ohMIIToAP9zcaeTKTFIPE6jJdncslDX/QqyroIbiGEzL/kU8ToAb+7HfrRl7RoOOV9pG+XqzHoMVHHyqTqEumaraOe lamtlPFN TthKyQCjQN56B8F42etNZzsFBb6PDdMD1SjWxkVt3LLa7MMbw3qwmdgrVOnuabwns6iHAYyN5aunm7oos9CmL00jtb7P1/7oC/R+xQwaBlXfmZQOE/McGz6/RNVZzt98QRnlcSvg4/RLHSSTYxOLy2S72ODmnwFcCiNjVbCClwPR39gtyEu2wemBPLMqNj4K25FoFyCtJ0TwwVwRc6+HSJoRFeJWjsQDEAgNK7GTK40Idpljq9Q4a53hltgjzz1ZE9qzqXQigHCUmlN4pKHNz7K61NhMULt+Y6xbvnDvTVg9h3MY= 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:15 -0700, Christoph Hellwig wrote: > On Tue, Jul 02, 2024 at 08:09:46AM -0400, Jeff Layton wrote: > > > > corrupt timestamps like this? > > >=20 > > > inode_set_ctime_to_ts should return an error if things are out of > > > range. > >=20 > > 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. > >=20 > > 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. >=20 > The seems like a more awkward interface vs one that explicitly > checks. >=20 Many of the existing callers of inode_ctime_to_ts are in void return functions. They're just copying data from an internal representation to struct inode and assume it always succeeds. For those we'll probably have to catch bad ctime values earlier. So, I think I'll probably have to roll bespoke error handling in all of the relevant filesystems if we go this route. There are also differences between filesystems -- does it make sense to refuse to load an inode with a bogus ctime on NFS or AFS? Probably not. Hell, it may be simpler to just ditch this patch and reimplement mgtimes using the nanosecond fields like the earlier versions did. I'll need to study this a bit and figure out what's best. > >=20 > > > How do we currently catch this when it comes from userland? > > >=20 > >=20 > > Not sure I understand this question. ctime values should never come > > from userland. They should only ever come from the system clock. >=20 > Ah, yes, utimes only changes mtime. Yep. That's the main reason I see the ctime as very different from the atime or mtime. --=20 Jeff Layton