public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs_repair: stop using ->data_entry_p()
Date: Fri, 17 Jan 2020 20:39:47 -0800	[thread overview]
Message-ID: <20200118043947.GO8257@magnolia> (raw)
In-Reply-To: <2cf1f45b-b3b2-f630-50d5-ff34c000b0c8@redhat.com>

On Fri, Jan 17, 2020 at 05:17:11PM -0600, Eric Sandeen wrote:
> The ->data_entry_p() op went away in v5.5 kernelspace, so rework
> xfs_repair to use ->data_entry_offset instead, in preparation
> for the v5.5 libxfs backport.
> 
> This could later be cleaned up to use offsets as was done
> in kernel commit 8073af5153c for example.

See, now that you've said that, I start wondering why not do that?

:D

> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> I'll munge this patch in mid-libxfs-sync, just before the
> ->data_entry_p removal patch.
> 
> diff --git a/repair/dir2.c b/repair/dir2.c
> index 4ac0084e..2494f3c4 100644
> --- a/repair/dir2.c
> +++ b/repair/dir2.c
> @@ -580,7 +580,7 @@ process_dir2_data(
>  
>  	d = bp->b_addr;
>  	bf = M_DIROPS(mp)->data_bestfree_p(d);
> -	ptr = (char *)M_DIROPS(mp)->data_entry_p(d);
> +	ptr = (char *)d + M_DIROPS(mp)->data_entry_offset;
>  	badbest = lastfree = freeseen = 0;
>  	if (be16_to_cpu(bf[0].length) == 0) {
>  		badbest |= be16_to_cpu(bf[0].offset) != 0;
> @@ -646,7 +646,7 @@ process_dir2_data(
>  			do_warn(_("\twould junk block\n"));
>  		return 1;
>  	}
> -	ptr = (char *)M_DIROPS(mp)->data_entry_p(d);
> +	ptr = (char *)d + M_DIROPS(mp)->data_entry_offset;
>  	/*
>  	 * Process the entries now.
>  	 */
> diff --git a/repair/phase6.c b/repair/phase6.c
> index 91d208a6..d61b2ae7 100644
> --- a/repair/phase6.c
> +++ b/repair/phase6.c
> @@ -1530,7 +1530,7 @@ longform_dir2_entry_check_data(
>  
>  	bp = *bpp;
>  	d = bp->b_addr;
> -	ptr = (char *)M_DIROPS(mp)->data_entry_p(d);
> +	ptr = (char *)d + M_DIROPS(mp)->data_entry_offset;
>  	nbad = 0;
>  	needscan = needlog = 0;
>  	junkit = 0;
> @@ -1590,7 +1590,7 @@ longform_dir2_entry_check_data(
>  				break;
>  
>  			/* check for block with no data entries */
> -			if ((ptr == (char *)M_DIROPS(mp)->data_entry_p(d)) &&
> +			if ((ptr == (char *)d + M_DIROPS(mp)->data_entry_offset) &&
>  			    (ptr + be16_to_cpu(dup->length) >= endptr)) {
>  				junkit = 1;
>  				*num_illegal += 1;
> @@ -1659,7 +1659,7 @@ longform_dir2_entry_check_data(
>  			do_warn(_("would fix magic # to %#x\n"), wantmagic);
>  	}
>  	lastfree = 0;
> -	ptr = (char *)M_DIROPS(mp)->data_entry_p(d);
> +	ptr = (char *)d + M_DIROPS(mp)->data_entry_offset;
>  	/*
>  	 * look at each entry.  reference inode pointed to by each
>  	 * entry in the incore inode tree.
> @@ -1834,7 +1834,7 @@ longform_dir2_entry_check_data(
>  			       (dep->name[0] == '.' && dep->namelen == 1));
>  			add_inode_ref(current_irec, current_ino_offset);
>  			if (da_bno != 0 ||
> -			    dep != M_DIROPS(mp)->data_entry_p(d)) {
> +			    dep != (void *)d + M_DIROPS(mp)->data_entry_offset) {

Er.... void pointer arithmetic?

(Though I really do wish the original author of the kernel patchset had
supplied a xfsprogs port of the kernel patches so we maintainers don't
get stuck doing all the porting work...)

--D

>  				/* "." should be the first entry */
>  				nbad++;
>  				if (entry_junked(
> 

  reply	other threads:[~2020-01-18  4:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17 23:17 [PATCH] xfs_repair: stop using ->data_entry_p() Eric Sandeen
2020-01-18  4:39 ` Darrick J. Wong [this message]
2020-01-20 14:29   ` Eric Sandeen
2020-01-21 18:37     ` Darrick J. Wong
2020-01-22  0:41       ` Darrick J. Wong
2020-01-20  8:58 ` 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=20200118043947.GO8257@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@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