Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

On 4/11/19, Rick Macklem wrote: > Mateusz Guzik wrote: >>On 4/11/19, Rick Macklem wrote: >>> Hi, >>> >>> I finally got around to looking at what effect replacing pfind_locked() >>> with >>> pfind() has for the NFSv4 client and it is broken. >>> >>> The problem is that the NFS code needs to call

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

Mateusz Guzik wrote: >On 4/11/19, Rick Macklem wrote: >> Hi, >> >> I finally got around to looking at what effect replacing pfind_locked() >> with >> pfind() has for the NFSv4 client and it is broken. >> >> The problem is that the NFS code needs to call some variant of "pfind()" >> while >>

Re: Do the pidhashtbl_locks added by r340742 need to be sx locks?

On 4/11/19, Rick Macklem wrote: > Hi, > > I finally got around to looking at what effect replacing pfind_locked() > with > pfind() has for the NFSv4 client and it is broken. > > The problem is that the NFS code needs to call some variant of "pfind()" > while > holding a mutex lock. The current

Do the pidhashtbl_locks added by r340742 need to be sx locks?

Hi, I finally got around to looking at what effect replacing pfind_locked() with pfind() has for the NFSv4 client and it is broken. The problem is that the NFS code needs to call some variant of "pfind()" while holding a mutex lock. The current _pfind() code uses the pidhashtbl_locks, which are