Re: [Xen-devel] [PATCH v2] rwlock: allow recursive read locking when already locked in write mode

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien@xen.org>
Cc: "Jürgen Groß" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.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>,
	"Jan Beulich" <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2] rwlock: allow recursive read locking when already locked in write mode
Date: Fri, 21 Feb 2020 15:59:12 +0100	[thread overview]
Message-ID: <20200221145912.GE4679@Air-de-Roger> (raw)
In-Reply-To: <270e3f03-a1e8-1cf8-af82-e7fed515985a@xen.org>

On Fri, Feb 21, 2020 at 02:56:20PM +0000, Julien Grall wrote:
> 
> 
> On 21/02/2020 14:49, Roger Pau Monné wrote:
> > On Fri, Feb 21, 2020 at 03:41:59PM +0100, Jan Beulich wrote:
> > > Because you need to invoke smp_processor_id() to calculate the value
> > > to use in the subtraction. I'm not meaning to say I'm entirely
> > > opposed (seeing how much of a discussion we're having), but the
> > > "simple write of zero" approach is certainly appealing.
> > 
> > Well, we could avoid the smp_processor_id() call and instead use:
> > 
> > atomic_sub(atomic_read(&lock->cnts) & 0xffff, &lock->cnts);
> 
> AFAICT, this would not be safe because the top 16-bit may change behind your
> back (via a read_lock).

Why not? We don't touch the top 16bits in any way, the subtraction
only affects the low 16bits and is done in an atomic manner.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel