On 23/05/20(Sat) 15:38, Vitaliy Makkoveev wrote:
> > On 23 May 2020, at 12:54, Martin Pieuchot <m...@openbsd.org> wrote:
> > On 22/05/20(Fri) 13:25, Vitaliy Makkoveev wrote:
> >> On Fri, May 22, 2020 at 07:57:13AM +1000, David Gwynne wrote:
> >>> [...]
> >>> can you try the following diff?
> >>>
> >>
> >> I tested this diff and it works for me. But the problem I pointed is
> >> about pipex(4) locking.
> >>
> >> pipex(4) requires NET_LOCK() be grabbed not only for underlaying
> >> ip{,6}_output() but for itself too. But since pppac_start() has
> >> unpredictable behavior I suggested to make it predictable [1].
> >
> > What needs the NET_LOCK() in their? We're talking about
> > pipex_ppp_output(), right? Does it really need the NET_LOCK() or
> > the KERNEL_LOCK() is what protects those data structures?
>
> Yes, about pipex_ppp_output() and pipex_output(). Except
> ip{,6}_output() nothing requires NET_LOCK(). As David Gwynne pointed,
> they can be replaced by ip{,6}_send().
Locks protect data structures, you're talking about functions, which
data structures are serialized by this lock? I'm questioning whether
there is one.
> [...]
> > In case of pipex(4) is isn't clear that the NET_LOCK() is necessary.
>
> I guess, pipex(4) was wrapped by NET_LOCK() to protect it while it’s
> accessed through `pr_input’. Is NET_LOCK() required for this case?
pipex(4) like all the network stack has been wrapped in the NET_LOCK()
because it was easy to do. That means it isn't a concious decision or
design. The fact that pipex(4) code runs under the NET_LOCK() is a side
effect of how the rest of the stack evolved. I'm questioning whether
this lock is required there. In theory it shouldn't. What is the
reality?
