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);
}
1. This way most of the code continues to use pcidevs_{lock|unlock}.
2. We need to change writers, those which can add /remove pdev, to use
pcidevs_write_{un}lock
3. Those, which do not modify pdevs (vpci_{read|write}), will use
pcidevs_read_lock
4. We do not introduce d->vpci_rwlock and use pcidevs_{read|write}_lock
as vpci doesn't seem to need to acquire _pcidevs_lock + we use pdev->vpci->lock
as it is now
Is this something which may address your worries?
Thank you,
Oleksandr
