All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Hawkins Jiawei <yin31149@gmail.com>
Cc: Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
	18801353760@163.com, linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	nathan@kernel.org, ndesaulniers@google.com,
	syzbot+dde7e853812ed57835ea@syzkaller.appspotmail.com,
	syzkaller-bugs@googlegroups.com, trix@redhat.com
Subject: Re: [PATCH] btrfs: update bytes_may_use in btrfs_free_reserved_bytes()
Date: Mon, 31 Oct 2022 11:11:58 -0400	[thread overview]
Message-ID: <Y1/lvgHE4JKvxsi8@localhost.localdomain> (raw)
In-Reply-To: <20221030162223.25970-1-yin31149@gmail.com>

On Mon, Oct 31, 2022 at 12:22:24AM +0800, Hawkins Jiawei wrote:
> Syzkaller reports warning as follows:
> =====================================
> WARNING: CPU: 0 PID: 3612 at fs/btrfs/space-info.h:122
>   btrfs_space_info_free_bytes_may_use fs/btrfs/space-info.h:154 [inline]
> WARNING: CPU: 0 PID: 3612 at fs/btrfs/space-info.h:122
>   block_rsv_release_bytes fs/btrfs/block-rsv.c:151 [inline]
> WARNING: CPU: 0 PID: 3612 at fs/btrfs/space-info.h:122
>   btrfs_block_rsv_release+0x5d1/0x730 fs/btrfs/block-rsv.c:295
> Modules linked in:
> [...]
> RIP: 0010:btrfs_space_info_update_bytes_may_use
>   fs/btrfs/space-info.h:122 [inline]
> RIP: 0010:btrfs_space_info_free_bytes_may_use
>   fs/btrfs/space-info.h:154 [inline]
> RIP: 0010:block_rsv_release_bytes
>   fs/btrfs/block-rsv.c:151 [inline]
> RIP: 0010:btrfs_block_rsv_release+0x5d1/0x730
>   fs/btrfs/block-rsv.c:295
> [...]
> Call Trace:
>  <TASK>
>  btrfs_release_global_block_rsv+0x2f/0x250 fs/btrfs/block-rsv.c:463
>  btrfs_free_block_groups+0xb67/0xfd0 fs/btrfs/block-group.c:4053
>  close_ctree+0x6c5/0xbde fs/btrfs/disk-io.c:4710
>  generic_shutdown_super+0x130/0x310 fs/super.c:491
>  kill_anon_super+0x36/0x60 fs/super.c:1085
>  btrfs_kill_super+0x3d/0x50 fs/btrfs/super.c:2441
>  deactivate_locked_super+0xa7/0xf0 fs/super.c:331
>  cleanup_mnt+0x4ce/0x560 fs/namespace.c:1186
>  task_work_run+0x146/0x1c0 kernel/task_work.c:177
>  ptrace_notify+0x29a/0x340 kernel/signal.c:2354
>  ptrace_report_syscall include/linux/ptrace.h:420 [inline]
>  ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline]
>  syscall_exit_work+0x8c/0xe0 kernel/entry/common.c:249
>  syscall_exit_to_user_mode_prepare+0x63/0xc0 kernel/entry/common.c:276
>  __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline]
>  syscall_exit_to_user_mode+0xa/0x60 kernel/entry/common.c:294
>  do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
>  [...]
>  </TASK>
> =====================================
> 
> In btrfs_new_extent_direct(), kernel will reserves space for extent
> by btrfs_reserve_extent(), and frees those space by
> btrfs_free_reserved_extent() if btrfs_create_dio_extent() fails.
> 
> Yet the problem is that, it may not update the space
> info correctly. To be more specific, kernel will
> converts space from ->bytes_may_use to ->bytes_reserved, in
> btrfs_add_reserved_bytes() when reserving space.
> But when freeing those space in btrfs_free_reserved_bytes(),
> kernel does not convert space from ->bytes_reserved back to
> ->bytes_may_use, which triggers the above warning.
> 
> This patch solves it by converting space from ->bytes_reserved
> back to ->bytes_may_use in btrfs_free_reserved_bytes().
> 

This isn't correct.  I haven't looked at the code yet, but reservations go into
->bytes_may_use, and then when we reserve the space we subtract the reservation
from ->bytes_may_use and add it to ->bytes_reserved.  If we free the reserved
extent we only have to update ->bytes_reserved.  What may be happening here is
we're failing to free the rest of our ->bytes_may_use resrvation, and that part
needs to be addressed.  This fix as it stands however is incorrect.  Thanks,

Josef

  reply	other threads:[~2022-10-31 15:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-30 16:22 [PATCH] btrfs: update bytes_may_use in btrfs_free_reserved_bytes() Hawkins Jiawei
2022-10-31 15:11 ` Josef Bacik [this message]
2022-10-31 15:44   ` Hawkins Jiawei

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=Y1/lvgHE4JKvxsi8@localhost.localdomain \
    --to=josef@toxicpanda.com \
    --cc=18801353760@163.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=syzbot+dde7e853812ed57835ea@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=trix@redhat.com \
    --cc=yin31149@gmail.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.