From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Jürgen Groß" <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
Date: Thu, 20 Feb 2020 16:17:34 +0100 [thread overview]
Message-ID: <20200220151734.GM4679@Air-de-Roger> (raw)
In-Reply-To: <0a3a762e-9a0d-7395-d3c4-aca07c366979@suse.com>
On Thu, Feb 20, 2020 at 04:02:55PM +0100, Jan Beulich wrote:
> On 20.02.2020 15:11, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> >> Another option is to use the recurse_cpu field of the
> >> associated spin lock: The field is used for recursive locks
> >> only, and hence the only conflict would be with
> >> _spin_is_locked(), which we don't (and in the future then
> >> also shouldn't) use on this lock.
> >
> > I looked into that also, but things get more complicated AFAICT, as it's
> > not possible to atomically fetch the state of the lock and the owner
> > CPU at the same time. Neither you could set the LOCKED bit and the CPU
> > at the same time.
>
> There's no need to atomically fetch both afaics: The field is
> valid only if the LOCKED bit is set. And when reading the
> field you only care about the value being equal to
> smp_processor_id(), i.e. it is fine to set LOCKED before
> updating the CPU field on lock, and to reset the CPU field to
> SPINLOCK_NO_CPU (or whatever it's called) before clearing
> LOCKED.
Yes that would require the usage of a sentinel value as 0 would be a
valid processor ID.
I would try to refrain from (abu)sing internal spinlock fields, as I
think we can solve this just by using the cnts field on the current
rwlock implementation.
What issue do you have in mind that would prevent storing the CPU
write locked in the cnts field?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-02-20 15:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 12:02 [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode Roger Pau Monne
2020-02-20 12:48 ` Jan Beulich
2020-02-20 14:11 ` Roger Pau Monné
2020-02-20 14:23 ` Jürgen Groß
2020-02-20 14:38 ` Roger Pau Monné
2020-02-20 15:11 ` Jan Beulich
2020-02-20 15:20 ` Roger Pau Monné
2020-02-20 15:52 ` Jan Beulich
2020-02-20 15:02 ` Jan Beulich
2020-02-20 15:17 ` Roger Pau Monné [this message]
2020-02-20 15:50 ` Jan Beulich
2020-02-20 15:57 ` Roger Pau Monné
2020-02-20 16:00 ` Jürgen Groß
2020-02-20 16:54 ` Roger Pau Monné
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=20200220151734.GM4679@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.