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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.02.2020 16:17, Roger Pau Monné wrote:
> 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?

The reduction of the number of bits used for other purposes.

Jan

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