diff options
author | Johannes Berg <johannes.berg@intel.com> | 2016-01-27 14:37:52 +0300 |
---|---|---|
committer | Johannes Berg <johannes.berg@intel.com> | 2016-01-29 19:13:39 +0300 |
commit | 8bf862739a7786ae72409220914df960a0aa80d8 (patch) | |
tree | 8ee53c9ca892727cf0623fd7aabb25d242cdfee6 /include/net/iw_handler.h | |
parent | 6736fde9672ff6717ac576e9bba2fd5f3dfec822 (diff) | |
download | linux-8bf862739a7786ae72409220914df960a0aa80d8.tar.xz |
wext: fix message delay/ordering
Beniamino reported that he was getting an RTM_NEWLINK message for a
given interface, after the RTM_DELLINK for it. It turns out that the
message is a wireless extensions message, which was sent because the
interface had been connected and disconnection while it was deleted
caused a wext message.
For its netlink messages, wext uses RTM_NEWLINK, but the message is
without all the regular rtnetlink attributes, so "ip monitor link"
prints just rudimentary information:
5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
Deleted 5: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
link/ether 02:00:00:00:01:00 brd ff:ff:ff:ff:ff:ff
5: wlan1: <BROADCAST,MULTICAST,UP>
link/ether
(from my hwsim reproduction)
This can cause userspace to get confused since it doesn't expect an
RTM_NEWLINK message after RTM_DELLINK.
The reason for this is that wext schedules a worker to send out the
messages, and the scheduling delay can cause the messages to get out
to userspace in different order.
To fix this, have wext register a netdevice notifier and flush out
any pending messages when netdevice state changes. This fixes any
ordering whenever the original message wasn't sent by a notifier
itself.
Cc: stable@vger.kernel.org
Reported-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'include/net/iw_handler.h')
0 files changed, 0 insertions, 0 deletions