Re: Making bpf MPSAFE (was Re: struct ifnet and ifaddr handling ...)

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Sun, Aug 31, 2014 at 6:23 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> Hi darrenr and rmind,
>
> Thank you for your replying, and I'm sorry for not replying yet.
> I'm now in a busy period for several weeks. I'll be back at the
> next weekend.

I'm back finally. I needed one more month than I expected...
Anyway I'm replying pending mails.

Thanks,
  ozaki-r

>
>   ozaki-r
>
> On Tue, Aug 26, 2014 at 4:49 AM, Mindaugas Rasiukevicius
> <rmind%netbsd.org@localhost> wrote:
>> Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>>> Hi,
>>>
>>> I thought I need more experience of pserialize
>>> (and lock primitives) to tackle ifnet work.
>>> So I suspended the work and now I am trying
>>> another easier task, bpf.
>>>
>>> http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff
>>>
>>
>> As Darren mentioned - there are various bugs in the code (also, malloc
>> change to M_NOWAIT is unhandled).  You cannot drop the lock on the floor
>> and expect the state to stay consistent.  Something has to preserve it.
>>
>> The following pattern applies both to the locks and pserialize(9):
>>
>>         pserialize_read_enter();
>>         obj = lookup();
>>         pserialize_read_exit();
>>         // the object is volatile here, it might be already destroyed
>>
>> Nothing prevents obj from being destroyed after the critical path unless
>> you acquire some form of a reference during the lookup.
>>
>>> BTW, I worry about there is no easy way to
>>> know if a function in a critical section
>>> blocks/sleeps or not. So I wrote a patch to
>>> detect that: http://www.netbsd.org/~ozaki-r/debug-pserialize.diff
>>> Is it meaningful?
>>
>> Why per-LWP rather than per-CPU diagnostic counter?  On the other hand, if
>> we start adding per-CPU counters, then we might as well start implementing
>> RCU. :)
>>
>> --
>> Mindaugas