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 s
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
>> holdin
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 _pf
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 "
(bcc -current and -stable for more audience)
FreeBSD CI Weekly Report 2019-04-07
===
Here is a summary of the FreeBSD Continuous Integration results for
the period from 2019-04-01 to 2019-04-07.
During this period, we have:
* 1841 builds (96% passed, 4% failed) w
> In message <19ca3a5d-4e41-4f17-a788-b9545f104...@gmail.com>, "Enji
> Cooper (yane
> urabeya)" writes:
> >
> > > On Apr 9, 2019, at 21:51, Enji Cooper wrote:
> >
> > ???
> >
> > > CCing crees@, the author of r346017, for context. I will file a PR soon
> > > if
> > one hasn???t already been fi
