cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Combine func meta_prep_new with its only caller
Date: Mon, 22 May 2017 16:11:36 +0100	[thread overview]
Message-ID: <48dc4ced-4b5c-b097-73b5-ea32f67ee351@redhat.com> (raw)
In-Reply-To: <1100310029.12345154.1495465229154.JavaMail.zimbra@redhat.com>

Hi,


On 22/05/17 16:00, Bob Peterson wrote:
> Hi,
>
> Before this patch function meta_prep_new was only called in one
> place, function gfs2_meta_new which is only a couple lines long.
> This patch combines them for readability.
>
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
That is a good plan. If you look at the callers of gfs2_meta_new then 
you'll see that there is a common pattern there too (aside from the two 
callers from log.c) and it would be good to merge back some of that into 
this function too, to reduce duplication of code.

It is a bit odd that we unlock the buffer before setting the magic 
number, and also that we do that before adding the buffer to a 
transaction. Worth a quick check there just to see if there is something 
not quite right,

Steve.

> ---
> diff --git a/fs/gfs2/meta_io.c b/fs/gfs2/meta_io.c
> index 663ffc1..bbd9411 100644
> --- a/fs/gfs2/meta_io.c
> +++ b/fs/gfs2/meta_io.c
> @@ -158,18 +158,6 @@ struct buffer_head *gfs2_getbuf(struct gfs2_glock *gl, u64 blkno, int create)
>   	return bh;
>   }
>   
> -static void meta_prep_new(struct buffer_head *bh)
> -{
> -	struct gfs2_meta_header *mh = (struct gfs2_meta_header *)bh->b_data;
> -
> -	lock_buffer(bh);
> -	clear_buffer_dirty(bh);
> -	set_buffer_uptodate(bh);
> -	unlock_buffer(bh);
> -
> -	mh->mh_magic = cpu_to_be32(GFS2_MAGIC);
> -}
> -
>   /**
>    * gfs2_meta_new - Get a block
>    * @gl: The glock associated with this block
> @@ -180,9 +168,15 @@ static void meta_prep_new(struct buffer_head *bh)
>   
>   struct buffer_head *gfs2_meta_new(struct gfs2_glock *gl, u64 blkno)
>   {
> -	struct buffer_head *bh;
> -	bh = gfs2_getbuf(gl, blkno, CREATE);
> -	meta_prep_new(bh);
> +	struct buffer_head *bh = gfs2_getbuf(gl, blkno, CREATE);
> +	struct gfs2_meta_header *mh = (struct gfs2_meta_header *)bh->b_data;
> +
> +	lock_buffer(bh);
> +	clear_buffer_dirty(bh);
> +	set_buffer_uptodate(bh);
> +	unlock_buffer(bh);
> +
> +	mh->mh_magic = cpu_to_be32(GFS2_MAGIC);
>   	return bh;
>   }
>   
>



      reply	other threads:[~2017-05-22 15:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1224744058.12343996.1495465081098.JavaMail.zimbra@redhat.com>
2017-05-22 15:00 ` [Cluster-devel] [GFS2 PATCH] GFS2: Combine func meta_prep_new with its only caller Bob Peterson
2017-05-22 15:11   ` Steven Whitehouse [this message]

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=48dc4ced-4b5c-b097-73b5-ea32f67ee351@redhat.com \
    --to=swhiteho@redhat.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;
as well as URLs for NNTP newsgroup(s).