public inbox for linux-xfs@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox