cvs commit: src/sys/net if_bridge.c
rwatson at FreeBSD.org
Sat Aug 27 02:42:24 GMT 2005
On Sat, 27 Aug 2005, Andrew Thompson wrote:
> Fix a panic in softclock() if the interface is destroyed with a bpf
> 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
Robert N M Watson
More information about the cvs-src