On Fri, Jul 2, 2021 at 9:52 AM Nikolay Borisov [off-list ref] wrote:

On 29.06.21 г. 16:43, fdmanana@kernel.org wrote:

quoted

|However that commit also introduced a deadlock where a task in phase 1
of the chunk allocation waited for another task that had allocated a
system chunk to finish its phase 2, but that other task was waiting on
an extent buffer lock held by the first task, therefore resulting in
both tasks not making any progress. That change was later reverted by a
patch with the subject "btrfs: fix deadlock with concurrent chunk
allocations involving system chunks", since there is no simple and short
solution to address it and the deadlock is relatively easy to trigger on
zoned filesystems, while the system chunk array exhaustion is not so
common. |

nit: Wouldn't the deadlock constitute of the task in phase1, holding
chunk_mutex sleep on chunk_reserve_wait and having set
space_info->chunk_alloc = 1 and this in turn causes task in phase 2 to
to deadlock on chunk_mutex in btrfs_alloc_chunk due to
btrfs_create_pending_block_groups (phase2) happening with chunk_mutex
unlocked BUT chunk_reserve_wait still not woken up ? Your previous patch
explains this situation but this paragraph seems to mention extent
buffer locks which I don't think are involved in the deadlock.

Yes, that's one of the cases, when both tasks are allocating chunks of
the same type.
The other case is regarding extent buffer locks as mentioned there
Indeed I didn't go into too much detail there, as one patch refers to
the other and avoids repeating too much.