1. 27 Apr, 2015 20 commits
  2. 21 Apr, 2015 11 commits
  3. 13 Apr, 2015 9 commits
    • Neal Cardwell's avatar
      tcp: fix FRTO undo on cumulative ACK of SACKed range · 39ae67b0
      Neal Cardwell authored
      commit 666b8051 upstream.
      
      On processing cumulative ACKs, the FRTO code was not checking the
      SACKed bit, meaning that there could be a spurious FRTO undo on a
      cumulative ACK of a previously SACKed skb.
      
      The FRTO code should only consider a cumulative ACK to indicate that
      an original/unretransmitted skb is newly ACKed if the skb was not yet
      SACKed.
      
      The effect of the spurious FRTO undo would typically be to make the
      connection think that all previously-sent packets were in flight when
      they really weren't, leading to a stall and an RTO.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Fixes: e33099f9 ("tcp: implement RFC5682 F-RTO")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      39ae67b0
    • Jonathan Davies's avatar
      xen-netfront: transmit fully GSO-sized packets · 53d556c7
      Jonathan Davies authored
      commit 0c36820e upstream.
      
      xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
      GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
      bytes each. This slight reduction in the size of packets means a slight loss in
      efficiency.
      
      Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
          XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
      where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
      
      The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
      6c09fa09) in determining when to split an skb into two is
          sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
      
      So the maximum permitted size of an skb is calculated to be
          (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
      
      Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
      Instead, there is no need to deviate from the default gso_max_size of 65536 as
      this already accommodates the size of the header.
      
      Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
      of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
      skbs of up to 65160 bytes (45 segments of 1448 bytes each).
      
      Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
      it relates to the size of the whole packet, including the header.
      
      Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
      Signed-off-by: default avatarJonathan Davies <jonathan.davies@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      53d556c7
    • Ido Shamay's avatar
      net/mlx4_en: Call register_netdevice in the proper location · 35dd2e41
      Ido Shamay authored
      commit e5eda89d upstream.
      
      Netdevice registration should be performed a the end of the driver
      initialization flow. If we don't do that, after calling register_netdevice,
      device callbacks may be issued by higher layers of the stack before
      final configuration of the device is done.
      
      For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued
      after the register_netdev command. System network scripts may configure
      the interface (UP) right after the registration, which also attach
      unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called,
      causing the firmware to fail the rule attachment.
      
      Fixes: 837052d0 ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling")
      Signed-off-by: default avatarIdo Shamay <idos@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      35dd2e41
    • WANG Cong's avatar
      net: use for_each_netdev_safe() in rtnl_group_changelink() · c3bd57cd
      WANG Cong authored
      commit d079535d upstream.
      
      In case we move the whole dev group to another netns,
      we should call for_each_netdev_safe(), otherwise we get
      a soft lockup:
      
       NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ip:798]
       irq event stamp: 255424
       hardirqs last  enabled at (255423): [<ffffffff81a2aa95>] restore_args+0x0/0x30
       hardirqs last disabled at (255424): [<ffffffff81a2ad5a>] apic_timer_interrupt+0x6a/0x80
       softirqs last  enabled at (255422): [<ffffffff81079ebc>] __do_softirq+0x2c1/0x3a9
       softirqs last disabled at (255417): [<ffffffff8107a190>] irq_exit+0x41/0x95
       CPU: 0 PID: 798 Comm: ip Not tainted 4.0.0-rc4+ #881
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       task: ffff8800d1b88000 ti: ffff880119530000 task.ti: ffff880119530000
       RIP: 0010:[<ffffffff810cad11>]  [<ffffffff810cad11>] debug_lockdep_rcu_enabled+0x28/0x30
       RSP: 0018:ffff880119533778  EFLAGS: 00000246
       RAX: ffff8800d1b88000 RBX: 0000000000000002 RCX: 0000000000000038
       RDX: 0000000000000000 RSI: ffff8800d1b888c8 RDI: ffff8800d1b888c8
       RBP: ffff880119533778 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000000 R11: 000000000000b5c2 R12: 0000000000000246
       R13: ffff880119533708 R14: 00000000001d5a40 R15: ffff88011a7d5a40
       FS:  00007fc01315f740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00007f367a120988 CR3: 000000011849c000 CR4: 00000000000007f0
       Stack:
        ffff880119533798 ffffffff811ac868 ffffffff811ac831 ffffffff811ac828
        ffff8801195337c8 ffffffff811ac8c9 ffff8801195339b0 ffff8801197633e0
        0000000000000000 ffff8801195339b0 ffff8801195337d8 ffffffff811ad2d7
       Call Trace:
        [<ffffffff811ac868>] rcu_read_lock+0x37/0x6e
        [<ffffffff811ac831>] ? rcu_read_unlock+0x5f/0x5f
        [<ffffffff811ac828>] ? rcu_read_unlock+0x56/0x5f
        [<ffffffff811ac8c9>] __fget+0x2a/0x7a
        [<ffffffff811ad2d7>] fget+0x13/0x15
        [<ffffffff811be732>] proc_ns_fget+0xe/0x38
        [<ffffffff817c7714>] get_net_ns_by_fd+0x11/0x59
        [<ffffffff817df359>] rtnl_link_get_net+0x33/0x3e
        [<ffffffff817df3d7>] do_setlink+0x73/0x87b
        [<ffffffff810b28ce>] ? trace_hardirqs_off+0xd/0xf
        [<ffffffff81a2aa95>] ? retint_restore_args+0xe/0xe
        [<ffffffff817e0301>] rtnl_newlink+0x40c/0x699
        [<ffffffff817dffe0>] ? rtnl_newlink+0xeb/0x699
        [<ffffffff81a29246>] ? _raw_spin_unlock+0x28/0x33
        [<ffffffff8143ed1e>] ? security_capable+0x18/0x1a
        [<ffffffff8107da51>] ? ns_capable+0x4d/0x65
        [<ffffffff817de5ce>] rtnetlink_rcv_msg+0x181/0x194
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de407>] ? rtnl_lock+0x17/0x19
        [<ffffffff817de44d>] ? __rtnl_unlock+0x17/0x17
        [<ffffffff818327c6>] netlink_rcv_skb+0x4d/0x93
        [<ffffffff817de42f>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff81830f18>] netlink_unicast+0xcb/0x150
        [<ffffffff8183198e>] netlink_sendmsg+0x501/0x523
        [<ffffffff8115cba9>] ? might_fault+0x59/0xa9
        [<ffffffff817b5398>] ? copy_from_user+0x2a/0x2c
        [<ffffffff817b7b74>] sock_sendmsg+0x34/0x3c
        [<ffffffff817b7f6d>] ___sys_sendmsg+0x1b8/0x255
        [<ffffffff8115c5eb>] ? handle_pte_fault+0xbd5/0xd4a
        [<ffffffff8100a2b0>] ? native_sched_clock+0x35/0x37
        [<ffffffff8109e94b>] ? sched_clock_local+0x12/0x72
        [<ffffffff8109eb9c>] ? sched_clock_cpu+0x9e/0xb7
        [<ffffffff810cadbf>] ? rcu_read_lock_held+0x3b/0x3d
        [<ffffffff811ac1d8>] ? __fcheck_files+0x4c/0x58
        [<ffffffff811ac946>] ? __fget_light+0x2d/0x52
        [<ffffffff817b8adc>] __sys_sendmsg+0x42/0x60
        [<ffffffff817b8b0c>] SyS_sendmsg+0x12/0x1c
        [<ffffffff81a29e32>] system_call_fastpath+0x12/0x17
      
      Fixes: e7ed828f ("netlink: support setting devgroup parameters")
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c3bd57cd
    • Shachar Raindel's avatar
      IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic · c8f7da00
      Shachar Raindel authored
      commit 8494057a upstream.
      
      Properly verify that the resulting page aligned end address is larger
      than both the start address and the length of the memory area requested.
      
      Both the start and length arguments for ib_umem_get are controlled by
      the user. A misbehaving user can provide values which will cause an
      integer overflow when calculating the page aligned end address.
      
      This overflow can cause also miscalculation of the number of pages
      mapped, and additional logic issues.
      
      Addresses: CVE-2014-8159
      Signed-off-by: default avatarShachar Raindel <raindel@mellanox.com>
      Signed-off-by: default avatarJack Morgenstein <jackm@mellanox.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c8f7da00
    • Johannes Berg's avatar
      mac80211: fix RX A-MPDU session reorder timer deletion · e4687bfe
      Johannes Berg authored
      commit 788211d8 upstream.
      
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e4687bfe
    • Stefan Lippers-Hollmann's avatar
      x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk · 77f6f3ba
      Stefan Lippers-Hollmann authored
      commit 80313b30 upstream.
      
      The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
      both BIOS and UEFI mode while rebooting unless reboot=pci is
      used. Add a quirk to reboot via the pci method.
      
      The problem is very intermittent and hard to debug, it might succeed
      rebooting just fine 40 times in a row - but fails half a dozen times
      the next day. It seems to be slightly less common in BIOS CSM mode
      than native UEFI (with the CSM disabled), but it does happen in either
      mode. Since I've started testing this patch in late january, rebooting
      has been 100% reliable.
      
      Most of the time it already hangs during POST, but occasionally it
      might even make it through the bootloader and the kernel might even
      start booting, but then hangs before the mode switch. The same symptoms
      occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
      kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
      Upgrading to the most current mainboard firmware of the ASRock
      Q1900DC-ITX, version 1.20, does not improve the situation.
      
      ( Searching the web seems to suggest that other Bay Trail-D mainboards
        might be affected as well. )
      --
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mirSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      77f6f3ba
    • Peter Ujfalusi's avatar
      dmaengine: omap-dma: Fix memory leak when terminating running transfer · 61086ac6
      Peter Ujfalusi authored
      commit 02d88b73 upstream.
      
      In omap_dma_start_desc the vdesc->node is removed from the virt-dma
      framework managed lists (to be precise from the desc_issued list).
      If a terminate_all comes before the transfer finishes the omap_desc will
      not be freed up because it is not in any of the lists and we stopped the
      DMA channel so the transfer will not going to complete.
      There is no special sequence for leaking memory when using cyclic (audio)
      transfer: with every start and stop of a cyclic transfer the driver leaks
      struct omap_desc worth of memory.
      
      Free up the allocated memory directly in omap_dma_terminate_all() since the
      framework will not going to do that for us.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      61086ac6
    • Petr Kulhavy's avatar
      dmaengine: edma: fix memory leak when terminating running transfers · 14a39537
      Petr Kulhavy authored
      commit 5ca9e7ce upstream.
      
      If edma_terminate_all() was called while a transfer was running (i.e. after
      edma_execute() but before edma_callback()) the echan->edesc was not freed.
      
      This was due to the fact that a running transfer is on none of the
      vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
      removes it from the desc_issued list), so the vchan_dma_desc_free_list()
      called at the end of edma_terminate_all() didn't find it and didn't free it.
      
      This bug was found on an AM1808 based hardware (very similar to da850evm,
      however using the second MMC/SD controller), where intense operations on the SD
      card wasted the device 128MB RAM within a couple of days.
      
      Peter Ujfalusi:
      The issue is even more severe since it affects cyclic (audio) transfers as
      well. In this case starting/stopping audio will results memory leak.
      Signed-off-by: default avatarPetr Kulhavy <petr@barix.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      CC: <linux-omap@vger.kernel.org>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      14a39537