Re: [PATCH 2/3] xfs: set firstfsb to NULLFSBLOCK before feeding it to _bmapi_write

[Brian Foster <bfoster@redhat.com>]

On Wed, Jul 19, 2017 at 08:39:50AM -0700, Darrick J. Wong wrote:
> On Wed, Jul 19, 2017 at 09:20:22AM -0400, Brian Foster wrote:
> > On Tue, Jul 18, 2017 at 11:24:22AM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <darrick.wong@oracle.com>
> > > 
> > > We must initialize the firstfsb parameter to _bmapi_write so that it
> > > doesn't incorrectly treat stack garbage as a restriction on which AGs
> > > it can search for free space.
> > > 
> > > Fixes-coverity-id: 1402025
> > > Fixes-coverity-id: 1415167
> > > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > > ---
> > >  fs/xfs/libxfs/xfs_bmap.c |    2 +-
> > >  fs/xfs/xfs_reflink.c     |    2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > 
> > > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> > > index 935adde..8c4ee60 100644
> > > --- a/fs/xfs/libxfs/xfs_bmap.c
> > > +++ b/fs/xfs/libxfs/xfs_bmap.c
> > > @@ -6508,7 +6508,7 @@ xfs_bmap_finish_one(
> > >  	xfs_filblks_t			*blockcount,
> > >  	xfs_exntst_t			state)
> > >  {
> > > -	xfs_fsblock_t			firstfsb;
> > > +	xfs_fsblock_t			firstfsb = NULLFSBLOCK;
> > >  	int				error = 0;
> > >  
> > 
> > Shouldn't firstfsb be tied to the transaction lifetime in (at least)
> > this case? It is used in the allocator to control things like AG locking
> > order.
> 
> That is correct...
> 
> > Here, it looks like we could potentially do multiple unmaps in a
> > single transaction without carrying the firstfsb state across..?
> 
> ...but keep in mind that we call xfs_bmap_finish_one once per
> transaction and roll transactions until the work is done.  I'll add a
> comment here to that effect:
> 
> /*
>  * firstfsb is tied to the transaction lifetime and is used to ensure
>  * correct AG locking order and schedule work item continuations.
>  * XFS_BUI_MAX_FAST_EXTENTS (== 1) restricts us to only making one bmap
>  * call per transaction, so it should be safe as a local variable.
>  */
> 

Ok, got it. One transaction per dfp and one unmap per dfp, therefore one
unmap per transaction. Thanks!

Brian

> > FWIW this patch still looks fine either way:
> > 
> > Reviewed-by: Brian Foster <bfoster@redhat.com>
> 
> Thank you for the review!
> 
> --D
> > 
> > >  	trace_xfs_bmap_deferred(tp->t_mountp,
> > > diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> > > index ab2270a..d9b3d57 100644
> > > --- a/fs/xfs/xfs_reflink.c
> > > +++ b/fs/xfs/xfs_reflink.c
> > > @@ -329,7 +329,7 @@ xfs_reflink_convert_cow_extent(
> > >  	xfs_filblks_t			count_fsb,
> > >  	struct xfs_defer_ops		*dfops)
> > >  {
> > > -	xfs_fsblock_t			first_block;
> > > +	xfs_fsblock_t			first_block = NULLFSBLOCK;
> > >  	int				nimaps = 1;
> > >  
> > >  	if (imap->br_state == XFS_EXT_NORM)
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html