[GEDI] [PATCH 00/15] Protect the block layer with a rwlock: part 3
Emanuele Giuseppe Esposito
eesposit at redhat.com
Fri Nov 18 15:01:26 UTC 2022
Am 18/11/2022 um 11:57 schrieb Paolo Bonzini:
> On 11/16/22 15:07, Emanuele Giuseppe Esposito wrote:
>> Here we introduce generated_co_wrapper_simple, a simplification of
>> g_c_w that
>> only considers the case where the caller is not in a coroutine.
>> This simplifies and clarifies a lot when the caller is a coroutine or
>> not, and
>> in the future will hopefully replace g_c_w.
> This is a good idea!
> Just one thing, though it belongs more in the two series which
> introduced generated_co_wrapper_simple and generated_co_wrapper_blk - I
> would make this the "official" wrapper. So perhaps:
> - generated_co_wrapper_simple -> coroutine_wrapper
> - generated_co_wrapper_blk -> coroutine_wrapper_mixed
> - generated_co_wrapper -> coroutine_wrapper_mixed_bdrv
> ? It is not clear to me yet if you will have bdrv_* functions that take
> the rdlock as well - in which case however coroutine_wrapper_bdrv would
> not be hard to add.
Why _mixed? I thought _blk was a nice name to identify only the blk_*
API that have this slightly different behavior (ie do not take the
No, I don't think there will be bdrv_* functions that will behave as
blk_*, if that's what you mean.
Regarding the bdrv_* functions in general, there are a couple of
additional places (which should be all in the main loop) where we need
to use assert_bdrv_grapg_readable. In those places we theoretically need
nothing, but if we use the automatic TSA locking checker that is being
tested by kevin, we need some sort of "placeholder" so that cc/gcc (I
don't remember anymore which) won't throw false positives.
> Even without looking at the lock, the three series are going in the
> right direction of ultimately having more "simple" coroutine wrappers at
> the blk_* level and more coroutine functions (ultimately less wrappers,
> too) at the bdrv_* level.
More information about the integration