All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: fix endianness compatibility during the SB RW
Date: Thu, 15 Feb 2018 17:49:07 +0100	[thread overview]
Message-ID: <20180215164907.GD10193@twin.jikos.cz> (raw)
In-Reply-To: <5caed65c-79b1-5e12-78a0-47cffb220ca0@oracle.com>

On Wed, Feb 14, 2018 at 10:53:19PM +0800, Anand Jain wrote:
> 
> 
> On 02/14/2018 01:55 AM, David Sterba wrote:
> > On Tue, Feb 13, 2018 at 06:27:13PM +0800, Anand Jain wrote:
> >> On 02/13/2018 05:01 PM, Qu Wenruo wrote:
> >>> On 2018年02月13日 11:00, Anand Jain wrote:
> >>>> Fixes the endianness bug in the fs_info::super_copy by using its
> >>>> btrfs_set_super...() function to set values in the SB, as these
> >>>> functions manage the endianness compatibility nicely.
> >>>>
> >>>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> >>>
> >>> Also went through all btrfs_super_block SETGET functions, greping using
> >>> \><member name>, seems that there are still some left here:
> >>>
> >>> fs/btrfs/sysfs.c:
> >>> In both btrfs_sectorsize_show() and btrfs_clone_alignment_show():
> >>> 	return snprintf(buf, PAGE_SIZE, "%u\n",
> >>> 			fs_info->super_copy->sectorsize);
> >>>
> >>> In btrfs_nodesize_show():
> >>> 	return snprintf(buf, PAGE_SIZE, "%u\n", fs_info->super_copy->nodesize);
> 
>   Thinking again on the printf they are fine without the endianness
>   functions, because it is printing the values from the memory to
>   buf/stdout, which was previously read from the disk (which
>   possibly written by the opposite endianness system). Here, there
>   is no endianness changes that will be required for it to be written
>   out using printf.

We need to fix the value for printf for the same reason this patch was
needed:

https://git.kernel.org/linus/bea7eafdbda3ba1d4b2ccb9cca829eefb7989bb9

and we can actually use the fs_info-> copies here too.

  reply	other threads:[~2018-02-15 16:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 15:37 [PATCH] btrfs: use set functions to update latest refs to the SB Anand Jain
2018-02-12 16:34 ` David Sterba
2018-02-13  2:56   ` Anand Jain
2018-02-13  3:00 ` [PATCH v2] btrfs: fix endianness compatibility during the SB RW Anand Jain
2018-02-13  7:04   ` Nikolay Borisov
2018-02-13  9:01   ` Qu Wenruo
2018-02-13 10:27     ` Anand Jain
2018-02-13 10:39       ` Qu Wenruo
2018-02-13 17:55       ` David Sterba
2018-02-14 14:53         ` Anand Jain
2018-02-15 16:49           ` David Sterba [this message]
2018-02-20 17:16   ` Liu Bo

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=20180215164907.GD10193@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.