Re: [PATCH v10 13/21] job: detect change of aiocontext within job coroutine

Am 17/08/2022 um 10:34 schrieb Kevin Wolf: > Am 16.08.2022 um 17:09 hat Emanuele Giuseppe Esposito geschrieben: >> >> >> Am 05/08/2022 um 10:37 schrieb Kevin Wolf: >>> Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: From: Paolo Bonzini We want to make sure

Re: [PATCH v10 13/21] job: detect change of aiocontext within job coroutine

Am 16.08.2022 um 17:09 hat Emanuele Giuseppe Esposito geschrieben: > > > Am 05/08/2022 um 10:37 schrieb Kevin Wolf: > > Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: > >> From: Paolo Bonzini > >> > >> We want to make sure access of job->aio_context is always done > >> under

Re: [PATCH v10 13/21] job: detect change of aiocontext within job coroutine

Am 05/08/2022 um 10:37 schrieb Kevin Wolf: > Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: >> From: Paolo Bonzini >> >> We want to make sure access of job->aio_context is always done >> under either BQL or job_mutex. > > Is this the goal of this series? If so, it would

Re: [PATCH v10 13/21] job: detect change of aiocontext within job coroutine

Am 25.07.2022 um 09:38 hat Emanuele Giuseppe Esposito geschrieben: > From: Paolo Bonzini > > We want to make sure access of job->aio_context is always done > under either BQL or job_mutex. Is this the goal of this series? If so, it would have been useful to state somewhere more obvious, because

[PATCH v10 13/21] job: detect change of aiocontext within job coroutine

From: Paolo Bonzini We want to make sure access of job->aio_context is always done under either BQL or job_mutex. The problem is that using aio_co_enter(job->aiocontext, job->co) in job_start and job_enter_cond makes the coroutine immediately resume, so we can't hold the job lock. And caching it