Good
Ajuz
On 8/14/24 23:12, Patrick Leis wrote:
I would go with your aio_wait_bh_oneshot suggestion. Please consider
adding it to QEMU as I pointed above. I can send a patch.
Hey - this is an important race condition to resolve, can we get some
attention back on this patchset please. It's pressi
On Thu, Jun 27, 2024 at 10:55 AM Roman Kiryanov wrote:
> Paolo, thank you for your comments.
>
> On Thu, Jun 27, 2024 at 10:16 AM Paolo Bonzini
> wrote:
> > I think the easiest options would be:
> >
> > 1) if possible, allocate the timer and the callbackState statically in
> > the device.
>
> I
Paolo, thank you for your comments.
On Thu, Jun 27, 2024 at 10:16 AM Paolo Bonzini wrote:
> I think the easiest options would be:
>
> 1) if possible, allocate the timer and the callbackState statically in
> the device.
I think this assumption is not good for both QEMU and us.
> 2) use "aio_wait
On Thu, Jun 27, 2024 at 6:12 PM Roman Kiryanov wrote:
>
> On Thu, Jun 27, 2024 at 6:27 AM Paolo Bonzini wrote:
> >
> > On Thu, Jun 27, 2024 at 2:32 AM Roman Kiryanov wrote:
> > > +if (qatomic_read(&ts->cb_running)) {
> > > +qemu_event_wait(&timer_list->timers_done_ev);
> > >
On Thu, Jun 27, 2024 at 6:27 AM Paolo Bonzini wrote:
>
> On Thu, Jun 27, 2024 at 2:32 AM Roman Kiryanov wrote:
> > +if (qatomic_read(&ts->cb_running)) {
> > +qemu_event_wait(&timer_list->timers_done_ev);
> > +}
>
> qemu_event_wait() already has the right atomic magic,
On Thu, Jun 27, 2024 at 2:32 AM Roman Kiryanov wrote:
> +if (qatomic_read(&ts->cb_running)) {
> +qemu_event_wait(&timer_list->timers_done_ev);
> +}
qemu_event_wait() already has the right atomic magic, and
ts->cb_running is both redundant (in general), and I think racy
`timerlist_run_timers` provides no mechanism to
make sure the data pointed by `opaque` is valid
when calling timer's callback: there could be
another thread running which is destroying
timer's opaque data.
With this change `timer_del` becomes blocking if
timer's callback is running and it will be
