linux-kernel - Re: [PATCH v8 01/11] btrfs: add raid stripe tree definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230913144951.GL20408@twin.jikos.cz>
Date:   Wed, 13 Sep 2023 16:49:52 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Johannes Thumshirn <Johannes.Thumshirn@....com>
Cc:     "dsterba@...e.cz" <dsterba@...e.cz>, Chris Mason <clm@...com>,
        Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>,
        Christoph Hellwig <hch@....de>,
        Naohiro Aota <Naohiro.Aota@....com>, Qu Wenruo <wqu@...e.com>,
        Damien Le Moal <dlemoal@...nel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 01/11] btrfs: add raid stripe tree definitions

On Wed, Sep 13, 2023 at 06:02:09AM +0000, Johannes Thumshirn wrote:
> On 12.09.23 22:32, David Sterba wrote:
> >> @@ -306,6 +306,16 @@ BTRFS_SETGET_FUNCS(timespec_nsec, struct btrfs_timespec, nsec, 32);
> >>   BTRFS_SETGET_STACK_FUNCS(stack_timespec_sec, struct btrfs_timespec, sec, 64);
> >>   BTRFS_SETGET_STACK_FUNCS(stack_timespec_nsec, struct btrfs_timespec, nsec, 32);
> >>   
> >> +BTRFS_SETGET_FUNCS(stripe_extent_encoding, struct btrfs_stripe_extent, encoding, 8);
> > 
> > What is encoding referring to?
> 
> At the moment (only) the RAID type. But in the future it can be expanded 
> to all kinds of encodings, like Reed-Solomon, Butterfly-Codes, etc...

I see, could it be better called ECC? Like stripe_extent_ecc, that would
be clear that it's for the correction, encoding sounds is too generic.

> >> +	__le64 devid;
> >> +	/* physical location on disk */
> >> +	__le64 physical;
> >> +	/* length of stride on this disk */
> >> +	__le64 length;
> >> +};
> > 
> > __attribute__ ((__packed__));
> 
> The structure doesn't have any holes in it so packed is not needed.
> 
> I might also be misinformed, but doesn't packed potentially lead to bad 
> code generation on some platforms?  I've always been under the 
> impression that packed forces the compiler to do byte-wise loads and 
> stores. But as I've said, I might be misinformed.

All on-disk structures have the packed attribute so for consistency and
future safety it should be here too, even if it technically does not
need it due to alignment. In addition, strucutres that need padding
would be also problematic, e.g. u64 followed by u32 needs 4 bytes of
padding but the next item after it would be placed right after u32.

It's right that on some platforms unaligned access is done by more code
but for the same reason on such platforms we can't let the compiler
decide the layout when the structure is directly mapped onto the blocks.