On 9/11/19 11:42 AM, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's > g_auto infrastrcture (and thus whatever the compilers hooks are) to > release it on all exits of the block. > > Note this macro has a variable declaration in, and hence is not in > a while loop. > > Signed-off-by: Dr. David Alan Gilbert > --- > include/qemu/rcu.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/include/qemu/rcu.h b/include/qemu/rcu.h > index 22876d1428..6a25b27d28 100644 > --- a/include/qemu/rcu.h > +++ b/include/qemu/rcu.h > @@ -154,6 +154,18 @@ extern void call_rcu1(struct rcu_head *head, RCUCBFunc *func); > }), \ > (RCUCBFunc *)g_free); > > +typedef char rcu_read_auto_t; Declaring new types ending in _t collides with the namespace reserved by POSIX. While I don't think it will bite us, it's still worth considering if a different name is better. > +static inline void rcu_read_auto_unlock(rcu_read_auto_t *r) > +{ > + rcu_read_unlock(); > +} > + > +G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(rcu_read_auto_t, rcu_read_auto_unlock) > + > +#define RCU_READ_LOCK_AUTO g_auto(rcu_read_auto_t) \ > + _rcu_read_auto = 'x'; \ I'm a bit lost at where _rcu_read_auto is declared. (I could understand if an earlier macro had created that typedef via concatenating _ with rcu_read_auto_t, but making the preprocessor drop _t is not possible. Is this a typo, and if so, why did the compiler not complain?) > + rcu_read_lock(); > + > #ifdef __cplusplus > } > #endif > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org