linux-kernel - Re: [PATCH 1/2] bcachefs: On disk data structures

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: <20180511083233.GX23861@dastard>
Date:   Fri, 11 May 2018 18:32:33 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Kent Overstreet <kent.overstreet@...il.com>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-bcache@...r.kernel.org, Dave Chinner <dchinner@...hat.com>,
        "Darrick J . Wong" <darrick.wong@...cle.com>, hare@...e.com
Subject: Re: [PATCH 1/2] bcachefs: On disk data structures

Hi Kent,

I haven't really had time to digest this in any real detail,
but I've noticed a couple of things that worry me...

On Tue, May 08, 2018 at 06:17:59PM -0400, Kent Overstreet wrote:
> Signed-off-by: Kent Overstreet <kent.overstreet@...il.com>
> ---
>  fs/bcachefs/bcachefs_format.h | 1448 +++++++++++++++++++++++++++++++++
>  1 file changed, 1448 insertions(+)
>  create mode 100644 fs/bcachefs/bcachefs_format.h
> 
> diff --git a/fs/bcachefs/bcachefs_format.h b/fs/bcachefs/bcachefs_format.h
> new file mode 100644
> index 0000000000..0961585c7e
> --- /dev/null
> +++ b/fs/bcachefs/bcachefs_format.h
> @@ -0,0 +1,1448 @@
> +#ifndef _BCACHEFS_FORMAT_H
> +#define _BCACHEFS_FORMAT_H
.....
> +/* Btree keys - all units are in sectors */
> +
> +struct bpos {
> +	/* Word order matches machine byte order */
> +#if defined(__LITTLE_ENDIAN)
> +	__u32		snapshot;
> +	__u64		offset;
> +	__u64		inode;
> +#elif defined(__BIG_ENDIAN)
> +	__u64		inode;
> +	__u64		offset;		/* Points to end of extent - sectors */
> +	__u32		snapshot;
> +#else

Mostly my concerns are about these endian constructs - is the on
disk structure big endian or little endian, and how do you ensure
that everything you read and write to the on-disk format is in the
correct endian notation? I think your on-disk format is little
endian (from the definitions later in the file) but these don't look
like endian neutral structures....

That's apart from the fact all the endian defines make the code
really hard to read, and probably a pain to maintain, and it doubles
the test matrix because any on-disk change has to be validate on
both little endian and big endian machines....

> +union bch_extent_entry {
> +#if defined(__LITTLE_ENDIAN) ||  __BITS_PER_LONG == 64
> +	unsigned long			type;
> +#elif __BITS_PER_LONG == 32
> +	struct {
> +		unsigned long		pad;
> +		unsigned long		type;
> +	};
> +#else

This is another worry - using "long" in the on disk structure
definition. If this is in-meory structures, then use
le64_to_cpu/cpu_to_le64 to convert the value from the on-disk value
to the in-memory, cpu order value....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com