1. 30 Apr, 2014 4 commits
    • Peter Boström's avatar
      vlan: Set correct source MAC address with TX VLAN offload enabled · c99f58d7
      Peter Boström authored
      [ Upstream commit dd38743b ]
      
      With TX VLAN offload enabled the source MAC address for frames sent using the
      VLAN interface is currently set to the address of the real interface. This is
      wrong since the VLAN interface may be configured with a different address.
      
      The bug was introduced in commit 2205369a
      ("vlan: Fix header ops passthru when doing TX VLAN offload.").
      
      This patch sets the source address before calling the create function of the
      real interface.
      Signed-off-by: default avatarPeter Boström <peter.bostrom@netrounds.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c99f58d7
    • Eric Dumazet's avatar
      net: unix: non blocking recvmsg() should not return -EINTR · e7177969
      Eric Dumazet authored
      [ Upstream commit de144391 ]
      
      Some applications didn't expect recvmsg() on a non blocking socket
      could return -EINTR. This possibility was added as a side effect
      of commit b3ca9b02 ("net: fix multithreaded signal handling in
      unix recv routines").
      
      To hit this bug, you need to be a bit unlucky, as the u->readlock
      mutex is usually held for very small periods.
      
      Fixes: b3ca9b02 ("net: fix multithreaded signal handling in unix recv routines")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Rainer Weikusat <rweikusat@mobileactivedefense.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e7177969
    • Linus Lüssing's avatar
      bridge: multicast: add sanity check for query source addresses · 36672f63
      Linus Lüssing authored
      [ Upstream commit 6565b9ee ]
      
      MLD queries are supposed to have an IPv6 link-local source address
      according to RFC2710, section 4 and RFC3810, section 5.1.14. This patch
      adds a sanity check to ignore such broken MLD queries.
      
      Without this check, such malformed MLD queries can result in a
      denial of service: The queries are ignored by any MLD listener
      therefore they will not respond with an MLD report. However,
      without this patch these malformed MLD queries would enable the
      snooping part in the bridge code, potentially shutting down the
      according ports towards these hosts for multicast traffic as the
      bridge did not learn about these listeners.
      Reported-by: default avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@web.de>
      Reviewed-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      36672f63
    • Daniel Borkmann's avatar
      net: sctp: fix skb leakage in COOKIE ECHO path of chunk->auth_chunk · 46e9c408
      Daniel Borkmann authored
      [ Upstream commit c485658b ]
      
      While working on ec0223ec ("net: sctp: fix sctp_sf_do_5_1D_ce to
      verify if we/peer is AUTH capable"), we noticed that there's a skb
      memory leakage in the error path.
      
      Running the same reproducer as in ec0223ec and by unconditionally
      jumping to the error label (to simulate an error condition) in
      sctp_sf_do_5_1D_ce() receive path lets kmemleak detector bark about
      the unfreed chunk->auth_chunk skb clone:
      
      Unreferenced object 0xffff8800b8f3a000 (size 256):
        comm "softirq", pid 0, jiffies 4294769856 (age 110.757s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          89 ab 75 5e d4 01 58 13 00 00 00 00 00 00 00 00  ..u^..X.........
        backtrace:
          [<ffffffff816660be>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff8119f328>] kmem_cache_alloc+0xc8/0x210
          [<ffffffff81566929>] skb_clone+0x49/0xb0
          [<ffffffffa0467459>] sctp_endpoint_bh_rcv+0x1d9/0x230 [sctp]
          [<ffffffffa046fdbc>] sctp_inq_push+0x4c/0x70 [sctp]
          [<ffffffffa047e8de>] sctp_rcv+0x82e/0x9a0 [sctp]
          [<ffffffff815abd38>] ip_local_deliver_finish+0xa8/0x210
          [<ffffffff815a64af>] nf_reinject+0xbf/0x180
          [<ffffffffa04b4762>] nfqnl_recv_verdict+0x1d2/0x2b0 [nfnetlink_queue]
          [<ffffffffa04aa40b>] nfnetlink_rcv_msg+0x14b/0x250 [nfnetlink]
          [<ffffffff815a3269>] netlink_rcv_skb+0xa9/0xc0
          [<ffffffffa04aa7cf>] nfnetlink_rcv+0x23f/0x408 [nfnetlink]
          [<ffffffff815a2bd8>] netlink_unicast+0x168/0x250
          [<ffffffff815a2fa1>] netlink_sendmsg+0x2e1/0x3f0
          [<ffffffff8155cc6b>] sock_sendmsg+0x8b/0xc0
          [<ffffffff8155d449>] ___sys_sendmsg+0x369/0x380
      
      What happens is that commit bbd0d598 clones the skb containing
      the AUTH chunk in sctp_endpoint_bh_rcv() when having the edge case
      that an endpoint requires COOKIE-ECHO chunks to be authenticated:
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        ------------------ AUTH; COOKIE-ECHO ---------------->
        <-------------------- COOKIE-ACK ---------------------
      
      When we enter sctp_sf_do_5_1D_ce() and before we actually get to
      the point where we process (and subsequently free) a non-NULL
      chunk->auth_chunk, we could hit the "goto nomem_init" path from
      an error condition and thus leave the cloned skb around w/o
      freeing it.
      
      The fix is to centrally free such clones in sctp_chunk_destroy()
      handler that is invoked from sctp_chunk_free() after all refs have
      dropped; and also move both kfree_skb(chunk->auth_chunk) there,
      so that chunk->auth_chunk is either NULL (since sctp_chunkify()
      allocs new chunks through kmem_cache_zalloc()) or non-NULL with
      a valid skb pointer. chunk->skb and chunk->auth_chunk are the
      only skbs in the sctp_chunk structure that need to be handeled.
      
      While at it, we should use consume_skb() for both. It is the same
      as dev_kfree_skb() but more appropriately named as we are not
      a device but a protocol. Also, this effectively replaces the
      kfree_skb() from both invocations into consume_skb(). Functions
      are the same only that kfree_skb() assumes that the frame was
      being dropped after a failure (e.g. for tools like drop monitor),
      usage of consume_skb() seems more appropriate in function
      sctp_chunk_destroy() though.
      
      Fixes: bbd0d598 ("[SCTP]: Implement the receive and verification of AUTH chunk")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <yasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      46e9c408
  2. 09 Apr, 2014 19 commits
  3. 01 Apr, 2014 17 commits
    • Ben Hutchings's avatar
      Linux 3.2.56 · e08e9457
      Ben Hutchings authored
      e08e9457
    • Bjorn Helgaas's avatar
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · f41b3d0b
      Bjorn Helgaas authored
      commit 3cdeb713 upstream.
      
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f41b3d0b
    • Konrad Rzeszutek Wilk's avatar
      intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it. · dcd8e204
      Konrad Rzeszutek Wilk authored
      commit 3735d524 upstream.
      
      If the machine is booted without any cpu_idle driver set
      (b/c disable_cpuidle() has been called) we should follow
      other users of cpu_idle API and check the return value
      for NULL before using it.
      Reported-and-tested-by: default avatarMark van Dijk <mark@internecto.net>
      Suggested-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dcd8e204
    • Daniel Borkmann's avatar
      net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable · c7160985
      Daniel Borkmann authored
      [ Upstream commit ec0223ec ]
      
      RFC4895 introduced AUTH chunks for SCTP; during the SCTP
      handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
      being optional though):
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        -------------------- COOKIE-ECHO -------------------->
        <-------------------- COOKIE-ACK ---------------------
      
      A special case is when an endpoint requires COOKIE-ECHO
      chunks to be authenticated:
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        ------------------ AUTH; COOKIE-ECHO ---------------->
        <-------------------- COOKIE-ACK ---------------------
      
      RFC4895, section 6.3. Receiving Authenticated Chunks says:
      
        The receiver MUST use the HMAC algorithm indicated in
        the HMAC Identifier field. If this algorithm was not
        specified by the receiver in the HMAC-ALGO parameter in
        the INIT or INIT-ACK chunk during association setup, the
        AUTH chunk and all the chunks after it MUST be discarded
        and an ERROR chunk SHOULD be sent with the error cause
        defined in Section 4.1. [...] If no endpoint pair shared
        key has been configured for that Shared Key Identifier,
        all authenticated chunks MUST be silently discarded. [...]
      
        When an endpoint requires COOKIE-ECHO chunks to be
        authenticated, some special procedures have to be followed
        because the reception of a COOKIE-ECHO chunk might result
        in the creation of an SCTP association. If a packet arrives
        containing an AUTH chunk as a first chunk, a COOKIE-ECHO
        chunk as the second chunk, and possibly more chunks after
        them, and the receiver does not have an STCB for that
        packet, then authentication is based on the contents of
        the COOKIE-ECHO chunk. In this situation, the receiver MUST
        authenticate the chunks in the packet by using the RANDOM
        parameters, CHUNKS parameters and HMAC_ALGO parameters
        obtained from the COOKIE-ECHO chunk, and possibly a local
        shared secret as inputs to the authentication procedure
        specified in Section 6.3. If authentication fails, then
        the packet is discarded. If the authentication is successful,
        the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
        MUST be processed. If the receiver has an STCB, it MUST
        process the AUTH chunk as described above using the STCB
        from the existing association to authenticate the
        COOKIE-ECHO chunk and all the chunks after it. [...]
      
      Commit bbd0d598 introduced the possibility to receive
      and verification of AUTH chunk, including the edge case for
      authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
      the function sctp_sf_do_5_1D_ce() handles processing,
      unpacks and creates a new association if it passed sanity
      checks and also tests for authentication chunks being
      present. After a new association has been processed, it
      invokes sctp_process_init() on the new association and
      walks through the parameter list it received from the INIT
      chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO
      and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
      meta data (peer_random, peer_hmacs, peer_chunks) in case
      sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
      SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set,
      peer_random != NULL and peer_hmacs != NULL the peer is to be
      assumed asoc->peer.auth_capable=1, in any other case
      asoc->peer.auth_capable=0.
      
      Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
      available, we set up a fake auth chunk and pass that on to
      sctp_sf_authenticate(), which at latest in
      sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
      at position 0..0008 when setting up the crypto key in
      crypto_hash_setkey() by using asoc->asoc_shared_key that is
      NULL as condition key_id == asoc->active_key_id is true if
      the AUTH chunk was injected correctly from remote. This
      happens no matter what net.sctp.auth_enable sysctl says.
      
      The fix is to check for net->sctp.auth_enable and for
      asoc->peer.auth_capable before doing any operations like
      sctp_sf_authenticate() as no key is activated in
      sctp_auth_asoc_init_active_key() for each case.
      
      Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
      passed from the INIT chunk was not used in the AUTH chunk, we
      SHOULD send an error; however in this case it would be better
      to just silently discard such a maliciously prepared handshake
      as we didn't even receive a parameter at all. Also, as our
      endpoint has no shared key configured, section 6.3 says that
      MUST silently discard, which we are doing from now onwards.
      
      Before calling sctp_sf_pdiscard(), we need not only to free
      the association, but also the chunk->auth_chunk skb, as
      commit bbd0d598 created a skb clone in that case.
      
      I have tested this locally by using netfilter's nfqueue and
      re-injecting packets into the local stack after maliciously
      modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
      and the SCTP packet containing the COOKIE_ECHO (injecting
      AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.
      
      Fixes: bbd0d598 ("[SCTP]: Implement the receive and verification of AUTH chunk")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <yasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c7160985
    • Michael Chan's avatar
      tg3: Don't check undefined error bits in RXBD · 608532c1
      Michael Chan authored
      [ Upstream commit d7b95315 ]
      
      Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
      a customer reported issue of randomly dropping packets on the 5719.
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      608532c1
    • Jason Wang's avatar
      virtio-net: alloc big buffers also when guest can receive UFO · ddc63f2b
      Jason Wang authored
      [ Upstream commit 0e7ede80 ]
      
      We should alloc big buffers also when guest can receive UFO
      packets to let the big packets fit into guest rx buffer.
      
      Fixes 5c516751
      (virtio-net: Allow UFO feature to be set and advertised.)
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Sridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ddc63f2b
    • Paul E. McKenney's avatar
      jiffies: Avoid undefined behavior from signed overflow · bc9664f1
      Paul E. McKenney authored
      commit 5a581b36 upstream.
      
      According to the C standard 3.4.3p3, overflow of a signed integer results
      in undefined behavior.  This commit therefore changes the definitions
      of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
      to avoid this undefined behavior.  The trick is that the subtraction
      is done using unsigned arithmetic, which according to 6.2.5p9 cannot
      overflow because it is defined as modulo arithmetic.  This has the added
      (though admittedly quite small) benefit of shortening four lines of code
      by four characters each.
      
      Note that the C standard considers the cast from unsigned to
      signed to be implementation-defined, see 6.3.1.3p3.  However, on a
      two's-complement system, an implementation that defines anything other
      than a reinterpretation of the bits is free to come to me, and I will be
      happy to act as a witness for its being committed to an insane asylum.
      (Although I have nothing against saturating arithmetic or signals in some
      cases, these things really should not be the default when compiling an
      operating-system kernel.)
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Kevin Easton <kevin@guarana.org>
      [ paulmck: Included time_after64() and time_after_eq64(), as suggested
        by Eric Dumazet, also fixed commit message.]
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bc9664f1
    • Clemens Ladisch's avatar
      ALSA: oxygen: Xonar DG(X): modify DAC routing · 54a19ec5
      Clemens Ladisch authored
      commit 1f91ecc1 upstream.
      
      When selecting the audio output destinations (headphones, FP headphones,
      multichannel output), unnecessary I2S channels are digitally muted to
      avoid invalid signal levels on the other outputs.
      Signed-off-by: default avatarRoman Volkov <v1ron@mail.ru>
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      54a19ec5
    • Roman Volkov's avatar
      ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2 · 935e68c6
      Roman Volkov authored
      commit 3dd77654 upstream.
      
      Actually CS4245 connected to the I2S channel 1 for
      capture, not channel 2. Otherwise capturing and
      playback does not work for CS4245.
      Signed-off-by: default avatarRoman Volkov <v1ron@mail.ru>
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      935e68c6
    • Takashi Iwai's avatar
      saa7134: Fix unlocked snd_pcm_stop() call · dd615645
      Takashi Iwai authored
      commit e6355ad7 upstream.
      
      snd_pcm_stop() must be called in the PCM substream lock context.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      [wml: Backported to 3.4: Adjust filename]
      Signed-off-by: default avatarWeng Meiling <wengmeiling.weng@huawei.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dd615645
    • Martijn de Gouw's avatar
      cifs: set MAY_SIGN when sec=krb5 · 9924c0fa
      Martijn de Gouw authored
      commit 0b7bc840 upstream.
      
      Setting this secFlg allows usage of dfs where some servers require
      signing and others don't.
      Signed-off-by: default avatarMartijn de Gouw <martijn.de.gouw@prodrive.nl>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      [Joseph Salisbury: This backport was done so including mainline commit
      8830d7e0 is not needed.]
      BugLink: http://bugs.launchpad.net/bugs/1285723Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9924c0fa
    • Daniel Borkmann's avatar
      net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode · ffbd2b62
      Daniel Borkmann authored
      [ Upstream commit ffd59393 ]
      
      SCTP's sctp_connectx() abi breaks for 64bit kernels compiled with 32bit
      emulation (e.g. ia32 emulation or x86_x32). Due to internal usage of
      'struct sctp_getaddrs_old' which includes a struct sockaddr pointer,
      sizeof(param) check will always fail in kernel as the structure in
      64bit kernel space is 4bytes larger than for user binaries compiled
      in 32bit mode. Thus, applications making use of sctp_connectx() won't
      be able to run under such circumstances.
      
      Introduce a compat interface in the kernel to deal with such
      situations by using a 'struct compat_sctp_getaddrs_old' structure
      where user data is copied into it, and then sucessively transformed
      into a 'struct sctp_getaddrs_old' structure with the help of
      compat_ptr(). That fixes sctp_connectx() abi without any changes
      needed in user space, and lets the SCTP test suite pass when compiled
      in 32bit and run on 64bit kernels.
      
      Fixes: f9c67811 ("sctp: Fix regression introduced by new sctp_connectx api")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ffbd2b62
    • Jiri Bohac's avatar
      bonding: 802.3ad: make aggregator_identifier bond-private · 22bff361
      Jiri Bohac authored
      [ Upstream commit 163c8ff3 ]
      
      aggregator_identifier is used to assign unique aggregator identifiers
      to aggregators of a bond during device enslaving.
      
      aggregator_identifier is currently a global variable that is zeroed in
      bond_3ad_initialize().
      
      This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:
      
      create bond0
      change bond0 mode to 802.3ad
      enslave eth0 to bond0 		//eth0 gets agg id 1
      enslave eth1 to bond0 		//eth1 gets agg id 2
      create bond1
      change bond1 mode to 802.3ad
      enslave eth2 to bond1		//aggregator_identifier is reset to 0
      				//eth2 gets agg id 1
      enslave eth3 to bond0 		//eth3 gets agg id 2
      
      Fix this by making aggregator_identifier private to the bond.
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Acked-by: default avatarVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      22bff361
    • Emil Goode's avatar
      usbnet: remove generic hard_header_len check · 7bf67232
      Emil Goode authored
      [ Upstream commit eb85569f ]
      
      This patch removes a generic hard_header_len check from the usbnet
      module that is causing dropped packages under certain circumstances
      for devices that send rx packets that cross urb boundaries.
      
      One example is the AX88772B which occasionally send rx packets that
      cross urb boundaries where the remaining partial packet is sent with
      no hardware header. When the buffer with a partial packet is of less
      number of octets than the value of hard_header_len the buffer is
      discarded by the usbnet module.
      
      With AX88772B this can be reproduced by using ping with a packet
      size between 1965-1976.
      
      The bug has been reported here:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=29082
      
      This patch introduces the following changes:
      - Removes the generic hard_header_len check in the rx_complete
        function in the usbnet module.
      - Introduces a ETH_HLEN check for skbs that are not cloned from
        within a rx_fixup callback.
      - For safety a hard_header_len check is added to each rx_fixup
        callback function that could be affected by this change.
        These extra checks could possibly be removed by someone
        who has the hardware to test.
      - Removes a call to dev_kfree_skb_any() and instead utilizes the
        dev->done list to queue skbs for cleanup.
      
      The changes place full responsibility on the rx_fixup callback
      functions that clone skbs to only pass valid skbs to the
      usbnet_skb_return function.
      Signed-off-by: default avatarEmil Goode <emilgoode@gmail.com>
      Reported-by: default avatarIgor Gnatenko <i.gnatenko.brain@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7bf67232
    • Nithin Sujir's avatar
      tg3: Fix deadlock in tg3_change_mtu() · 9a46001e
      Nithin Sujir authored
      [ Upstream commit c6993dfd ]
      
      Quoting David Vrabel -
      "5780 cards cannot have jumbo frames and TSO enabled together.  When
      jumbo frames are enabled by setting the MTU, the TSO feature must be
      cleared.  This is done indirectly by calling netdev_update_features()
      which will call tg3_fix_features() to actually clear the flags.
      
      netdev_update_features() will also trigger a new netlink message for the
      feature change event which will result in a call to tg3_get_stats64()
      which deadlocks on the tg3 lock."
      
      tg3_set_mtu() does not need to be under the tg3 lock since converting
      the flags to use set_bit(). Move it out to after tg3_netif_stop().
      Reported-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Tested-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9a46001e
    • Maciej Żenczykowski's avatar
      net: fix 'ip rule' iif/oif device rename · 2c62fcd9
      Maciej Żenczykowski authored
      [ Upstream commit 946c032e ]
      
      ip rules with iif/oif references do not update:
      (detach/attach) across interface renames.
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      CC: Willem de Bruijn <willemb@google.com>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Chris Davis <chrismd@google.com>
      CC: Carlo Contavalli <ccontavalli@google.com>
      
      Google-Bug-Id: 12936021
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2c62fcd9
    • Paul E. McKenney's avatar
      printk: Fix scheduling-while-atomic problem in console_cpu_notify() · d8db5f98
      Paul E. McKenney authored
      commit 85eae82a upstream.
      
      The console_cpu_notify() function runs with interrupts disabled in the
      CPU_DYING case.  It therefore cannot block, for example, as will happen
      when it calls console_lock().  Therefore, remove the CPU_DYING leg of
      the switch statement to avoid this problem.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      d8db5f98