From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/5] xfs: refactor remote attr value buffer invalidation
Date: Mon, 13 Jan 2020 16:43:07 -0800 [thread overview]
Message-ID: <20200114004307.GQ8247@magnolia> (raw)
In-Reply-To: <20200110115540.GC19577@infradead.org>
On Fri, Jan 10, 2020 at 03:55:40AM -0800, Christoph Hellwig wrote:
> > + struct xfs_mount *mp = ip->i_mount;
> > + struct xfs_buf *bp;
> > + xfs_daddr_t dblkno;
> > + int dblkcnt;
> > +
> > + ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL));
> > +
> > + dblkno = XFS_FSB_TO_DADDR(mp, map->br_startblock),
> > + dblkcnt = XFS_FSB_TO_BB(mp, map->br_blockcount);
> > +
> > + /*
> > + * If the "remote" value is in the cache, remove it.
> > + */
> > + bp = xfs_buf_incore(mp->m_ddev_targp, dblkno, dblkcnt, XBF_TRYLOCK);
>
> Do we really need the dblkno and dblkcnt local variables here?
Eh, not really.
> > @@ -592,18 +614,8 @@ xfs_attr_rmtval_remove(
> > ASSERT((map.br_startblock != DELAYSTARTBLOCK) &&
> > (map.br_startblock != HOLESTARTBLOCK));
> >
> > - dblkno = XFS_FSB_TO_DADDR(mp, map.br_startblock),
> > - dblkcnt = XFS_FSB_TO_BB(mp, map.br_blockcount);
> > -
> > - /*
> > - * If the "remote" value is in the cache, remove it.
> > - */
> > - bp = xfs_buf_incore(mp->m_ddev_targp, dblkno, dblkcnt, XBF_TRYLOCK);
> > - if (bp) {
> > - xfs_buf_stale(bp);
> > - xfs_buf_relse(bp);
> > - bp = NULL;
> > - }
> > + if (map.br_startblock != HOLESTARTBLOCK)
> > + xfs_attr_rmtval_stale(args->dp, &map);
>
> I don't think we need the HOLESTARTBLOCK check here, given that we have
> the asserts above. I also think the assert should move into
> xfs_attr_rmtval_stale and be split into two asserts, one each for the
> invalid values.
<nod> I'll upgrade them to proper fs corruption messages while I'm at
it.
--D
next prev parent reply other threads:[~2020-01-14 0:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 18:44 [PATCH v2 0/5] xfs: fix buf log item memory corruption on non-amd64 Darrick J. Wong
2020-01-09 18:44 ` [PATCH 1/5] xfs: refactor remote attr value buffer invalidation Darrick J. Wong
2020-01-10 11:55 ` Christoph Hellwig
2020-01-14 0:43 ` Darrick J. Wong [this message]
2020-01-09 18:44 ` [PATCH 2/5] xfs: fix memory corruption during " Darrick J. Wong
2020-01-10 11:57 ` Christoph Hellwig
2020-01-14 0:59 ` Darrick J. Wong
2020-01-09 18:45 ` [PATCH 3/5] xfs: clean up xfs_buf_item_get_format return value Darrick J. Wong
2020-01-10 11:58 ` Christoph Hellwig
2020-01-09 18:45 ` [PATCH 4/5] xfs: complain if anyone tries to create a too-large buffer log item Darrick J. Wong
2020-01-10 11:58 ` Christoph Hellwig
2020-01-09 18:45 ` [PATCH 5/5] xfs: make struct xfs_buf_log_format have a consistent size Darrick J. Wong
2020-01-10 11:59 ` Christoph Hellwig
2020-01-10 16:53 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200114004307.GQ8247@magnolia \
--to=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.