From: Dan Carpenter <error27@gmail.com>
To: oe-kbuild@lists.linux.dev, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH 4/5] btrfs: raid56: prepare data checksums for later RMW data csum verification
Date: Tue, 15 Nov 2022 09:40:22 +0300 [thread overview]
Message-ID: <202211150946.Z76SnBqp-lkp@intel.com> (raw)
In-Reply-To: <6620c738ea5f959085bfad0c0c843880f4c4e6e2.1668384746.git.wqu@suse.com>
Hi Qu,
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Qu-Wenruo/btrfs-raid56-destructive-RMW-fix-for-RAID5-data-profiles/20221114-082910
base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link: https://lore.kernel.org/r/6620c738ea5f959085bfad0c0c843880f4c4e6e2.1668384746.git.wqu%40suse.com
patch subject: [PATCH 4/5] btrfs: raid56: prepare data checksums for later RMW data csum verification
config: x86_64-randconfig-m001-20221114
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
New smatch warnings:
fs/btrfs/raid56.c:2108 fill_data_csums() error: uninitialized symbol 'ret'.
Old smatch warnings:
fs/btrfs/raid56.c:1017 get_rbio_veritical_errors() error: we previously assumed 'faila' could be null (see line 1011)
vim +/ret +2108 fs/btrfs/raid56.c
f24e7de3761574 Qu Wenruo 2022-11-14 2057 static void fill_data_csums(struct btrfs_raid_bio *rbio)
f24e7de3761574 Qu Wenruo 2022-11-14 2058 {
f24e7de3761574 Qu Wenruo 2022-11-14 2059 struct btrfs_fs_info *fs_info = rbio->bioc->fs_info;
f24e7de3761574 Qu Wenruo 2022-11-14 2060 struct btrfs_root *csum_root = btrfs_csum_root(fs_info,
f24e7de3761574 Qu Wenruo 2022-11-14 2061 rbio->bioc->raid_map[0]);
f24e7de3761574 Qu Wenruo 2022-11-14 2062 const u64 start = rbio->bioc->raid_map[0];
f24e7de3761574 Qu Wenruo 2022-11-14 2063 const u32 len = (rbio->nr_data * rbio->stripe_nsectors) <<
f24e7de3761574 Qu Wenruo 2022-11-14 2064 fs_info->sectorsize_bits;
f24e7de3761574 Qu Wenruo 2022-11-14 2065 int ret;
f24e7de3761574 Qu Wenruo 2022-11-14 2066
f24e7de3761574 Qu Wenruo 2022-11-14 2067 /* The rbio should not has its csum buffer initialized. */
f24e7de3761574 Qu Wenruo 2022-11-14 2068 ASSERT(!rbio->csum_buf && !rbio->csum_bitmap);
f24e7de3761574 Qu Wenruo 2022-11-14 2069
f24e7de3761574 Qu Wenruo 2022-11-14 2070 /*
f24e7de3761574 Qu Wenruo 2022-11-14 2071 * Skip the csum search if:
f24e7de3761574 Qu Wenruo 2022-11-14 2072 *
f24e7de3761574 Qu Wenruo 2022-11-14 2073 * - The rbio doesn't belongs to data block groups
f24e7de3761574 Qu Wenruo 2022-11-14 2074 * Then we are doing IO for tree blocks, no need to
f24e7de3761574 Qu Wenruo 2022-11-14 2075 * search csums.
f24e7de3761574 Qu Wenruo 2022-11-14 2076 *
f24e7de3761574 Qu Wenruo 2022-11-14 2077 * - The rbio belongs to mixed block groups
f24e7de3761574 Qu Wenruo 2022-11-14 2078 * This is to avoid deadlock, as we're already holding
f24e7de3761574 Qu Wenruo 2022-11-14 2079 * the full stripe lock, if we trigger a metadata read, and
f24e7de3761574 Qu Wenruo 2022-11-14 2080 * it needs to do raid56 recovery, we will deadlock.
f24e7de3761574 Qu Wenruo 2022-11-14 2081 */
f24e7de3761574 Qu Wenruo 2022-11-14 2082 if (!(rbio->bioc->map_type & BTRFS_BLOCK_GROUP_DATA) ||
f24e7de3761574 Qu Wenruo 2022-11-14 2083 rbio->bioc->map_type & BTRFS_BLOCK_GROUP_METADATA)
f24e7de3761574 Qu Wenruo 2022-11-14 2084 return;
f24e7de3761574 Qu Wenruo 2022-11-14 2085
f24e7de3761574 Qu Wenruo 2022-11-14 2086 rbio->csum_buf = kzalloc(rbio->nr_data * rbio->stripe_nsectors *
f24e7de3761574 Qu Wenruo 2022-11-14 2087 fs_info->csum_size, GFP_NOFS);
f24e7de3761574 Qu Wenruo 2022-11-14 2088 rbio->csum_bitmap = bitmap_zalloc(rbio->nr_data * rbio->stripe_nsectors,
f24e7de3761574 Qu Wenruo 2022-11-14 2089 GFP_NOFS);
f24e7de3761574 Qu Wenruo 2022-11-14 2090 if (!rbio->csum_buf || !rbio->csum_bitmap)
f24e7de3761574 Qu Wenruo 2022-11-14 2091 goto error;
"ret" uninitialized on this path.
f24e7de3761574 Qu Wenruo 2022-11-14 2092
f24e7de3761574 Qu Wenruo 2022-11-14 2093 ret = btrfs_lookup_csums_bitmap(csum_root, start, start + len - 1,
f24e7de3761574 Qu Wenruo 2022-11-14 2094 rbio->csum_buf, rbio->csum_bitmap);
f24e7de3761574 Qu Wenruo 2022-11-14 2095 if (ret < 0)
f24e7de3761574 Qu Wenruo 2022-11-14 2096 goto error;
f24e7de3761574 Qu Wenruo 2022-11-14 2097 if (bitmap_empty(rbio->csum_bitmap, len >> fs_info->sectorsize_bits))
f24e7de3761574 Qu Wenruo 2022-11-14 2098 goto no_csum;
f24e7de3761574 Qu Wenruo 2022-11-14 2099 return;
f24e7de3761574 Qu Wenruo 2022-11-14 2100
f24e7de3761574 Qu Wenruo 2022-11-14 2101 error:
f24e7de3761574 Qu Wenruo 2022-11-14 2102 /*
f24e7de3761574 Qu Wenruo 2022-11-14 2103 * We failed to allocate memory or grab the csum,
f24e7de3761574 Qu Wenruo 2022-11-14 2104 * but it's not the end of day, we can still continue.
f24e7de3761574 Qu Wenruo 2022-11-14 2105 * But better to warn users that RMW is no longer safe for this
f24e7de3761574 Qu Wenruo 2022-11-14 2106 * particular sub-stripe write.
f24e7de3761574 Qu Wenruo 2022-11-14 2107 */
f24e7de3761574 Qu Wenruo 2022-11-14 @2108 btrfs_warn_rl(fs_info,
f24e7de3761574 Qu Wenruo 2022-11-14 2109 "sub-stripe write for full stripe %llu is not safe, failed to get csum: %d",
f24e7de3761574 Qu Wenruo 2022-11-14 2110 rbio->bioc->raid_map[0], ret);
^^^
f24e7de3761574 Qu Wenruo 2022-11-14 2111 no_csum:
f24e7de3761574 Qu Wenruo 2022-11-14 2112 kfree(rbio->csum_buf);
f24e7de3761574 Qu Wenruo 2022-11-14 2113 bitmap_free(rbio->csum_bitmap);
f24e7de3761574 Qu Wenruo 2022-11-14 2114 rbio->csum_buf = NULL;
f24e7de3761574 Qu Wenruo 2022-11-14 2115 rbio->csum_bitmap = NULL;
f24e7de3761574 Qu Wenruo 2022-11-14 2116 }
--
0-DAY CI Kernel Test Service
https://01.org/lkp
next prev parent reply other threads:[~2022-11-15 6:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 0:26 [PATCH 0/5] btrfs: raid56: destructive RMW fix for RAID5 data profiles Qu Wenruo
2022-11-14 0:26 ` [PATCH 1/5] btrfs: use btrfs_dev_name() helper to handle missing devices better Qu Wenruo
2022-11-14 16:06 ` Goffredo Baroncelli
2022-11-14 22:40 ` Qu Wenruo
2022-11-14 23:54 ` David Sterba
2022-11-14 0:26 ` [PATCH 2/5] btrfs: refactor btrfs_lookup_csums_range() Qu Wenruo
2022-11-14 0:26 ` [PATCH 3/5] btrfs: introduce a bitmap based csum range search function Qu Wenruo
2022-11-14 0:26 ` [PATCH 4/5] btrfs: raid56: prepare data checksums for later RMW data csum verification Qu Wenruo
2022-11-15 6:40 ` Dan Carpenter [this message]
2022-11-15 13:18 ` David Sterba
2022-11-14 0:26 ` [PATCH 5/5] btrfs: raid56: do data csum verification during RMW cycle Qu Wenruo
2022-11-14 1:59 ` [PATCH 0/5] btrfs: raid56: destructive RMW fix for RAID5 data profiles Qu Wenruo
2022-11-15 13:24 ` David Sterba
2022-11-16 3:21 ` Qu Wenruo
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=202211150946.Z76SnBqp-lkp@intel.com \
--to=error27@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
--cc=wqu@suse.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;
as well as URLs for NNTP newsgroup(s).