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
