On Thu, Nov 13, 2025 at 11:22:27PM +0100, Alexander Bluhm wrote:
> On Thu, Nov 13, 2025 at 11:39:27PM +0300, Vitaliy Makkoveev wrote:
> > On Thu, Nov 13, 2025 at 11:21:51PM +0300, Vitaliy Makkoveev wrote:
> > > On Thu, Nov 13, 2025 at 11:07:28PM +0300, Vitaliy Makkoveev wrote:
> > > > On Thu, Nov 13, 2025 at 11:05:46AM -0800, Mark McBride wrote:
> > > > > I can trigger a kernel panic if I start the syncthing service.
> > > > >
> > > > > rcctl start syncthing_markmcb
> > > > >
> > > > > ... wait 5-10 seconds ...
> > > > >
> > > > > panic: netlock rwlock 0xffffff80012492d0: exit write when lock not
> > > > > held (owner 0
> > > > > x10, self 0xffffff809ee7ad24)
> > > > > Stopped at db_enter+0x18: brk #0xf000
> > > > > TID PID UID PRFLAGS PFLAGS CPU COMMAND
> > > > > 87509 73883 1000 0x3 0 2 syncthing
> > > > > 468519 73883 1000 0x3 0x4000000 3 syncthing
> > > > > * 29160 73883 1000 0x3 0x4000000 1 syncthing
> > > > > 3 22537 73883 1000 0x3 0x4000000 0 syncthing
> > > > > db_enter() at panic+0x138
> > > > > panic() at rw_exit_write+0xd0
> > > > > _rw_init_flags() at cad_ioctl+0x80
> > > > > cad_ioctl() at in_delmulti+0xbc
> > > > > in_delmulti() at ip_freemoptions+0x3c
> > > > > ip_freemoptions() at in_pcbdetach+0x5c
> > > > > in_pcbdetach() at udp_detach+0x2c
> > > > >
> > > >
> > > > We don't hold netlock wile performing SIOC{G,S}IFMEDIA ifioctl()
> > > > commands, so add them to exception list too.
> > > >
> > >
> > > Ops, they already are. Please drop this diff.
> > >
> >
> > We hold shared netlock, so we trigger the assertion. This should not be
> > the problem for cad(4), but this should be the problem for interface
> > addresses list.
>
> This code in cad_ioctl() looks ugly.
>
> if (netlock_held)
> NET_UNLOCK();
> rw_enter_write(&sc->sc_cfg_lock);
> if (netlock_held)
> NET_LOCK();
> s = splnet();
>
> Why does cad(4) fiddle with net lock at all?
>
> Drivers, not aware of MP, should rely on kernel lock. New drivers,
> that announce themselves as MPSAFE, should implement their own
> locking. I think no driver should ever touch net lock.
>
> bluhm
>
This is the known locks order problem between driver's lock and netlock.
