Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp8977082ybc; Fri, 29 Nov 2019 21:35:54 -0800 (PST) X-Google-Smtp-Source: APXvYqwERq1gI0kQUoB94ST5hOi0fOslZv1ZI/Isnr8O2+rlFPUATcPLtyCY9c1btLkdHfSgL9Ci X-Received: by 2002:a17:906:5351:: with SMTP id j17mr24877706ejo.66.1575092154587; Fri, 29 Nov 2019 21:35:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575092154; cv=none; d=google.com; s=arc-20160816; b=FO6B4BlerKYn2NhqM01TDBxzd14eIMkbdtb4AW0C921KteTZxR9hvtyOM8CfXDRzTu q7w2vN4QyU3ucsH6yR10jPLwrk9HTuKJm/btPkE8+59uEjivB1ZjcJe7S/mcNrAXMZhu V/7/bDn1BA6eiC+LKYPNKA1EkkLDGhhHFamKcYUTWfMePTdX7hx6uzl42ZismCMvZlpw lRWrbUiXnZnqZZhEjDguTCb8TV7bAWQq70lm3FeelkA9O/LA1IHc+ml/o91wPCwjG1vP YvuMGdkMnhRYwCIwwXav3YjMbQ532sBJZfYIGpKWSCVeOjGhNGt/galLAIFU1XlR5xWJ UxXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=expuErTDLV7kYKDvwrUyVz/OvBmHSSvA+J1XVJvaACE=; b=QdF4da66+95T15tcORbZ2aqmugDqKpE5eMTktt1qFZSk5VpYQh5O1/57vecchDWl4J Y+MWT3d9y6+PoPFzBAe3OBScA67jbUyamW6Mu/1X6DyWP5otYMmF5WmqoBfXkPgC9IIQ Qdkv2tlGbZl2lgHkxRxMrM0ZRxzOXuvx7SgUv9OL79lQFRxbl0aeTWo0VmmVL7iMvSEW q/K42t898w9nGCx4VlZ/FYT50Jow0plJ3GxV9fMTjuFiR2K/0pL3Y8W0CgdorqUri0ee 6CLz55j41SrKLM5Jbe53LLyGKxUBSAOyZUKsofXKrh8sWNp6WCfbrcE8u3XvRH+hDqTy SX9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="C7nZIyE/"; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v13si8684015edl.174.2019.11.29.21.35.16; Fri, 29 Nov 2019 21:35:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="C7nZIyE/"; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725783AbfK3Fer (ORCPT + 99 others); Sat, 30 Nov 2019 00:34:47 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:34543 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725298AbfK3Feq (ORCPT ); Sat, 30 Nov 2019 00:34:46 -0500 Received: by mail-io1-f67.google.com with SMTP id z193so34548974iof.1; Fri, 29 Nov 2019 21:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=expuErTDLV7kYKDvwrUyVz/OvBmHSSvA+J1XVJvaACE=; b=C7nZIyE/OPXd5iYmWUU4RNdRFFn278tbUtXnJULGNurVvBQhznWYArkSIiIXCxYuXk fDhvb6flf+FFTkOGH09YcqzPqFykRr6cmIssudxauJ+HefllAjjDv/V7jnGF5AGCweHw YzWpA0QhiPtQFwdSURfDNzE3hRMPfWxxiz+pzdlvDdymck02YwLRd5KbWudj9AajmIud ER/ayWvQluoy1ZpKzNwQy9jgIIpXL99YGg5eucxc2PhotAFTXm6868okFz8Qv7fvxfa0 VDOmUliJ2OFro/vMim7NOY2R5c7UtHT9iUKZy+gU+33vSCxHP2jswpV31EownMfDi9PI XWRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=expuErTDLV7kYKDvwrUyVz/OvBmHSSvA+J1XVJvaACE=; b=ZNYXjZQeB4vIZcs356HwdOl1Ag/FAh42bxID7IkQ1HUKDpKXF6VC85cv17Qg/h3dTI Et5c/Ny0ToHH08eDAM20Ee2fiGPQFT8z3CMsizUTcZ6A8e/5qVyEoBTfUThCUcJCtfdt hopSOJWN/hT23WWeAtaGwMTIbAscOPiBila9EqkaCSnwqUCYopWcPbrtBkRoO6qy+yjq NFrYgvzCMPIe27S9uMh30eHv9GaSrjIPXx7s4j7yfixVlKWeCfn+0u52iR2fkgVI8Amy G+431k6VN+8Mt+as/29bGpJwPaMfzoc6yj8KT27st+kFgtsKB3Z4hhvbfqnOeyFjN1SP Tvcw== X-Gm-Message-State: APjAAAUBDT63UR4xDe5ynTHRb+TSN6bWfrKJR+S9v0M6VG1QSHaumA8y SukTVfn0AE3iSvEd30Gcn+1olvdpdD0KGJw3p4hJM6mx X-Received: by 2002:a02:9307:: with SMTP id d7mr4360196jah.103.1575092086087; Fri, 29 Nov 2019 21:34:46 -0800 (PST) MIME-Version: 1.0 References: <20191124193145.22945-1-amir73il@gmail.com> <20191124194934.GB4203@ZenIV.linux.org.uk> <20191124213415.GD4203@ZenIV.linux.org.uk> In-Reply-To: <20191124213415.GD4203@ZenIV.linux.org.uk> From: Deepa Dinamani Date: Fri, 29 Nov 2019 21:34:35 -0800 Message-ID: Subject: Re: [PATCH] utimes: Clamp the timestamps in notify_change() To: Al Viro Cc: Amir Goldstein , Arnd Bergmann , Jeff Layton , "J . Bruce Fields" , Miklos Szeredi , Linux FS-devel Mailing List , overlayfs , Linux NFS Mailing List , y2038 Mailman List Content-Type: text/plain; charset="UTF-8" Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Sun, Nov 24, 2019 at 1:34 PM Al Viro wrote: > > On Sun, Nov 24, 2019 at 01:13:50PM -0800, Deepa Dinamani wrote: > > > We also want to replace all uses of timespec64_trunc() with > > timestamp_truncate() for all fs cases. > > > > In that case we have a few more: > > > > fs/ceph/mds_client.c: req->r_stamp = timespec64_trunc(ts, > > mdsc->fsc->sb->s_time_gran); > > Umm... That comes from ktime_get_coarse_real_ts64(&ts); > > > fs/cifs/inode.c: fattr->cf_mtime = > > timespec64_trunc(fattr->cf_mtime, sb->s_time_gran); > ktime_get_real_ts64(&fattr->cf_mtime) here > > > fs/cifs/inode.c: fattr->cf_atime = > > timespec64_trunc(fattr->cf_atime, sb->s_time_gran); > ditto > > > fs/fat/misc.c: inode->i_ctime = > > timespec64_trunc(*now, 10000000); > > I wonder... some are from setattr, some (with NULL passed to fat_truncate_time()) > from current_time()... Wouldn't it make more sense to move the truncation into > the few callers that really need it (if any)? Quite a few of those are *also* > getting the value from current_time(), after all. fat_fill_inode() looks like > the only case that doesn't fall into these classes; does it need truncation? I've posted a series at https://lore.kernel.org/lkml/20191130053030.7868-1-deepa.kernel@gmail.com/ I was able to get rid of all instances but it seemed like it would be easier for cifs to use timestamp_truncate() directly. If you really don't want it exported, I could find some other way of doing it. > BTW, could we *please* do something about fs/inode.c:update_time()? I mean, > sure, local variable shadows file-scope function, so it's legitimate C, but > this is not IOCCC and having a function called 'update_time' end with > return update_time(inode, time, flags); > is actively hostile towards casual readers... Added this to the series as well. -Deepa