Ryota Ozaki <[email protected]> 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
