Re: MPSAFE and KERNEL_LOCK

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

On Mon, May 14, 2018 at 2:59 PM Michael van Elst <mlelstv%serpens.de@localhost> wrote:

> On Mon, May 14, 2018 at 12:00:44PM +0900, Ryota Ozaki wrote:
> > On Fri, May 11, 2018 at 6:41 PM Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
> >
> >
> > > On Fri, May 11, 2018 at 3:53 PM Michael van Elst <mlelstv%serpens.de@localhost>
> > wrote:
> >
> > > > A traditional ethernet driver receives input via an interrupt
routine
> > > > and passes packets to ether_input(). The data is protected by
disabling
> > > > the receive interrupt.
> >
> > > > In multiprocessor land, the same is achieved by also acquiring the
> > > > big kernel lock.
> >
> > > > Current code however queues incoming packets in a percpuq and passes
> > > > things through a softint tagged as MPSAFE. The softint handler is
> > calling
> > > > ether_input without holding the kernel lock.
> >
> > > > There is another unprotected path in bpf_write calling into the
> > > > _if_input vector directly without locking (bpf device is tagged
MPSAFE)
> > > > and without disabling interrupts.
> >
> > > > Did I miss something?
> >
> > > You're right.
> >
> > > Not holding KERNEL_LOCK in ether_input can be problematic if we use
> > > CARP and/or AGR (and NETATALK) that are not MP-safe. Also calling
> > > _if_ipnput without splsoftnet from bpf_write is problematic as you
said.
> >
> > > The following patch should fix the issue:
> > >     http://www.netbsd.org/~ozaki-r/fix-if_input.diff
> >
> > I committed the patch with the same fix for ether_input from
bridge_output.


> This will need a pullup to netbsd-8 too.

Yes. I prepared a mail for a pullup and am waiting for someone to object
or exposing build issues for a while to be safe.

   ozaki-r