linux-ext4 - Re: [PATCH] ext4: remove unnecessary ext4_inode_datasync

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211109045010.GG418105@dread.disaster.area>
Date:   Tue, 9 Nov 2021 15:50:10 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Zhongwei Cai <sunrise_l@...u.edu.cn>
Cc:     tytso@....edu, adilger.kernel@...ger.ca,
        linux-ext4@...r.kernel.org, mingkaidong@...il.com
Subject: Re: [PATCH] ext4: remove unnecessary ext4_inode_datasync_dirty in
 read path

On Fri, Nov 05, 2021 at 01:28:10PM +0800, Zhongwei Cai wrote:
> 
> 
> On 11/5/21 7:22 AM, Dave Chinner wrote:
> > 
> > No. Some filesystems don't track inode metadata dirty status using
> > the VFS inode; instead they track it more efficiently in internal
> > inode and/or journal based structures. Hence the only way to get
> > "inode needs journal flush for data stability" information to
> > generic IO code is to have a specific per-IO mapping flag for it.
> > 
> 
> Could we add IOMAP_REPORT_DIRTY flag in the flags field of
> struct iomap_iter to indicate whether the IOMAP_F_DIRTY flag
> needs to be set or not?

You can try. It might turn out OK, but you're also going to have to
modify all the iomap code that current needs IOMAP_F_DIRTY to first
set that flag, then change all the code that currently sets
IOMAP_F_DIRTY to look at IOMAP_REPORT_DIRTY. i.e you now have to
change iomap, ext4 and XFS to do this.

> Currently the IOMAP_F_DIRTY flag is only checked in
> iomap_swapfile_activate(), dax_iomap_fault() and iomap_dio_rw()
> (To be more specific, only the write path in dax_iomap_fault() and
> iomap_dio_rw()). So it would be unnecessary to set the IOMAP_F_DIRTY
> flag in dax_iomap_rw() called in the previous tests.

I think you're trying to optimise the wrong thing - the API is not
the problem, the problem is that the journal->j_state_lock is
contended and the ext4 dirty inode check needs to take it. Fix the
dirty check not to need the journal state lock and the ext4 problem
goes away and there is no need to change the iomap infrastructure.

> Other file systems that set the IOMAP_F_DIRTY flag efficiently
> could ignore the IOMAP_REPORT_DIRTY flag.

No, that's just bad API design. If we are adding IOMAP_REPORT_DIRTY
then the iomap infrastructure should only use that control flag when
it needs to know if the inode is dirty. At this point, it really
becomes mandatory for all filesystems using iomap to support it
because the absence of IOMAP_F_DIRTY because a filesystem doesn't
support it is not the same as "filesystem didn't set it because the
inode is clean".

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com