linux-kernel - Re: [PATCH v9 03/11] btrfs: add support for inserting raid stripe extents

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: <dd759994-678f-1d2c-a33e-6320b8ac4c6c@linux-m68k.org>
Date:   Fri, 15 Sep 2023 12:03:23 +0200 (CEST)
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     David Sterba <dsterba@...e.cz>
cc:     Johannes Thumshirn <johannes.thumshirn@....com>,
        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-kernel@...r.kernel.org
Subject: Re: [PATCH v9 03/11] btrfs: add support for inserting raid stripe
 extents

 	Hi David,

On Thu, 14 Sep 2023, David Sterba wrote:
> On Thu, Sep 14, 2023 at 09:06:58AM -0700, Johannes Thumshirn wrote:
>> Add support for inserting stripe extents into the raid stripe tree on
>> completion of every write that needs an extra logical-to-physical
>> translation when using RAID.
>>
>> Inserting the stripe extents happens after the data I/O has completed,
>> this is done to a) support zone-append and b) rule out the possibility of
>> a RAID-write-hole.
>>
>> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@....com>

>> --- /dev/null
>> +++ b/fs/btrfs/raid-stripe-tree.c
>> +static int btrfs_insert_striped_mirrored_raid_extents(
>> +				      struct btrfs_trans_handle *trans,
>> +				      struct btrfs_ordered_extent *ordered,
>> +				      u64 map_type)
>> +{
>> +	struct btrfs_io_context *bioc;
>> +	struct btrfs_io_context *rbioc;
>> +	const int nstripes = list_count_nodes(&ordered->bioc_list);
>> +	const int index = btrfs_bg_flags_to_raid_index(map_type);
>> +	const int substripes = btrfs_raid_array[index].sub_stripes;
>> +	const int max_stripes =
>> +		trans->fs_info->fs_devices->rw_devices / substripes;
>
> This will probably warn due to u64/u32 division.

Worse, it causes link failures in linux-next, as e.g. reported by
noreply@...erman.id.au:

     ERROR: modpost: "__udivdi3" [fs/btrfs/btrfs.ko] undefined!

So despite being aware of the issue, you still queued it?

The use of "int" for almost all variables is also a red flag:
   - list_count_nodes() returns size_t,
   - btrfs_bg_flags_to_raid_index() returns an enum.
   - btrfs_raid_array[index].sub_stripes is u8,
   - The result of the division may not fit in 32-bit.

Thanks for fixing, soon! ;-)

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds