From: Christoph Hellwig <hch@lst.de>
To: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH 15/21] implement generic xfs_btree_rshift
Date: Fri, 1 Aug 2008 21:49:14 +0200 [thread overview]
Message-ID: <20080801194914.GI1263@lst.de> (raw)
In-Reply-To: <20080730060808.GP13395@disturbed>
> > +{
> > + ASSERT(from >= 0 && from <= 1000);
> > + ASSERT(to >= 0 && to <= 1000);
> > + ASSERT(numptrs >= 0);
>
> Those numbers are not safe. I plucked them out of thin air to verify
> validity on 4k block size filesystem which had (IIRC) a max of about
> 500 ptrs to a block. It was throwaway debug code to find a problem.
> Larger block sizes can well exceed 1000. So realistically, the only
> valid assert there is this one:
>
> ASSERT(numptrs >= 0);
Yeah, I've actually managed to trigger it now. The >=0 checks
for from and to still make sense, although they might be overkill.
> How about:
>
> union xfs_btree_ptr *pp;
> xfs_caddr_t *block = XFS_BUF_TO_BLOCK(bp);
> xfs_caddr_t start; /* first byte offset logged */
> xfs_caddr_t end; /* last byte offset logged */
>
> pp = cur->bc_ops->ptr_addr(cur, 1, XFS_BUF_TO_BLOCK(bp));
>
> if (cur->bc_flags & XFS_BTREE_LONG_PTRS) {
> __be64 *lpp = &pp->l;
>
> start = (xfs_caddr_t)&lpp[first - 1] - block;
> end = ((xfs_caddr_t)&lpp[last] - 1) - block;
> } else {
> __be32 *spp = &pp->s;
>
> start = (xfs_caddr_t)&spp[first - 1] - block;
> end = ((xfs_caddr_t)&spp[last] - 1) - block;
> }
>
> xfs_trans_log_buf(cur->bc_tp, bp, (int)start, (int)end);
>
> That makes it much easier to read (to me, anyway).
Yes, absolutely. And there's also another set of useless braces.
I've also applied a similar cleanup to the log_keys and log_recs
implementations.
> > + XFS_BTREE_TRACE_CURSOR(cur, XBT_ENTRY);
> > + XFS_BTREE_TRACE_ARGBI(cur, bp, fields);
> > +
> > + if (bp) {
> > + xfs_btree_offsets(fields,
> > + (cur->bc_flags & XFS_BTREE_LONG_PTRS) ?
> > + loffsets : soffsets,
> ^^
> Some stray whitespace there.
Fixed.
> > + XFS_BB_NUM_BITS, &first, &last);
> > + xfs_trans_log_buf(cur->bc_tp, bp, first, last);
> > + } else {
> > + /* XXX(hch): maybe factor out into a method? */
> > + xfs_trans_log_inode(cur->bc_tp, cur->bc_private.b.ip,
> > + XFS_ILOG_FBROOT(cur->bc_private.b.whichfork));
>
> I don't think it is necessary at this point.
It's the only leakage of the detailed inode root implementation into
the generic code, so I'm still wondering whether a method would be
better.
next prev parent reply other threads:[~2008-08-01 19:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 19:31 [PATCH 15/21] implement generic xfs_btree_rshift Christoph Hellwig
2008-07-30 6:08 ` Dave Chinner
2008-08-01 19:49 ` Christoph Hellwig [this message]
2008-08-02 1:20 ` Dave Chinner
2008-08-02 15:31 ` Christoph Hellwig
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=20080801194914.GI1263@lst.de \
--to=hch@lst.de \
--cc=xfs@oss.sgi.com \
/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.