On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote:
>
> I am trying to debug a leak of a shared vnode lock and I noticed that
> there is no check for td_lk_slocks in userret. There are checks for
> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario
> where a thread
On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote:
> On 01/08/2019 22:51, Ian Lepore wrote:
> > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote:
> >> On 01/08/2019 19:12, Warner Losh wrote:
> >>>
> >>>
> >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes
> >>>
On 12/08/2019 13:49, Mateusz Guzik wrote:
> On 8/12/19, Andriy Gapon wrote:
>>
>> I am trying to debug a leak of a shared vnode lock and I noticed that
>> there is no check for td_lk_slocks in userret. There are checks for
>> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid
On 12/08/2019 13:57, Andriy Gapon wrote:
> On 12/08/2019 13:45, Konstantin Belousov wrote:
>> On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote:
>>> I guess that there is more than one way to achieve what I want or
>>> something similar to that.
>>> Rather than "expend words" on a
On 8/12/19, Andriy Gapon wrote:
>
> I am trying to debug a leak of a shared vnode lock and I noticed that
> there is no check for td_lk_slocks in userret. There are checks for
> td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario
> where a thread is allowed to retain a shared
On 12/08/2019 13:45, Konstantin Belousov wrote:
> On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote:
>> I guess that there is more than one way to achieve what I want or
>> something similar to that.
>> Rather than "expend words" on a theoretical discussion, I decided to do
>> this:
On 01/08/2019 22:51, Ian Lepore wrote:
> On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote:
>> On 01/08/2019 19:12, Warner Losh wrote:
>>>
>>>
>>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes
>>> mailto:freebsd-...@gndrsh.dnsmgr.net>>
>>> wrote:
>>>
>>> >
>>> > Is it possible in an
I am trying to debug a leak of a shared vnode lock and I noticed that
there is no check for td_lk_slocks in userret. There are checks for
td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario
where a thread is allowed to retain a shared lock manager lock across
system calls.
On 8/9/19 8:56 PM, Clay Daniels Jr. wrote:
I was eager to load the new 13.0 Current snapshot yesterday as I wanted to
play with the new FUSE tools. I was running 13.0 Current r350491 from last
week and everything was going great. So last night, a little late I guess,
I wiped the older install
