summaryrefslogtreecommitdiffstats
path: root/contrib/diff/lib/posixver.c
diff options
context:
space:
mode:
authorbms <bms@FreeBSD.org>2014-04-10 18:43:02 +0000
committerbms <bms@FreeBSD.org>2014-04-10 18:43:02 +0000
commitf923a8498a893153f25b3138c6a0629cb3242bae (patch)
treee0fdd08ec2dfdc87cfa5928c967a2216ab27623d /contrib/diff/lib/posixver.c
parent757ecd1f691c9d6df9dcc3e1fcf6dd172e3dedbb (diff)
downloadFreeBSD-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/posixver.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud