Skip to content
  1. Dec 28, 2013
  3. Dec 27, 2013
    • Florian Westphal's avatar
      macvlan: fix netdev feature propagation from lower device · 797f87f8
      Florian Westphal authored 
      There are inconsistencies wrt. feature propagation/inheritance between
macvlan and the underlying interface.

When a feature is turned off on the real device before a macvlan is
created on top, these will remain enabled on the macvlan device, whereas
turning off the feature on the lower device after macvlan creation the
kernel will propagate the changes to the macvlan.

The second issue is that, when propagating changes from underlying device
to the macvlan interface, macvlan can erronously lose its NETIF_F_LLTX flag,
as features are anded with the underlying device.

However, LLTX should be kept since it has no dependencies on physical
hardware (LLTX is set on macvlan creation regardless of the lower
device properties, see 8ffab51b
(macvlan: lockless tx path).

The LLTX flag is now forced regardless of user settings in absence of
layer2 hw acceleration (a6cc0cfa

,
net: Add layer 2 hardware acceleration operations for macvlan devices).

Use netdev_increment_features to rebuild the feature set on capability
changes on either the lower device or on the macvlan interface.

As pointed out by Ben Hutchings, use netdev_update_features on
NETDEV_FEAT_CHANGE event (it calls macvlan_fix_features/netdev_features_change
if needed).

Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      797f87f8
  5. Dec 23, 2013
  7. Dec 22, 2013
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 6eb3c282
      David S. Miller authored 
      

John W. Linville says:

====================
Please consider pulling this batch of fixes for the 3.13 stream...

For the mac80211 bits, Johannes says:

"Here's a fix for another potential radiotap parser buffer overrun thanks
to Evan Huus, and a fix for a cfg80211 warning in a certain corner case
(reconnecting to the same BSS)."

For the bluetooth bits, Gustavo says:

"Two patches in this pull request. An important fix from Marcel in the
permission check for HCI User Channels, there was a extra check for
CAP_NET_RAW, and it was now removed. These channels should only require
CAP_NET_ADMIN. The other patch is a device id addition."

On top of that...

Sujith Manoharan provides a workaround for a hardware problem that
can result in lost interrupts.

Larry Finger fixes an oops when unloading the rtlwifi driver (Red
Hat bug 852761).

Mathy Vanhoef fixes a somewhat minor MAC address privacy issue
(CVE-2013-4579).
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6eb3c282
    • Haiyang Zhang's avatar
      hyperv: Fix race between probe and open calls · a68f9614
      Haiyang Zhang authored 
      

Moving the register_netdev to the end of probe to prevent
possible open call happens before NetVSP is connected.

Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a68f9614
  9. Dec 21, 2013
  11. Dec 20, 2013
  13. Dec 19, 2013
    • Eric Dumazet's avatar
      ipv6: sit: update mtu check to take care of gso packets · 58a47824
      Eric Dumazet authored 
      While testing my changes for TSO support in SIT devices,
I was using sit0 tunnel which appears to include nopmtudisc flag.

But using :

ip tun add sittun mode sit remote $REMOTE_IPV4 local $LOCAL_IPV4 \
   dev $IFACE

We get a tunnel which rejects too long packets because of the mtu check
which is not yet GSO aware.

erd:~# ip tunnel
sittun: ipv6/ip  remote 10.246.17.84  local 10.246.17.83  ttl inherit  6rd-prefix 2002::/16
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16

This patch is based on an excellent report from
Michal Shmidt.

In the future, we probably want to extend the MTU check to do the
right thing for GSO packets...

Fixes: ("61c1db7f

 ipv6: sit: add GSO/TSO support")
Reported-by: default avatarMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Tested-by: default avatarMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58a47824
    • Hannes Frederic Sowa's avatar
      ipv6: pmtudisc setting not respected with UFO/CORK · 4df98e76
      Hannes Frederic Sowa authored 
      Sockets marked with IPV6_PMTUDISC_PROBE (or later IPV6_PMTUDISC_INTERFACE)
don't respect this setting when the outgoing interface supports UFO.

We had the same problem in IPv4, which was fixed in commit
daba287b

 ("ipv4: fix DO and PROBE pmtu
mode regarding local fragmentation with UFO/CORK").

Also IPV6_DONTFRAG mode did not care about already corked data, thus
it may generate a fragmented frame even if this socket option was
specified. It also did not care about the length of the ipv6 header and
possible options.

In the error path allow the user to receive the pmtu notifications via
both, rxpmtu method or error queue. The user may opted in for both,
so deliver the notification to both error handlers (the handlers check
if the error needs to be enqueued).

Also report back consistent pmtu values when sending on an already
cork-appended socket.

Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4df98e76
    • Peter Korsgaard's avatar
      dm9601: work around tx fifo sync issue on dm962x · 4263c86d
      Peter Korsgaard authored 
      

Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
(E.G. if bulk crc mismatch) happens right after a transfer with odd or
maxpacket length, the internal tx hardware fifo gets out of sync causing
the interface to stop working.

Work around it by adding up to 3 bytes of padding to ensure this situation
cannot trigger.

This workaround also means we never pass multiple-of-maxpacket size skb's
to usbnet, so the length adjustment to handle usbnet's padding of those can
be removed.

Cc: <stable@vger.kernel.org>
Reported-by: default avatarJoseph Chang <joseph_chang@davicom.com.tw>
Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4263c86d