On 15.02.2022 13:44, Oleksandr Andrushchenko wrote:
> On 15.02.22 13:54, Oleksandr Andrushchenko wrote:
>> On 15.02.22 13:50, Jan Beulich wrote:
>>> On 15.02.2022 12:45, Oleksandr Andrushchenko wrote:
>>>> I'm on your side, I just want to hear that we all agree pcidevs
>>>> needs to be converted into rwlock according with the plan you
>>>> suggested and at least now it seems to be an acceptable solution.
>>> I'd like to express worries though about the conversion of this
>>> recursive lock into an r/w one.
>> Could you please elaborate more on this?
> What if we just do the following:
>
> static spinlock_t _pcidevs_lock = SPIN_LOCK_UNLOCKED;
> static rwlock_t DEFINE_RWLOCK(_pcidevs_rwlock);
>
> void pcidevs_lock(void)
> {
> read_lock(&_pcidevs_rwlock);
> spin_lock_recursive(&_pcidevs_lock);
> }
>
> void pcidevs_unlock(void)
> {
> spin_unlock_recursive(&_pcidevs_lock);
> read_unlock(&_pcidevs_rwlock);
> }
>
> void pcidevs_read_lock(void)
> {
> read_lock(&_pcidevs_rwlock);
> }
>
> void pcidevs_read_unlock(void)
> {
> read_unlock(&_pcidevs_rwlock);
> }
>
> void pcidevs_write_lock(void)
> {
> write_lock(&_pcidevs_rwlock);
> }
>
> void pcidevs_write_unlock(void)
> {
> write_unlock(&_pcidevs_rwlock);
> }
Hmm, this is an interesting idea. Except that I'm not sure in how
far it'll be suitable: read_lock() won't lock out users of just
lock(), so the solution looks tailored to your vPCI use case. Yet
obviously (I think) read_lock() would want to become usable for
e.g. simple list traversal as well, down the road.
Jan
