public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 11/12] xfs: remove struct xfs_dabuf and infrastructure
Date: Sat, 17 Dec 2011 18:30:47 -0500	[thread overview]
Message-ID: <20111217233047.GC2383@infradead.org> (raw)
In-Reply-To: <1323238703-13198-12-git-send-email-david@fromorbit.com>

>  	ASSERT(bp != NULL);
> -	leaf = bp->data;
> +	leaf = bp->b_addr;
>  	if (unlikely(leaf->hdr.info.magic != cpu_to_be16(XFS_ATTR_LEAF_MAGIC))) {
>  		XFS_CORRUPTION_ERROR("xfs_attr_leaf_list", XFS_ERRLEVEL_LOW,
>  				     context->dp->i_mount, leaf);
> -		xfs_da_brelse(NULL, bp);
> +		xfs_trans_brelse(NULL, bp);

Wouldn't a direct call to xfs_buf_relse be the more logical replacement
for a call to xfs_da_brelse with a constant NULL transaction argument?

>  int
> -xfs_attr_shortform_allfit(xfs_dabuf_t *bp, xfs_inode_t *dp)
> +xfs_attr_shortform_allfit(
> +	struct xfs_buf	*bp,
> +	struct xfs_inode *dp)

If you'd use one more tab all arguments would be full aligned.  This
also happens in a few more places.

> -xfs_attr_leaf_to_shortform(xfs_dabuf_t *bp, xfs_da_args_t *args, int forkoff)
> +xfs_attr_leaf_to_shortform(
> +	struct xfs_buf	*bp,
> +	xfs_da_args_t	*args,

Also if you touch the argument list anyway please replace xfs_da_args_t
with struct xfs_da_args.

>  void
>  xfs_da_state_free(xfs_da_state_t *state)
>  {
> -	int	i;
> -
>  	xfs_da_state_kill_altpath(state);
> -	for (i = 0; i < state->path.active; i++) {
> -		if (state->path.blk[i].bp)
> -			xfs_da_buf_done(state->path.blk[i].bp);
> -	}
> -	if (state->extravalid && state->extrablk.bp)
> -		xfs_da_buf_done(state->extrablk.bp);
>  #ifdef DEBUG
>  	memset((char *)state, 0, sizeof(*state));
>  #endif /* DEBUG */
>  	kmem_zone_free(xfs_da_state_zone, state);

We really should kill that memset, which only defeats slab poisoning.
Not in this patch, though.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-12-17 23:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07  6:18 [RFC, PATCH 0/12] xfs: compound buffers for directory blocks Dave Chinner
2011-12-07  6:18 ` [PATCH 01/12] xfs: remove remaining scraps of struct xfs_iomap Dave Chinner
2011-12-08 16:02   ` Christoph Hellwig
2011-12-07  6:18 ` [PATCH 02/12] xfs: clean up buffer get/read call API Dave Chinner
2011-12-08 16:07   ` Christoph Hellwig
2011-12-07  6:18 ` [PATCH 03/12] xfs: introduce a compound buffer construct Dave Chinner
2011-12-17 23:11   ` Christoph Hellwig
2011-12-07  6:18 ` [PATCH 04/12] xfs: add compound buffer get and read interfaces Dave Chinner
2011-12-17 23:14   ` Christoph Hellwig
2011-12-07  6:18 ` [PATCH 05/12] xfs: add irec interfaces to xfs_trans_buf_get/read Dave Chinner
2011-12-07  6:18 ` [PATCH 06/12] xfs: convert xfs_da_do_buf to use irec buffer interface Dave Chinner
2011-12-07  6:18 ` [PATCH 07/12] xfs: switch the buffer get/read API to use irec methods Dave Chinner
2011-12-07  6:18 ` [PATCH 08/12] xfs: support multiple irec maps in buffer code Dave Chinner
2011-12-07  6:18 ` [PATCH 09/12] xfs: support compund buffers in buf_item logging Dave Chinner
2011-12-07  6:18 ` [PATCH 10/12] xfs: use multiple irec xfs buf support in dabuf Dave Chinner
2011-12-07  6:18 ` [PATCH 11/12] xfs: remove struct xfs_dabuf and infrastructure Dave Chinner
2011-12-17 23:30   ` Christoph Hellwig [this message]
2011-12-07  6:18 ` [PATCH 12/12] xfs: remove duplication in transaction buffer operations Dave Chinner
2011-12-17 23:32   ` Christoph Hellwig
2011-12-07  6:35 ` [RFC, PATCH 0/12] xfs: compound buffers for directory blocks Christoph Hellwig
2011-12-07  9:23   ` Dave Chinner
2011-12-14 18:33 ` Christoph Hellwig
2011-12-18 23:01   ` Dave Chinner

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=20111217233047.GC2383@infradead.org \
    --to=hch@infradead.org \
    --cc=david@fromorbit.com \
    --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