Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 3 Nov 2021 11:28:43 +1100
From:   Dave Chinner <david@fromorbit.com>
To:     Zhongwei Cai <sunrise_l@sjtu.edu.cn>
Cc:     tytso@mit.edu, adilger.kernel@dilger.ca,
        linux-ext4@vger.kernel.org, mingkaidong@gmail.com
Subject: Re: [PATCH] ext4: remove unnecessary ext4_inode_datasync_dirty in
 read path
Message-ID: <20211103002843.GC418105@dread.disaster.area>
References: <20211102024258.210439-1-sunrise_l@sjtu.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211102024258.210439-1-sunrise_l@sjtu.edu.cn>
Precedence: bulk

On Tue, Nov 02, 2021 at 10:42:58AM +0800, Zhongwei Cai wrote:
> ext4_inode_datasync_dirty will call read_lock(&journal->j_state_lock) in
> journal mode, which is unnecessary in read path (As far as I know, the
> IOMAP_F_DIRTY flag set in the if branch is only used in write path,
> making it unnecessary in read path. Please correct me if I'm wrong).

IOMAP_F_DIRTY isn't conditional on the type of lookup being done. If
the inode is dirty in a way that O_DSYNC would require it to be
flushed to make the data stable, iomap should be told that it is
dirty, even on read lookups...

e.g. iomap_swapfile_activate() uses IOMAP_REPORT as the flags for
extent mapping iteration passed to iomap_swapfile_iter(). THis then
checks:

	/* No uncommitted metadata or shared blocks. */
	if (iomap->flags & IOMAP_F_DIRTY)
		return iomap_swapfile_fail(isi, "is not committed");

IOWs, we expect the IOMAP_F_DIRTY flag to be set on all types of
iomap mapping calls if the inode is dirty, not just IOMAP_WRITE
calls.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com