On Wed, Nov 26, 2014 at 05:15:44PM +0800, Ming Lei wrote: > On Wed, Nov 26, 2014 at 12:18 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > >> > >> You mean the abort BH may not have chance to run before its deletion > >> in the detach callback? > > > > Exactly. Any time you schedule a BH you need to be aware of things that > > may happen before the BH is invoked. > > > >> If so, bdrv_drain_all() from bdrv_set_aio_context() should have > >> handled the pending BH, right? > > > > I'm not sure if it's good to make subtle assumptions like that. If the > > code changes they will break. > > IMO, that should be the purpose of bdrv_drain_all(), at least from > its comment: > > /* ensure there are no in-flight requests */ > > If it changes in future, the general problem has to be considered. > > > Since it is very easy to protect against this case (the code I posted > > before), it seems worthwhile to be on the safe side. > > Given there hasn't the potential problem in current tree, could you > agree on merging it first? > > BTW, there isn't sort of handling for 'completion_bh' of linux aio too, :-)
That's incorrect, completion_bh is protected: void laio_attach_aio_context(void *s_, AioContext *new_context) { struct qemu_laio_state *s = s_; s->completion_bh = aio_bh_new(new_context, qemu_laio_completion_bh, s); aio_set_event_notifier(new_context, &s->e, qemu_laio_completion_cb); ^---- this will reschedule completion_bh if s->e has events pending I am asking for a one-line if statement to avoid introducing a subtle assumption that would be a pain to debug in the future. It's so easy to add that I'm against merging the patch without this protection.
pgp4dBoUojlCk.pgp
Description: PGP signature