On 03/09/14(Wed) 23:59, Claudio Jeker wrote:
> On Wed, Sep 03, 2014 at 03:25:34PM +0200, Martin Pieuchot wrote:
> > Drivers that need a splnet() protection inside their SIOCSIFADDR
> > generally raise the spl level themselves, so we should not need
> > to do that in in{6,}_ifinit(). One exception to this rule is,
> > as always, carp(4)...
> >
> > So the diff below moves the spl dance inside carp's SIOCSIFADDR
> > handler, it's a baby step, so we can take care of carp_set_addr{6,}
> > later.
>
> Hmm. My gut feeling is that this is scary. Calling ifp functions at
> non-splnet is always a cause for troubles (e.g. the watchdog callbacks
> miss often the needed splnet calls).
> I think the ioctl code pathes in the various places may suffer from
> similar problems with missing splnet() calls. Guess a bit of an audit is
> needed in that area.
And the audit revealed that only lo(4) has an unneeded splnet() call.
> Something else I wonder is if splsoftnet() is good enough when dealing
> with ifp in general (aren't we detaching interfaces at splnet())?
> Removable interfaces opened for sure a bucket sized can of worms.
I believe it is, or at least it should be. splnet() should only be
necessary inside drivers to protect the code that might interfere with
configuring the hardware or messing with the rings.
The rational is quite simple: packets are processed in softnet, so the
pieces of code modifying the global lists and tables should make sure
code run at softnet cannot be executed in parallel.
The fact that some of the operations are still done under splnet(), like
detatching interfaces, seems related to history. I'm trying to carefully
remove the unneeded splnet()s. One of the biggest problem was the routing
table update triggered by a link state change that *was* executed during a
IPL_NET interrupt. But that's no longer the case.
