On Mon, Jul 10, 2017 at 06:06:32PM +0200, Paolo Bonzini wrote:
> On 10/07/2017 17:52, Stefan Hajnoczi wrote:
> > On Thu, Jul 06, 2017 at 06:38:20PM +0200, Paolo Bonzini wrote:
> >> void notifier_list_notify(NotifierList *list, void *data)
> >> {
> >> Notifier *notifier, *next;
> >>
> >> - QLIST_FOREACH_SAFE(notifier, &list->notifiers, node, next) {
> >> + QLIST_FOREACH_SAFE_RCU(notifier, &list->notifiers, node, next) {
> >> notifier->notify(notifier, data);
> >> }
> >> }
> >
> > Who calls rcu_read_lock() or is it unnecessary?
>
> It depends.
>
> If the notifier is really only used within the BQL, it's unnecessary.
>
> If the notifier's readers want to protect the notifier with RCU, it's up
> to the callers indeed.
>
> However, RCU accessors can also be used with any API that has the same
> contract as synchronize_rcu, i.e. it stops until all concurrent readers
> complete, no matter how "readers" are defined.
>
> In the next patch, for example, synchronize_rcu's role is taken by
> bdrv_drain (which is a superset of synchronize_rcu, since it also blocks
> new incoming readers).
>
> For a similar example in Linux, see drivers/vhost/net.c. It replaces
> rcu_read_lock/unlock with "always run readers for a workqueue", and
> synchronize_rcu with vhost_poll_flush (which calls vhost_work_flush).Thanks for the explanation. I see how that is safe.
signature.asc
Description: PGP signature
