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