1. 01 Oct, 2013 5 commits
    • Hannes Frederic Sowa's avatar
      ipv6: gre: correct calculation of max_headroom · 3da812d8
      Hannes Frederic Sowa authored
      gre_hlen already accounts for sizeof(struct ipv6_hdr) + gre header,
      so initialize max_headroom to zero. Otherwise the
      
      	if (encap_limit >= 0) {
      		max_headroom += 8;
      		mtu -= 8;
      	}
      
      increments an uninitialized variable before max_headroom was reset.
      
      Found with coverity: 728539
      
      Cc: Dmitry Kozlov <xeb@mail.ru>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3da812d8
    • Aida Mynzhasova's avatar
      powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file · e58f6f4f
      Aida Mynzhasova authored
      Currently IEEE 1588 timer reference clock source is determined through
      hard-coded value in gianfar_ptp driver. This patch allows to select ptp
      clock source by means of device tree file node.
      
      For instance:
      
      	fsl,cksel = <0>;
      
      for using external (TSEC_TMR_CLK input) high precision timer
      reference clock.
      
      Other acceptable values:
      
      	<1> : eTSEC system clock
      	<2> : eTSEC1 transmit clock
      	<3> : RTC clock input
      
      When this attribute isn't used, eTSEC system clock will serve as
      IEEE 1588 timer reference clock.
      Signed-off-by: default avatarAida Mynzhasova <aida.mynzhasova@skitlab.ru>
      Acked-by: default avatarKumar Gala <galak@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e58f6f4f
    • David S. Miller's avatar
      Revert "powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file" · 3f3f0960
      David S. Miller authored
      This reverts commit 894116bd.
      
      I applied the wrong version of this patch, correct
      version coming up.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f3f0960
    • Neil Horman's avatar
      bonding: Fix broken promiscuity reference counting issue · 5a0068de
      Neil Horman authored
      Recently grabbed this report:
      https://bugzilla.redhat.com/show_bug.cgi?id=1005567
      
      Of an issue in which the bonding driver, with an attached vlan encountered the
      following errors when bond0 was taken down and back up:
      
      dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
      device might be broken.
      
      The error occurs because, during __bond_release_one, if we release our last
      slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
      notification.  With an attached vlan, the vlan may see that the vlan and bond
      mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
      and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
      we complete __bond_release_one, we use the current state of the bond flags to
      determine if we should decrement the promiscuity of the releasing slave.  But
      since the bond changed promiscuity state during the release operation, we
      incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
      to begin with, causing the above error
      
      Fix is pretty simple, just cache the bonding flags at the start of the function
      and use those when determining the need to set promiscuity.
      
      This is also needed for the ALLMULTI flag
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Mark Wu <wudxw@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Reported-by: default avatarMark Wu <wudxw@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a0068de
    • Eric Dumazet's avatar
      tcp: TSQ can use a dynamic limit · c9eeec26
      Eric Dumazet authored
      When TCP Small Queues was added, we used a sysctl to limit amount of
      packets queues on Qdisc/device queues for a given TCP flow.
      
      Problem is this limit is either too big for low rates, or too small
      for high rates.
      
      Now TCP stack has rate estimation in sk->sk_pacing_rate, and TSO
      auto sizing, it can better control number of packets in Qdisc/device
      queues.
      
      New limit is two packets or at least 1 to 2 ms worth of packets.
      
      Low rates flows benefit from this patch by having even smaller
      number of packets in queues, allowing for faster recovery,
      better RTT estimations.
      
      High rates flows benefit from this patch by allowing more than 2 packets
      in flight as we had reports this was a limiting factor to reach line
      rate. [ In particular if TX completion is delayed because of coalescing
      parameters ]
      
      Example for a single flow on 10Gbp link controlled by FQ/pacing
      
      14 packets in flight instead of 2
      
      $ tc -s -d qd
      qdisc fq 8001: dev eth0 root refcnt 32 limit 10000p flow_limit 100p
      buckets 1024 quantum 3028 initial_quantum 15140
       Sent 1168459366606 bytes 771822841 pkt (dropped 0, overlimits 0
      requeues 6822476)
       rate 9346Mbit 771713pps backlog 953820b 14p requeues 6822476
        2047 flow, 2046 inactive, 1 throttled, delay 15673 ns
        2372 gc, 0 highprio, 0 retrans, 9739249 throttled, 0 flows_plimit
      
      Note that sk_pacing_rate is currently set to twice the actual rate, but
      this might be refined in the future when a flow is in congestion
      avoidance.
      
      Additional change : skb->destructor should be set to tcp_wfree().
      
      A future patch (for linux 3.13+) might remove tcp_limit_output_bytes
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9eeec26
  2. 30 Sep, 2013 10 commits
  3. 28 Sep, 2013 4 commits
  4. 27 Sep, 2013 18 commits
  5. 26 Sep, 2013 3 commits
    • Roger Luethi's avatar
      via-rhine: fix VLAN priority field (PCP, IEEE 802.1p) · 207070f5
      Roger Luethi authored
      Outgoing packets sent by via-rhine have their VLAN PCP field off by one
      (when hardware acceleration is enabled). The TX descriptor expects only VID
      and PCP (without a CFI/DEI bit).
      
      Peter Boström noticed and reported the bug.
      Signed-off-by: default avatarRoger Luethi <rl@hellgate.ch>
      Cc: Peter Boström <peter.bostrom@netrounds.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      207070f5
    • Arend van Spriel's avatar
      brcmsmac: call bcma_core_pci_power_save() from non-atomic context · c7515d23
      Arend van Spriel authored
      This patch adds explicit call to bcma_core_pci_power_save() from
      a non-atomic context resolving 'scheduling while atomic' issue.
      
      [   13.224317] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
      [   13.224322] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
      [   13.224354] CPU: 0 PID: 1800 Comm: dhcpcd Tainted: G        W    3.11.0-wl #1
      [   13.224359] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
      [   13.224363]  ffff880177c12c40 ffff880170fd1968 ffffffff8169af5b 0000000000000007
      [   13.224374]  ffff880170fd1ad0 ffff880170fd1978 ffffffff81697ee2 ffff880170fd19f8
      [   13.224383]  ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
      [   13.224391] Call Trace:
      [   13.224399]  [<ffffffff8169af5b>] dump_stack+0x4f/0x84
      [   13.224403]  [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
      [   13.224409]  [<ffffffff816a19f5>] __schedule+0x6e5/0x810
      [   13.224412]  [<ffffffff816a1c34>] schedule+0x24/0x70
      [   13.224416]  [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
      [   13.224420]  [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
      [   13.224424]  [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
      [   13.224429]  [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
      [   13.224432]  [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
      [   13.224437]  [<ffffffffa003733a>] bcma_pcie_mdio_read.isra.5+0x8a/0x100 [bcma]
      [   13.224442]  [<ffffffffa00374a5>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x25/0x30 [bcma]
      [   13.224448]  [<ffffffffa00374f9>] bcma_core_pci_power_save+0x49/0x80 [bcma]
      [   13.224452]  [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
      [   13.224460]  [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
      [   13.224467]  [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
      [   13.224473]  [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
      [   13.224478]  [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
      [   13.224483]  [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
      [   13.224487]  [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
      [   13.224491]  [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
      [   13.224495]  [<ffffffff81657b41>] ieee80211_open+0x71/0x80
      [   13.224498]  [<ffffffff81526267>] __dev_open+0x87/0xe0
      [   13.224502]  [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
      [   13.224505]  [<ffffffff815266a3>] dev_change_flags+0x23/0x70
      [   13.224509]  [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
      [   13.224512]  [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
      [   13.224516]  [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
      [   13.224519]  [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
      [   13.224523]  [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
      [   13.224528]  [<ffffffff8113f159>] ? ____fput+0x9/0x10
      [   13.224533]  [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
      [   13.224537]  [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
      [   13.224541]  [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
      
      Cc: <stable@vger.kernel.org> # 3.11.x
      Cc: Tod Jackson <tod.jackson@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c7515d23
    • Arend van Spriel's avatar
      bcma: make bcma_core_pci_{up,down}() callable from atomic context · 2bedea8f
      Arend van Spriel authored
      This patch removes the bcma_core_pci_power_save() call from
      the bcma_core_pci_{up,down}() functions as it tries to schedule
      thus requiring to call them from non-atomic context. The function
      bcma_core_pci_power_save() is now exported so the calling module
      can explicitly use it in non-atomic context. This fixes the
      'scheduling while atomic' issue reported by Tod Jackson and
      Joe Perches.
      
      [   13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
      [   13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
      [   13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
      [   13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
      [   13.210767]  ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b 0000000000000007
      [   13.210777]  ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2 ffff880170fd19d8
      [   13.210785]  ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
      [   13.210794] Call Trace:
      [   13.210813]  [<ffffffff8169af5b>] dump_stack+0x4f/0x84
      [   13.210826]  [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
      [   13.210837]  [<ffffffff816a19f5>] __schedule+0x6e5/0x810
      [   13.210845]  [<ffffffff816a1c34>] schedule+0x24/0x70
      [   13.210855]  [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
      [   13.210867]  [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
      [   13.210877]  [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
      [   13.210887]  [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
      [   13.210897]  [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
      [   13.210910]  [<ffffffffa00371af>] bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
      [   13.210921]  [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0 [bcma]
      [   13.210932]  [<ffffffffa0037498>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
      [   13.210942]  [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80 [bcma]
      [   13.210953]  [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
      [   13.210975]  [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
      [   13.210989]  [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
      [   13.211003]  [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
      [   13.211020]  [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
      [   13.211030]  [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
      [   13.211064]  [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
      [   13.211076]  [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
      [   13.211086]  [<ffffffff81657b41>] ieee80211_open+0x71/0x80
      [   13.211101]  [<ffffffff81526267>] __dev_open+0x87/0xe0
      [   13.211109]  [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
      [   13.211117]  [<ffffffff815266a3>] dev_change_flags+0x23/0x70
      [   13.211127]  [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
      [   13.211136]  [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
      [   13.211147]  [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
      [   13.211155]  [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
      [   13.211169]  [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
      [   13.211180]  [<ffffffff8113f159>] ? ____fput+0x9/0x10
      [   13.211198]  [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
      [   13.211202]  [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
      [   13.211208]  [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
      [   13.211217] NOHZ: local_softirq_pending 202
      
      The issue was introduced in v3.11 kernel by following commit:
      
      commit aa51e598
      Author: Hauke Mehrtens <hauke@hauke-m.de>
      Date:   Sat Aug 24 00:32:31 2013 +0200
      
          brcmsmac: use bcma PCIe up and down functions
      
          replace the calls to bcma_core_pci_extend_L1timer() by calls to the
          newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
          Cc: Arend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      
      This fix has been discussed with Hauke Mehrtens [1] selection
      option 3) and is intended for v3.12.
      
      Ref:
      [1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de
      
      Cc: <stable@vger.kernel.org> # 3.11.x
      Cc: Tod Jackson <tod.jackson@gmail.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2bedea8f