On Tue, Feb 25, 2025 at 06:09:35PM +0800, Alan Huang wrote:
> This fixes two deadlocks:
>
> 1.pcpu_alloc_mutex involved one as pointed by syzbot[1]
> 2.recursion deadlock.
>
> The root cause is that we hold the bc lock during alloc_percpu, fix it
> by following the pattern used by __btree_node_me
This fixes two deadlocks:
1.pcpu_alloc_mutex involved one as pointed by syzbot[1]
2.recursion deadlock.
The root cause is that we hold the bc lock during alloc_percpu, fix it
by following the pattern used by __btree_node_mem_alloc().
[1] https://lore.kernel.org/all/66f97d9a.050a0220.6bad9.001d..
On Thu, Jan 30, 2025 at 02:17:44AM +0900, Jeongjun Park wrote:
> In the previous commit b3d82c2f2761, code was added to prevent journal
> sequence
> overflow. Among them, the code added to journal_entry_open() uses the
> bch2_fs_fatal_err_on() function to handle errors.
>
> However, __journal_res
In the previous commit b3d82c2f2761, code was added to prevent journal sequence
overflow. Among them, the code added to journal_entry_open() uses the
bch2_fs_fatal_err_on() function to handle errors.
However, __journal_res_get() , which calls journal_entry_open() , calls
journal_entry_open() while
On Fri, Jun 21, 2024 at 05:34:23PM +0800, Lizhi Xu wrote:
> [Syz reported]
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&c->btree_root_lock){+.+.}-{3:3}:
>lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
>__mutex_lock_common kernel/locking/mutex.c:608 [in
[Syz reported]
the existing dependency chain (in reverse order) is:
-> #1 (&c->btree_root_lock){+.+.}-{3:3}:
lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
__mutex_lock_common kernel/locking/mutex.c:608 [inline]
__mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752
