From: Filipe Manana <fdmanana@kernel.org>
To: kernel test robot <lkp@intel.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
kbuild-all@lists.01.org,
Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH 3/9] btrfs: move the tree mod log code into its own file
Date: Thu, 11 Mar 2021 17:41:32 +0000 [thread overview]
Message-ID: <CAL3q7H4RRn5PWKVRcNWKG5Q-jNxjtp+3Bj2MmExXLM=iNDg9gg@mail.gmail.com> (raw)
In-Reply-To: <202103120146.nWyeg1sH-lkp@intel.com>
On Thu, Mar 11, 2021 at 5:27 PM kernel test robot <lkp@intel.com> wrote:
>
> Hi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on v5.12-rc2]
> [also build test WARNING on next-20210311]
> [cannot apply to kdave/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/fdmanana-kernel-org/btrfs-bug-fixes-for-the-tree-mod-log-and-small-refactorings/20210311-223429
> base: a38fd8748464831584a19438cbb3082b5a2dab15
> config: x86_64-randconfig-m001-20210311 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> smatch warnings:
> fs/btrfs/tree-mod-log.c:286 btrfs_tree_mod_log_insert_move() warn: missing error code 'ret'
> fs/btrfs/tree-mod-log.c:519 btrfs_tree_mod_log_eb_copy() warn: missing error code 'ret'
> fs/btrfs/tree-mod-log.c:577 btrfs_tree_mod_log_free_eb() warn: missing error code 'ret'
No, those are all ok.
For all cases, 'ret' was initialized to 0 when declared, and that's
what we want to return when tree_mod_dont_log() returns true.
>
> vim +/ret +286 fs/btrfs/tree-mod-log.c
>
> 246
> 247 int btrfs_tree_mod_log_insert_move(struct extent_buffer *eb,
> 248 int dst_slot, int src_slot,
> 249 int nr_items)
> 250 {
> 251 struct tree_mod_elem *tm = NULL;
> 252 struct tree_mod_elem **tm_list = NULL;
> 253 int ret = 0;
> 254 int i;
> 255 int locked = 0;
> 256
> 257 if (!tree_mod_need_log(eb->fs_info, eb))
> 258 return 0;
> 259
> 260 tm_list = kcalloc(nr_items, sizeof(struct tree_mod_elem *), GFP_NOFS);
> 261 if (!tm_list)
> 262 return -ENOMEM;
> 263
> 264 tm = kzalloc(sizeof(*tm), GFP_NOFS);
> 265 if (!tm) {
> 266 ret = -ENOMEM;
> 267 goto free_tms;
> 268 }
> 269
> 270 tm->logical = eb->start;
> 271 tm->slot = src_slot;
> 272 tm->move.dst_slot = dst_slot;
> 273 tm->move.nr_items = nr_items;
> 274 tm->op = BTRFS_MOD_LOG_MOVE_KEYS;
> 275
> 276 for (i = 0; i + dst_slot < src_slot && i < nr_items; i++) {
> 277 tm_list[i] = alloc_tree_mod_elem(eb, i + dst_slot,
> 278 BTRFS_MOD_LOG_KEY_REMOVE_WHILE_MOVING, GFP_NOFS);
> 279 if (!tm_list[i]) {
> 280 ret = -ENOMEM;
> 281 goto free_tms;
> 282 }
> 283 }
> 284
> 285 if (tree_mod_dont_log(eb->fs_info, eb))
> > 286 goto free_tms;
> 287 locked = 1;
> 288
> 289 /*
> 290 * When we override something during the move, we log these removals.
> 291 * This can only happen when we move towards the beginning of the
> 292 * buffer, i.e. dst_slot < src_slot.
> 293 */
> 294 for (i = 0; i + dst_slot < src_slot && i < nr_items; i++) {
> 295 ret = tree_mod_log_insert(eb->fs_info, tm_list[i]);
> 296 if (ret)
> 297 goto free_tms;
> 298 }
> 299
> 300 ret = tree_mod_log_insert(eb->fs_info, tm);
> 301 if (ret)
> 302 goto free_tms;
> 303 write_unlock(&eb->fs_info->tree_mod_log_lock);
> 304 kfree(tm_list);
> 305
> 306 return 0;
> 307 free_tms:
> 308 for (i = 0; i < nr_items; i++) {
> 309 if (tm_list[i] && !RB_EMPTY_NODE(&tm_list[i]->node))
> 310 rb_erase(&tm_list[i]->node, &eb->fs_info->tree_mod_log);
> 311 kfree(tm_list[i]);
> 312 }
> 313 if (locked)
> 314 write_unlock(&eb->fs_info->tree_mod_log_lock);
> 315 kfree(tm_list);
> 316 kfree(tm);
> 317
> 318 return ret;
> 319 }
> 320
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Filipe Manana <fdmanana@kernel.org>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH 3/9] btrfs: move the tree mod log code into its own file
Date: Thu, 11 Mar 2021 17:41:32 +0000 [thread overview]
Message-ID: <CAL3q7H4RRn5PWKVRcNWKG5Q-jNxjtp+3Bj2MmExXLM=iNDg9gg@mail.gmail.com> (raw)
In-Reply-To: <202103120146.nWyeg1sH-lkp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]
On Thu, Mar 11, 2021 at 5:27 PM kernel test robot <lkp@intel.com> wrote:
>
> Hi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on v5.12-rc2]
> [also build test WARNING on next-20210311]
> [cannot apply to kdave/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/fdmanana-kernel-org/btrfs-bug-fixes-for-the-tree-mod-log-and-small-refactorings/20210311-223429
> base: a38fd8748464831584a19438cbb3082b5a2dab15
> config: x86_64-randconfig-m001-20210311 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> smatch warnings:
> fs/btrfs/tree-mod-log.c:286 btrfs_tree_mod_log_insert_move() warn: missing error code 'ret'
> fs/btrfs/tree-mod-log.c:519 btrfs_tree_mod_log_eb_copy() warn: missing error code 'ret'
> fs/btrfs/tree-mod-log.c:577 btrfs_tree_mod_log_free_eb() warn: missing error code 'ret'
No, those are all ok.
For all cases, 'ret' was initialized to 0 when declared, and that's
what we want to return when tree_mod_dont_log() returns true.
>
> vim +/ret +286 fs/btrfs/tree-mod-log.c
>
> 246
> 247 int btrfs_tree_mod_log_insert_move(struct extent_buffer *eb,
> 248 int dst_slot, int src_slot,
> 249 int nr_items)
> 250 {
> 251 struct tree_mod_elem *tm = NULL;
> 252 struct tree_mod_elem **tm_list = NULL;
> 253 int ret = 0;
> 254 int i;
> 255 int locked = 0;
> 256
> 257 if (!tree_mod_need_log(eb->fs_info, eb))
> 258 return 0;
> 259
> 260 tm_list = kcalloc(nr_items, sizeof(struct tree_mod_elem *), GFP_NOFS);
> 261 if (!tm_list)
> 262 return -ENOMEM;
> 263
> 264 tm = kzalloc(sizeof(*tm), GFP_NOFS);
> 265 if (!tm) {
> 266 ret = -ENOMEM;
> 267 goto free_tms;
> 268 }
> 269
> 270 tm->logical = eb->start;
> 271 tm->slot = src_slot;
> 272 tm->move.dst_slot = dst_slot;
> 273 tm->move.nr_items = nr_items;
> 274 tm->op = BTRFS_MOD_LOG_MOVE_KEYS;
> 275
> 276 for (i = 0; i + dst_slot < src_slot && i < nr_items; i++) {
> 277 tm_list[i] = alloc_tree_mod_elem(eb, i + dst_slot,
> 278 BTRFS_MOD_LOG_KEY_REMOVE_WHILE_MOVING, GFP_NOFS);
> 279 if (!tm_list[i]) {
> 280 ret = -ENOMEM;
> 281 goto free_tms;
> 282 }
> 283 }
> 284
> 285 if (tree_mod_dont_log(eb->fs_info, eb))
> > 286 goto free_tms;
> 287 locked = 1;
> 288
> 289 /*
> 290 * When we override something during the move, we log these removals.
> 291 * This can only happen when we move towards the beginning of the
> 292 * buffer, i.e. dst_slot < src_slot.
> 293 */
> 294 for (i = 0; i + dst_slot < src_slot && i < nr_items; i++) {
> 295 ret = tree_mod_log_insert(eb->fs_info, tm_list[i]);
> 296 if (ret)
> 297 goto free_tms;
> 298 }
> 299
> 300 ret = tree_mod_log_insert(eb->fs_info, tm);
> 301 if (ret)
> 302 goto free_tms;
> 303 write_unlock(&eb->fs_info->tree_mod_log_lock);
> 304 kfree(tm_list);
> 305
> 306 return 0;
> 307 free_tms:
> 308 for (i = 0; i < nr_items; i++) {
> 309 if (tm_list[i] && !RB_EMPTY_NODE(&tm_list[i]->node))
> 310 rb_erase(&tm_list[i]->node, &eb->fs_info->tree_mod_log);
> 311 kfree(tm_list[i]);
> 312 }
> 313 if (locked)
> 314 write_unlock(&eb->fs_info->tree_mod_log_lock);
> 315 kfree(tm_list);
> 316 kfree(tm);
> 317
> 318 return ret;
> 319 }
> 320
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
next prev parent reply other threads:[~2021-03-11 17:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 14:31 [PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings fdmanana
2021-03-11 14:31 ` [PATCH 1/9] btrfs: fix race when cloning extent buffer during rewind of an old root fdmanana
2021-03-11 14:31 ` [PATCH 2/9] btrfs: always pin deleted leaves when there are active tree mod log users fdmanana
2021-03-15 19:28 ` David Sterba
2021-03-16 11:49 ` Filipe Manana
2021-03-16 11:54 ` Johannes Thumshirn
2021-03-11 14:31 ` [PATCH 3/9] btrfs: move the tree mod log code into its own file fdmanana
2021-03-11 17:26 ` kernel test robot
2021-03-11 17:26 ` kernel test robot
2021-03-11 17:41 ` Filipe Manana [this message]
2021-03-11 17:41 ` Filipe Manana
2021-03-12 8:50 ` Anand Jain
2021-03-11 14:31 ` [PATCH 4/9] btrfs: use booleans where appropriate for the tree mod log functions fdmanana
2021-03-12 12:44 ` Anand Jain
2021-03-11 14:31 ` [PATCH 5/9] btrfs: use a bit to track the existence of tree mod log users fdmanana
2021-03-13 7:26 ` Wang Yugui
2021-03-15 9:52 ` Filipe Manana
2021-03-11 14:31 ` [PATCH 6/9] btrfs: use the new bit BTRFS_FS_TREE_MOD_LOG_USERS at btrfs_free_tree_block() fdmanana
2021-03-11 14:31 ` [PATCH 7/9] btrfs: remove unnecessary leaf check at btrfs_tree_mod_log_free_eb() fdmanana
2021-03-11 14:31 ` [PATCH 8/9] btrfs: add and use helper to get lowest sequence number for the tree mod log fdmanana
2021-03-11 14:31 ` [PATCH 9/9] btrfs: update debug message when checking seq number of a delayed ref fdmanana
2021-03-16 16:58 ` [PATCH 0/9] btrfs: bug fixes for the tree mod log and small refactorings David Sterba
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='CAL3q7H4RRn5PWKVRcNWKG5Q-jNxjtp+3Bj2MmExXLM=iNDg9gg@mail.gmail.com' \
--to=fdmanana@kernel.org \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=fdmanana@suse.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=lkp@intel.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.