• Johannes Berg's avatar
    wext: fix message delay/ordering · 746ba2ee
    Johannes Berg authored
    [ Upstream commit 8bf86273 ]
    
    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: default avatarBeniamino Galvani <bgalvani@redhat.com>
    Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
    746ba2ee
wext-core.c 29.7 KB