lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9711e5f19dd2c040b4105147129a8db0aaf94b53.camel@kernel.org>
Date:   Wed, 05 Jul 2023 17:48:24 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Andreas Gruenbacher <agruenba@...hat.com>
Cc:     Christian Brauner <brauner@...nel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Brad Warrum <bwarrum@...ux.ibm.com>,
        Ritu Agarwal <rituagar@...ux.ibm.com>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ian Kent <raven@...maw.net>,
        "Tigran A. Aivazian" <aivazian.tigran@...il.com>,
        Jeremy Kerr <jk@...abs.org>, Ard Biesheuvel <ardb@...nel.org>,
        Namjae Jeon <linkinjeon@...nel.org>,
        Sungjong Seo <sj1557.seo@...sung.com>,
        Bob Peterson <rpeterso@...hat.com>,
        Steve French <sfrench@...ba.org>,
        Paulo Alcantara <pc@...guebit.com>,
        Ronnie Sahlberg <lsahlber@...hat.com>,
        Shyam Prasad N <sprasad@...rosoft.com>,
        Tom Talpey <tom@...pey.com>,
        John Johansen <john.johansen@...onical.com>,
        Paul Moore <paul@...l-moore.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Ruihan Li <lrh2000@....edu.cn>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Sebastian Reichel <sebastian.reichel@...labora.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        autofs@...r.kernel.org, linux-efi@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com,
        linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
        apparmor@...ts.ubuntu.com, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 7/9] gfs2: update ctime when quota is updated

On Wed, 2023-07-05 at 22:25 +0200, Andreas Gruenbacher wrote:
> On Mon, Jun 12, 2023 at 12:36 PM Jeff Layton <jlayton@...nel.org> wrote:
> > On Fri, 2023-06-09 at 18:44 +0200, Andreas Gruenbacher wrote:
> > > Jeff,
> > > 
> > > On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@...nel.org> wrote:
> > > > Signed-off-by: Jeff Layton <jlayton@...nel.org>
> > > > ---
> > > >  fs/gfs2/quota.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> > > > index 1ed17226d9ed..6d283e071b90 100644
> > > > --- a/fs/gfs2/quota.c
> > > > +++ b/fs/gfs2/quota.c
> > > > @@ -869,7 +869,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->i_atime = inode->i_ctime = current_time(inode);
> > > 
> > > I don't think we need to worry about the ctime of the quota inode as
> > > that inode is internal to the filesystem only.
> > > 
> > 
> > Thanks Andreas.  I'll plan to drop this patch from the series for now.
> > 
> > Does updating the mtime and atime here serve any purpose, or should
> > those also be removed? If you plan to keep the a/mtime updates then I'd
> > still suggest updating the ctime for consistency's sake. It shouldn't
> > cost anything extra to do so since you're dirtying the inode below
> > anyway.
> 
> Yes, good point actually, we should keep things consistent for simplicity.
> 
> Would you add this back in if you do another posting?
> 

I just re-posted the other patches in this as part of the ctime accessor
conversion. If I post again though, I can resurrect the gfs2 patch. If
not, we can do a follow-on fix later.

Since we're discussing it, it may be more correct to remove the atime
update there. gfs2_adjust_quota sounds like a "modify" operation, not a
"read", so I don't see a reason to update the atime.

In general, the only time you only want to set the atime, ctime and
mtime in lockstep is when the inode is brand new.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ