Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 29 Aug 2019 14:38:25 +0200
From:   Jan Kara <jack@suse.cz>
To:     Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc:     Jan Kara <jack@suse.cz>, linux-ext4@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, tytso@mit.edu, riteshh@linux.ibm.com
Subject: Re: [PATCH 4/5] ext4: introduce direct IO write code path using
 iomap infrastructure
Message-ID: <20190829123825.GB22939@quack2.suse.cz>
References: <cover.1565609891.git.mbobrowski@mbobrowski.org>
 <581c3a2da89991e7ce5862d93dcfb23e1dc8ddc8.1565609891.git.mbobrowski@mbobrowski.org>
 <20190828202619.GG22343@quack2.suse.cz>
 <20190829114515.GB2486@poseidon.bobrowski.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190829114515.GB2486@poseidon.bobrowski.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Thu 29-08-19 21:45:17, Matthew Bobrowski wrote:
> > > @@ -3581,10 +3611,10 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
> > >  		iomap->type = delalloc ? IOMAP_DELALLOC : IOMAP_HOLE;
> > >  		iomap->addr = IOMAP_NULL_ADDR;
> > >  	} else {
> > > -		if (map.m_flags & EXT4_MAP_MAPPED) {
> > > -			iomap->type = IOMAP_MAPPED;
> > > -		} else if (map.m_flags & EXT4_MAP_UNWRITTEN) {
> > > +		if (map.m_flags & EXT4_MAP_UNWRITTEN) {
> > >  			iomap->type = IOMAP_UNWRITTEN;
> > > +		} else if (map.m_flags & EXT4_MAP_MAPPED) {
> > > +			iomap->type = IOMAP_MAPPED;
> > >  		} else {
> > >  			WARN_ON_ONCE(1);
> > >  			return -EIO;
> > 
> > Possibly this hunk should go into a separate patch (since this is not
> > directly related with iomap conversion) with a changelog / comment
> > explaining why we need to check EXT4_MAP_UNWRITTEN first.
> 
> But wouldn't doing so break bisection? Seeing as though we needed to
> change this statement specifically to accommodate for the weirdness
> being returned from ext4_map_blocks()? i.e. map.m_flags being set to
> either of the following:
> 
> 	- (EXT4_MAP_NEW | EXT4_MAP_MAPPED)
>         or
>         - (EXT4_MAP_NEW | EXT4_MAP_MAPPED | EXT4_MAP_UNWRITTEN)
> 
> So, if we left the statement in its original form, we'd allocate
> unwritten extents but never actually get around to converting them in
> ext4_dio_write_end_io() as IOMAP_DIO_UNWRITTEN would never be set?

By splitting into a separate patch, I meant that patch would go before this
one. Original code in ext4_iomap_begin() never called ext4_map_blocks()
with a set of flags that can return with both EXT4_MAP_MAPPED and
EXT4_MAP_UNWRITTEN set so that patch would be a no-op but would fix that
landmine you tripped over.

								Honza

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