xfs
[Top] [All Lists]

Re: [PATCH 03/11] xfs: remote attribute read too short

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 03/11] xfs: remote attribute read too short
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 22 May 2013 08:53:33 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130521205924.GM20028@xxxxxxx>
References: <1369123330-9579-1-git-send-email-david@xxxxxxxxxxxxx> <1369123330-9579-4-git-send-email-david@xxxxxxxxxxxxx> <20130521205924.GM20028@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, May 21, 2013 at 03:59:24PM -0500, Ben Myers wrote:
> On Tue, May 21, 2013 at 06:02:02PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > Reading a maximally size remote attribute fails when CRCs are
> > enabled with this verification error:
> > 
> > XFS (vdb): remote attribute header does not match required off/len/owner)
> > 
> > There are two reasons for this, the first being that the
> > length of the buffer being read is determined from the
> > args->rmtblkcnt which doesn't take into account CRC headers. Hence
> > the mapped length ends up being too short and so we need to
> > calculate it directly from the value length.
> > 
> > The second is that the byte count of valid data within a buffer is
> > capped by the length of the data and so doesn't take into account
> > that the buffer might be longer due to headers. Hence we need to
> > calculate the data space in the buffer first before calculating the
> > actual byte count of data.
> > 
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
> >  fs/xfs/xfs_attr_remote.c |   15 +++++++++------
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_attr_remote.c b/fs/xfs/xfs_attr_remote.c
> > index aad95b0..bcdc07c 100644
> > --- a/fs/xfs/xfs_attr_remote.c
> > +++ b/fs/xfs/xfs_attr_remote.c
> > @@ -52,9 +52,11 @@ xfs_attr3_rmt_blocks(
> >     struct xfs_mount *mp,
> >     int             attrlen)
> >  {
> > -   int             buflen = XFS_ATTR3_RMT_BUF_SPACE(mp,
> > -                                                    mp->m_sb.sb_blocksize);
> > -   return (attrlen + buflen - 1) / buflen;
> > +   if (xfs_sb_version_hascrc(&mp->m_sb)) {
> > +           int buflen = XFS_ATTR3_RMT_BUF_SPACE(mp, mp->m_sb.sb_blocksize);
> > +           return (attrlen + buflen - 1) / buflen;
> > +   }
> > +   return XFS_B_TO_FSB(mp, attrlen);
> 
> xfs_attr_rmtval_set, xfs_attr3_rmt_blocks, and XFS_ATTR3_RMT_BUF_SPACE all 
> have
> checks for crcs on the superblock.  It's like I'm seeing stars.

Sure - I'm not concerned about how efficient the code is at this
point. I just want it to work correctly. If that means we check for
CRC support more frequently than we need to, then that's no big deal
right now.

> 
> >  }
> >  
> >  static bool
> > @@ -206,8 +208,9 @@ xfs_attr_rmtval_get(
> >  
> >     while (valuelen > 0) {
> >             nmap = ATTR_RMTVALUE_MAPSIZE;
> > +           blkcnt = xfs_attr3_rmt_blocks(mp, valuelen);
> >             error = xfs_bmapi_read(args->dp, (xfs_fileoff_t)lblkno,
> > -                                  args->rmtblkcnt, map, &nmap,
> > +                                  blkcnt, map, &nmap,
> 
> Isn't blkcnt wrong on the 2nd or greater iteration of this loop?  Looks like 
> an old bug.

Yes, args->rmtblkcnt is wrong on the 2nd+ loop iteration. And yes,
it's an old, old bug.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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