> On Jul 18, 2022, at 2:03 AM, Taylor R Campbell
> wrote:
>
>> Date: Sun, 17 Jul 2022 12:54:56 -0700
>> From: Jason Thorpe
>>
>> And another new version. This:
>>
>> ==> Creates a knote_impl structure that's private to kern_event.c
>> that has the new lock. I took the opportunity to m
> Date: Sun, 17 Jul 2022 12:54:56 -0700
> From: Jason Thorpe
>
> And another new version. This:
>
> ==> Creates a knote_impl structure that's private to kern_event.c
> that has the new lock. I took the opportunity to move kn_influx to
> the knote_impl as well, since absolutely no one outsi
> On Jul 13, 2022, at 7:18 PM, Jason Thorpe wrote:
>
> Ok, new version. Main differences:
And another new version. This:
==> Creates a knote_impl structure that’s private to kern_event.c that has the
new lock. I took the opportunity to move kn_influx to the knote_impl as well,
since a
> On Jul 13, 2022, at 12:02 PM, Jason Thorpe wrote:
>
>> On Jul 13, 2022, at 11:25 AM, Taylor R Campbell
>> wrote:
>>
>> Sorry, haven't had time yet to do a full review, but I spot at least
>> one problem that means this won't fly as is: kqueue_register and
>> kqueue_scan both call filter_tou
> On Jul 13, 2022, at 11:25 AM, Taylor R Campbell
> wrote:
>
> Sorry, haven't had time yet to do a full review, but I spot at least
> one problem that means this won't fly as is: kqueue_register and
> kqueue_scan both call filter_touch under a spin lock, but with your
> patch filter_touch now
Sorry, haven't had time yet to do a full review, but I spot at least
one problem that means this won't fly as is: kqueue_register and
kqueue_scan both call filter_touch under a spin lock, but with your
patch filter_touch now takes an rwlock -- which is forbidden under a
spin lock (and it'll crash u
> On Jul 12, 2022, at 7:54 AM, Jason Thorpe wrote:
>
> The following patch rectifies this situation by having klist_fini() traverse
> a list of knotes and substitute their filterops with no-op stubs. This
> requires synchronizing with any calls into the filterops themselves. We have
> conv
> On Jul 12, 2022, at 10:27 AM, Jason Thorpe wrote:
>
>
>> On Jul 12, 2022, at 7:54 AM, Jason Thorpe wrote:
>>
>> If someone has ideas about another synchronization mechanism, I’m all ears…
>> again, the main issue is that the filterops calls themselves are allowed to
>> block, so I’m not
> On Jul 12, 2022, at 7:54 AM, Jason Thorpe wrote:
>
> If someone has ideas about another synchronization mechanism, I’m all ears…
> again, the main issue is that the filterops calls themselves are allowed to
> block, so I’m not sure that any of our passive serialization mechanisms would
> w
