cvs commit: src/sys/net if_bridge.c

[Robert Watson]

On Sat, 27 Aug 2005, Andrew Thompson wrote:

>  Fix a panic in softclock() if the interface is destroyed with a bpf 
> consumer
>  attached.
>
>  This is caused by bpf_detachd clearing IFF_PROMISC on the interface which does
>  a SIOCSIFFLAGS ioctl. The problem here is that while the interface has been
>  stopped, IFF_UP has not been cleared so IFF_UP != IFF_DRV_RUNNING, this causes
>  the ioctl function to init() the interface which resets the callouts.
>
>  The destroy then completes and frees the softc but softclock will panic on a
>  dead callout pointer.
>
>  Ensure ifp->if_flags matches reality by clearing IFF_UP when we destroy.
>
>  Silence from:   rwatson
>  Approved by:    mlaier (mentor)
>  MFC after:      3 days

Sorry about not yet having gotten around to responding to your e-mail -- 
I've been on travel for the last couple of weeks, having spent quality 
time in Heathrow courtesy BA, but hope to look more closely at this and 
related issues in the near future.

One particular long-term concern I have is with respect to modification of 
IFF_UP state, which for most device drivers is an administrative 
condition, rather than a link condition.  Certain connection-oriented 
drivers, such as PPP, modify IFF_UP.  So do some ethernet interfaces, 
under the possibly mistaken impression that that is necessary to raise the 
interface when it is configured.  I've not yet had a chance to investigate 
what the right approach is, but in the long term, we will need to resolve 
who "owns" the field, be it the stack or the device driver, and how event 
notifications are handled.

I suspect some use of IFF_UP by device drivers will eventually become a 
separate driver-owned flag, possibly in softc, which will reflect the 
driver's state transitions to reflect administrator-requested up/down 
state.

Robert N M Watson