xfs
[Top] [All Lists]

Re: [PATCH 03/12] xfs: Remove the macro XFS_BUF_ERROR and family

To: aelder@xxxxxxx
Subject: Re: [PATCH 03/12] xfs: Remove the macro XFS_BUF_ERROR and family
From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
Date: Fri, 22 Jul 2011 13:49:56 -0700
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1311363490.2771.98.camel@doink>
Organization: IBM
References: <20110722003226.21069.58401.sendpatchset@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110722003254.21069.27101.sendpatchset@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1311363490.2771.98.camel@doink>
Reply-to: sekharan@xxxxxxxxxx
Thanks for the review Alex.

See below for comments.

On Fri, 2011-07-22 at 14:38 -0500, Alex Elder wrote:
> On Thu, 2011-07-21 at 17:32 -0700, Chandra Seetharaman wrote:
> > Remove the definitions and usage of the macros XFS_BUF_ERROR,
> > XFS_BUF_GETERROR and XFS_BUF_ISERROR.
> > 
> > Signed-off-by: Chandra Seetharaman <sekharan@xxxxxxxxxx>
> 
> Nice work on this.  It is clear it was thoughtfully
> done.
> 
> I have two things that need to be fixed.  If you do that
> you can consider this signed off by me.xfs_buf_geterror
> 
> Reviewed-by: Alex Elder <aelder@xxxxxxx>
> 
> . . .
> 
> > diff --git a/fs/xfs/quota/xfs_dquot.c b/fs/xfs/quota/xfs_dquot.c
> > index 837f311..e7e35fb 100644
> > --- a/fs/xfs/quota/xfs_dquot.c
> > +++ b/fs/xfs/quota/xfs_dquot.c
> > @@ -403,7 +403,8 @@ xfs_qm_dqalloc(
> >                            dqp->q_blkno,
> >                            mp->m_quotainfo->qi_dqchunklen,
> >                            0);
> > -   if (!bp || (error = XFS_BUF_GETERROR(bp)))
> > +   error = xfs_buf_geterror(bp);
> > +   if (error)
> >             goto error1;
> >     /*
> >      * Make a chunk of dquots out of this buffer and log
> 
> This results in behavior that differs from before.
> Previously, error would have value 0 following
> the call to xfs_trans_get_buf() here, meaning that
> (at error1:) xfs_qm_dqalloc() would return 0 in
> this case.  Now it will return ENOMEM.
> 
> I think what you have done may be correct, but
> since the change does more than the simple
> macro transformation you intend, this change
> should be done in a separate commit.
> 
> So either:
> - post a new patch (preferably before this
>   whole series) that makes this code return
>   ENOMEM if xfs_trans_get_buf() returns a
>   null pointer, then update this patch accordingly;

Will it this way and resent the patch
xfs_buf_geterror
> - or just change this patch to return 0 instead
>   of  ENOMEM if xfs_trans_get_buf() returns a
>   null pointer.
> 
> . . .
> 
> > diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c
> > index 88d1214..97daa35 100644
> > --- a/fs/xfs/xfs_vnodeops.c
> > +++ b/fs/xfs/xfs_vnodeops.c
> > @@ -83,7 +83,7 @@ xfs_readlink_bmap(
> >  
> >             bp = xfs_buf_read(mp->m_ddev_targp, d, BTOBB(byte_cnt),
> >                               XBF_LOCK | XBF_MAPPED | XBF_DONT_BLOCK);
> 
> xfs_buf_read() can return NULL here, so to match
> the existing behavior you should call xfs_buf_geterror()
> here.
> 
> > -           error = XFS_BUF_GETERROR(bp);
> > +           error = bp->b_error;
> >             if (error) {
> >                     xfs_ioerror_alert("xfs_readlink",
> >                               ip->i_mount, bp, XFS_BUF_ADDR(bp));

I did the change consciously. If bp were NULL, error would have been set
to ENOMEM, and xfs_ioerror_alert() and xfs_buf_relse(), would have
accessed bp and tripped anyways. So, I felt using the indirection
(xfs_buf_geterror()) is not adding any value, hence set error by
directly accessing b_error.

There are more place like these.

What do you think of this option

Leave this as is (with b_error), and send another patch to check for bp
after xfs_buf_read() in all places (if you want this option, what do you
think error should be set to, I see both EIO and ENOMEM used. I think it
should be the same always).

If you don't like that option I can revert to xfs_buf_geterror() too.

> 
> 


<Prev in Thread] Current Thread [Next in Thread>