linux-ext4 - Re: [PATCH 3/5] ext4: for committing inode, make ext4_fc_track

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] [day] [month] [year] [list]

Message-ID: <20220309095248.v7kj3ss2kn6kva54@quack3.lan>
Date:   Wed, 9 Mar 2022 10:52:48 +0100
From:   Jan Kara <jack@...e.cz>
To:     harshad shirwadkar <harshadshirwadkar@...il.com>
Cc:     Jan Kara <jack@...e.cz>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Ritesh Harjani <riteshh@...ux.ibm.com>,
        "Theodore Y. Ts'o" <tytso@....edu>
Subject: Re: [PATCH 3/5] ext4: for committing inode, make ext4_fc_track_inode
 wait

On Tue 08-03-22 05:06:51, harshad shirwadkar wrote:
> On Tue, 8 Mar 2022 at 04:30, Jan Kara <jack@...e.cz> wrote:
> > > diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
> > > index 3477a16d08ae..7fa301b0a35a 100644
> > > --- a/fs/ext4/ext4_jbd2.c
> > > +++ b/fs/ext4/ext4_jbd2.c
> > > @@ -106,6 +106,18 @@ handle_t *__ext4_journal_start_sb(struct super_block *sb, unsigned int line,
> > >                                  GFP_NOFS, type, line);
> > >  }
> > >
> > > +handle_t *__ext4_journal_start(struct inode *inode, unsigned int line,
> > > +                               int type, int blocks, int rsv_blocks,
> > > +                               int revoke_creds)
> > > +{
> > > +     handle_t *handle = __ext4_journal_start_sb(inode->i_sb, line,
> > > +                                                type, blocks, rsv_blocks,
> > > +                                                revoke_creds);
> > > +     if (ext4_handle_valid(handle) && !IS_ERR(handle))
> > > +             ext4_fc_track_inode(handle, inode);
> >
> > Why do you need to call ext4_fc_track_inode() here? Calls in
> > ext4_map_blocks() and ext4_mark_iloc_dirty() should be enough, shouldn't
> > they?
> This is just a precautionary call. ext4_fc_track_inode is an
> idempotent function, so it doesn't matter if it gets called multiple
> times. This check just covers cases (such as the ones in inline.c)
> where ext4_reserve_inode_write() doesn't get called. I saw a few
> failures in the log group when I remove this call. The right way to
> fix this though is to ensure that ext4_reserve_inode_write() gets
> called before every inode update.

Oh, you mean like when updating inline data? I'm not sure
ext4_reserve_inode_write() is usable for all the places in inline.c but
yes, you probably need some sprinkling of ext4_fc_track_inode() there. That
would be definitely better than hacking it around in
__ext4_journal_start().

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR