From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: quintela@redhat.com, berrange@redhat.com, qemu-devel@nongnu.org,
ehabkost@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 1/5] rcu: Add automatically released rcu_read_lock variant
Date: Thu, 12 Sep 2019 18:45:24 +0100 [thread overview]
Message-ID: <20190912174524.GD2722@work-vm> (raw)
In-Reply-To: <e8802180-3c9a-97b9-dae1-5e07d7843de3@redhat.com>
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 11/09/19 21:06, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >
> > RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> > g_auto infrastructure (and thus whatever the compiler's hooks are) to
> > release it on all exits of the block.
> >
> > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > ---
> > include/qemu/rcu.h | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/include/qemu/rcu.h b/include/qemu/rcu.h
> > index 22876d1428..8768a7b60a 100644
> > --- a/include/qemu/rcu.h
> > +++ b/include/qemu/rcu.h
> > @@ -154,6 +154,24 @@ extern void call_rcu1(struct rcu_head *head, RCUCBFunc *func);
> > }), \
> > (RCUCBFunc *)g_free);
> >
> > +typedef void RCUReadAuto;
> > +static inline RCUReadAuto *rcu_read_auto_lock(void)
> > +{
> > + rcu_read_lock();
> > + /* Anything non-NULL causes the cleanup function to be called */
> > + return (void *)0x1;
>
> Doesn't this cause a warning (should be "(void *)(uintptr_t)1" instead)?
Apparently not, but I'll change it anyway.
> > +}
> > +
> > +static inline void rcu_read_auto_unlock(RCUReadAuto *r)
> > +{
> > + rcu_read_unlock();
> > +}
> > +
> > +G_DEFINE_AUTOPTR_CLEANUP_FUNC(RCUReadAuto, rcu_read_auto_unlock)
> > +
> > +#define RCU_READ_LOCK_AUTO \
> > + g_autoptr(RCUReadAuto) _rcu_read_auto = rcu_read_auto_lock()
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> >
>
> Is it possible to make this a scope, like
>
> WITH_RCU_READ_LOCK() {
> }
>
> ? Perhaps something like
>
> #define WITH_RCU_READ_LOCK() \
> WITH_RCU_READ_LOCK_(_rcu_read_auto##__COUNTER__)
>
> #define WITH_RCU_READ_LOCK_(var) \
> for (g_autoptr(RCUReadAuto) var = rcu_read_auto_lock();
> (var); rcu_read_auto_unlock(), (var) = NULL)
>
> where the dummy variable doubles as an execute-once guard and the gauto
> cleanup is still used in case of a "break". I'm not sure if the above
> raises a warning because of the variable declaration inside the for
> loop, though.
Yes, that works - I'm not seeing any warnings.
Do you think it's best to use the block version for all cases
or to use the non-block version by taste?
The block version is quite nice, but that turns most of the patches
into 'indent everything'.
Dave
> Thanks,
>
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-09-12 17:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-11 19:06 [Qemu-devel] [PATCH v2 0/5] Automatic RCU read unlock Dr. David Alan Gilbert (git)
2019-09-11 19:06 ` [Qemu-devel] [PATCH v2 1/5] rcu: Add automatically released rcu_read_lock variant Dr. David Alan Gilbert (git)
2019-09-12 9:35 ` Daniel P. Berrangé
2019-09-12 12:30 ` Paolo Bonzini
2019-09-12 17:45 ` Dr. David Alan Gilbert [this message]
2019-09-13 7:13 ` Paolo Bonzini
2019-09-13 10:24 ` Dr. David Alan Gilbert
2019-09-13 10:29 ` Paolo Bonzini
2019-09-11 19:06 ` [Qemu-devel] [PATCH v2 2/5] migration: Use automatic rcu_read unlock in ram.c Dr. David Alan Gilbert (git)
2019-09-12 9:37 ` Daniel P. Berrangé
2019-09-11 19:06 ` [Qemu-devel] [PATCH v2 3/5] migration: Use automatic rcu_read unlock in rdma.c Dr. David Alan Gilbert (git)
2019-09-12 9:37 ` Daniel P. Berrangé
2019-09-11 19:06 ` [Qemu-devel] [PATCH v2 4/5] rcu: Use automatic rc_read unlock in core memory/exec code Dr. David Alan Gilbert (git)
2019-09-12 9:38 ` Daniel P. Berrangé
2019-09-11 19:06 ` [Qemu-devel] [PATCH v2 5/5] migration: Missing rcu_read_unlock Dr. David Alan Gilbert (git)
2019-09-12 9:38 ` Daniel P. Berrangé
2019-09-12 12:32 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190912174524.GD2722@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).