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.
ozaki-r On Tue, Aug 26, 2014 at 4:49 AM, Mindaugas Rasiukevicius <[email protected]> wrote: > 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
