Message ID | 20230713135249.153796-1-jlayton@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp1856798vqm; Thu, 13 Jul 2023 07:17:35 -0700 (PDT) X-Google-Smtp-Source: APBJJlEz9F8Fe8K5/iYfcrPE6+17zUEB7fEtDyzwhSDpCMfq5feEBCGNZQr9eluqGr56PDaHjQeR X-Received: by 2002:a05:6512:20c8:b0:4f9:a232:f09c with SMTP id u8-20020a05651220c800b004f9a232f09cmr1326533lfr.63.1689257855139; Thu, 13 Jul 2023 07:17:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689257855; cv=none; d=google.com; s=arc-20160816; b=W/ohNpxGQEb9Os1O8C6K1ZZblsYoeF0sp/ec3Yt8UP0rHTRPioM14gTslsc0JOl+/3 XOUzBsbW3fnko2XZcF7iUBepRxwzFj12veZC/2cvauZ9pe7wP9/CDMEuLe96SXuKJg3k lXgLnJz3tF2aIZhTzJcZJYN8EejBTiZol6xYaco2Y29GPvHXyqgHMdIR5NjoilFGABLa O72Tv7nbKJxJDdBqzmj2ev1aotSYSwGiPsKvFkVvVYJOp3nS1Zl+07mTKW7aErwEBWFy 7WcnooJoEEhia/HtO0ifLGM/cdCGUL3Y1n0HufDlKOy924cfFxhyO3/qqKSr51nBDN1O zY/Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=RXh8cTREYz3J5/c2S9REAu+l8nf3umaty+DieH9Rq2c=; fh=dI8uQi+sT/ovD/KocURm17MaCUGVWccEVekl7SUdgr4=; b=SJFIxP2CPn+p6MgWKfDIHro3tQrrrAbOA7PmEryjT3BjLDWbeXkYEMtOrw76p3K62l FDPf/B5FFv+KCQ5Stwj74agLJW0MSuWT+Rq1jji1ZjGFLpCz/1uP5fGv8jGTByyRBerY +6Tq3Bj9vTrs3fpTR2KiWbvTF55jG5lv7UboyDDH4VEUHj7xPvu8yst8tqpaTA/Bb6Td 1nZOe5/19G4s4KDA3RZqd7znyi29mEFWcVLtQ5bc//WJBBUVPBl3B9Jxz3V1k9+0HPaB CA3jUCfVYmPOLC+p9T4ns8GGlLr1KvHjKwWOTLC3W430EIIFiBeyn4fe7hoyJjUvg6Sq /NNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mTynh6tF; 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 t27-20020a1709063e5b00b0098f99532db4si7074161eji.664.2023.07.13.07.17.09; Thu, 13 Jul 2023 07:17:35 -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=mTynh6tF; 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 S230174AbjGMNwy (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Thu, 13 Jul 2023 09:52:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230055AbjGMNwx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Jul 2023 09:52:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B8831992; Thu, 13 Jul 2023 06:52:52 -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 0187F612E6; Thu, 13 Jul 2023 13:52:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3534C433C8; Thu, 13 Jul 2023 13:52:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689256371; bh=yQE/06XtN9J0/9x5jyBU+rANpjW1fPpTd29gKkhEkO4=; h=From:To:Cc:Subject:Date:From; b=mTynh6tFaqDyWig0CZnR9oUbpU1b4pvoLSwLuRSd2dGG8NF7GucdHnkvBfErhpO27 BMqrS5fa25Y/XKs+tTD3vVjLWCYzR4LsUfJgMZehWtiZuCuVs3pecG8uRujZMAuyl6 xqh9TE5V+KnJNWKop6hnKA/IqoI55QAYzlRsb+VNG02UNFYUp2j0ADgkH37uc71IEi f1wQ6t//knMMsD6Yy7zUh4jhAmMhNIiar4Ge5yH3VhvkdmekfvMYzu8VKjrGDHzI9p SRKi/GX4BQGvQuATVDVprXwYxsjqBN5NyCSe3PX1fIL9Zlf4IHRCeDBjYtu3cQ2ANs 6jr5cHk2W92Iw== From: Jeff Layton <jlayton@kernel.org> To: brauner@kernel.org, Bob Peterson <rpeterso@redhat.com>, Andreas Gruenbacher <agruenba@redhat.com> Cc: linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-kernel@vger.kernel.org Subject: [PATCH] gfs2: fix timestamp handling on quota inodes Date: Thu, 13 Jul 2023 09:52:48 -0400 Message-ID: <20230713135249.153796-1-jlayton@kernel.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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: INBOX X-GMAIL-THRID: 1771315244707649601 X-GMAIL-MSGID: 1771315244707649601 |
Series |
gfs2: fix timestamp handling on quota inodes
|
|
Commit Message
Jeff Layton
July 13, 2023, 1:52 p.m. UTC
While these aren't generally visible from userland, it's best to be
consistent with timestamp handling. When adjusting the quota, update the
mtime and ctime like we would with a write operation on any other inode,
and avoid updating the atime which should only be done for reads.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
fs/gfs2/quota.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Christian,
Would you mind picking this into the vfs.ctime branch, assuming the GFS2
maintainers ack it? Andreas and I had discussed this privately, and I
think it makes sense as part of that series.
Thanks,
Jeff
Comments
On Thu, Jul 13, 2023 at 09:52:48AM -0400, Jeff Layton wrote: > While these aren't generally visible from userland, it's best to be > consistent with timestamp handling. When adjusting the quota, update the > mtime and ctime like we would with a write operation on any other inode, > and avoid updating the atime which should only be done for reads. > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > --- > fs/gfs2/quota.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Christian, > > Would you mind picking this into the vfs.ctime branch, assuming the GFS2 > maintainers ack it? Andreas and I had discussed this privately, and I Happy to!
Jeff and Christian, On Thu, Jul 13, 2023 at 3:52 PM Jeff Layton <jlayton@kernel.org> wrote: > While these aren't generally visible from userland, it's best to be > consistent with timestamp handling. When adjusting the quota, update the > mtime and ctime like we would with a write operation on any other inode, > and avoid updating the atime which should only be done for reads. > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > --- > fs/gfs2/quota.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Christian, > > Would you mind picking this into the vfs.ctime branch, assuming the GFS2 > maintainers ack it? Andreas and I had discussed this privately, and I > think it makes sense as part of that series. Yes, please. > Thanks, > Jeff > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > index 704192b73605..aa5fd06d47bc 100644 > --- a/fs/gfs2/quota.c > +++ b/fs/gfs2/quota.c > @@ -871,7 +871,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > size = loc + sizeof(struct gfs2_quota); > if (size > inode->i_size) > i_size_write(inode, size); > - inode->i_mtime = inode->i_atime = current_time(inode); > + inode->i_mtime = inode_set_ctime_current(inode); > mark_inode_dirty(inode); > set_bit(QDF_REFRESH, &qd->qd_flags); > } > -- > 2.41.0 > Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com> Thanks, Andreas
On Thu, 13 Jul 2023 09:52:48 -0400, Jeff Layton wrote: > While these aren't generally visible from userland, it's best to be > consistent with timestamp handling. When adjusting the quota, update the > mtime and ctime like we would with a write operation on any other inode, > and avoid updating the atime which should only be done for reads. > > Applied to the vfs.ctime branch of the vfs/vfs.git tree. Patches in the vfs.ctime branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.ctime [1/1] gfs2: fix timestamp handling on quota inodes https://git.kernel.org/vfs/vfs/c/ea462c3f7f48
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c index 704192b73605..aa5fd06d47bc 100644 --- a/fs/gfs2/quota.c +++ b/fs/gfs2/quota.c @@ -871,7 +871,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, size = loc + sizeof(struct gfs2_quota); if (size > inode->i_size) i_size_write(inode, size); - inode->i_mtime = inode->i_atime = current_time(inode); + inode->i_mtime = inode_set_ctime_current(inode); mark_inode_dirty(inode); set_bit(QDF_REFRESH, &qd->qd_flags); }