On Tue, Oct 21, 2025 at 1:05 AM Vladimir Sementsov-Ogievskiy
<[email protected]> wrote:
>
> > This can cause races with qmp query-named-block nodes as described in
> > #3149.
>
> Hmm. But why it lead to segfault? Ok, children kept in global_bdrv_states.
> and referenced by the job itself (as I can assume from the patch). What's
> wrong with the state, so we went in segfault?
My understanding is that when bdrv_replace_node_common is called with
`detach_subchain=true` then `children` is cleared. Here's a trace from
stream_clean (line numbers approximate on v10.1.0):
- stream_clean (block/stream.c L131)
- bdrv_cor_filter_drop (block/copy-on-read.c L274)
- bdrv_drop_filter (block.c L5466)
- bdrv_replace_node_common (block.c L5404)
(called with `detach_subchain=true`)
- bdrv_remove_child (block.c L5335)
- bdrv_replace_child_tran (block.c L2489)
- bdrv_replace_child_noperm (block.c L2944)
- bdrv_child_cb_detach (BdrvChildClass.detach) (block.c L1492)
I can observe that children.lh_first == NULL in gdb.
> Also, would be good to write the segfault backtrace here, for someone
> to search the fix through git.
I'll include the backtrace from #3149 in the commit message of my next
submission.
Thanks so much for the review!
~Wesley
