diff options
author | bms <bms@FreeBSD.org> | 2014-04-10 18:43:02 +0000 |
---|---|---|
committer | bms <bms@FreeBSD.org> | 2014-04-10 18:43:02 +0000 |
commit | f923a8498a893153f25b3138c6a0629cb3242bae (patch) | |
tree | e0fdd08ec2dfdc87cfa5928c967a2216ab27623d /contrib/diff/lib/cmpbuf.h | |
parent | 757ecd1f691c9d6df9dcc3e1fcf6dd172e3dedbb (diff) | |
download | FreeBSD-src-f923a8498a893153f25b3138c6a0629cb3242bae.zip FreeBSD-src-f923a8498a893153f25b3138c6a0629cb3242bae.tar.gz |
In if_freemulti(), relax the paranoid KASSERT() on ifma->ifma_protospec.
This KASSERT() existed as a sanity check that upper layers in the network
stack (e.g. inet, inet6) had released their reference to the underlying
driver's multicast memberships (ifmultiaddr{}). However it assumes the
lifecycle of the driver membership corresponds to the lifecycle of the
network layer membership.
In the submitter's case, ieee80211_ioctl_updatemulti() attempts to
reprogram the (parent, physical) ifnet{} memberships in response
to a change in membership on the (child, virtual) VAP ifnet, using
a batched update mechanism. These updates happen independently from
the network layer, causing a "false negative" assertion failure.
There are possibly other use cases where this KASSERT() may be triggered
by other networking stack activity (e.g. where a nesting relationship
exists between multiple ifnet{} instances). This suggests that further
review of FreeBSD's approach to nested ifnet relationships is needed.
MFC after: 6 weeks
Submitted by: adrian@
Diffstat (limited to 'contrib/diff/lib/cmpbuf.h')
0 files changed, 0 insertions, 0 deletions