All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.