[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about block graph lock limitation with generated co-wrappers
From: |
Fiona Ebner |
Subject: |
Question about block graph lock limitation with generated co-wrappers |
Date: |
Tue, 26 Mar 2024 11:58:02 +0100 |
User-agent: |
Mozilla Thunderbird |
Hi,
we have a custom block driver downstream, which currently calls
bdrv_get_info() (for its file child) in the bdrv_refresh_limits()
callback. However, with graph locking, this doesn't work anymore.
AFAICT, the reason is the following:
The block driver has a backing file option.
During initialization, in bdrv_set_backing_hd(), the graph lock is
acquired exclusively.
Then the bdrv_refresh_limits() callback is invoked.
Now bdrv_get_info() is called, which is a generated co-wrapper.
The bdrv_co_get_info_entry() function tries to acquire the graph lock
for reading, sees that has_writer is true and so the coroutine will be
put to wait, leading to a deadlock.
For my specific case, I can move the bdrv_get_info() call to bdrv_open()
as a workaround. But I wanted to ask if there is a way to make generated
co-wrappers inside an exclusively locked section work? And if not, could
we introduce/extend the annotations, so the compiler can catch this kind
of issue, i.e. calling a generated co-wrapper while in an exclusively
locked section?
Best Regards,
Fiona
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Question about block graph lock limitation with generated co-wrappers,
Fiona Ebner <=