1. 23 Jan, 2012 5 commits
  2. 22 Jan, 2012 19 commits
  3. 20 Jan, 2012 3 commits
    • Neal Cardwell's avatar
      tcp: fix undo after RTO for CUBIC · 5a45f008
      Neal Cardwell authored
      This patch fixes CUBIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Acked-by: default avatarSangtae Ha <sangtae.ha@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a45f008
    • Neal Cardwell's avatar
      tcp: fix undo after RTO for BIC · fc16dcd8
      Neal Cardwell authored
      This patch fixes BIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc16dcd8
    • Roopa Prabhu's avatar
      enic: fix compile when CONFIG_PCI_IOV is not enabled · b67f231d
      Roopa Prabhu authored
      reverting back change that access enic->num_vfs outside
      CONFIG_PCI_IOV
      Reported-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: default avatarRoopa Prabhu <roprabhu@cisco.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b67f231d
  4. 19 Jan, 2012 11 commits
  5. 18 Jan, 2012 2 commits
    • Darren Hart's avatar
      pch_gbe: Do not abort probe on bad MAC · 2b53d078
      Darren Hart authored
      If the MAC is invalid or not implemented, do not abort the probe. Issue
      a warning and prevent bringing the interface up until a MAC is set manually
      (via ifconfig $IFACE hw ether $MAC).
      
      Tested on two platforms, one with a valid MAC, the other without a MAC. The real
      MAC is used if present, the interface fails to come up until the MAC is set on
      the other. They successfully get an IP over DHCP and pass a simple ping and
      login over ssh test.
      
      This is meant to allow the Inforce SYS940X development board:
      http://www.inforcecomputing.com/SYS940X_ECX.html
      (and others suffering from a missing MAC) to work with the mainline kernel.
      Without this patch, the probe will fail and the interface will not be created,
      preventing the user from configuring the MAC manually.
      
      This does not make any attempt to address a missing or invalid MAC for the
      pch_phub driver.
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      CC: Alan Cox <alan@linux.intel.com>
      CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Paul Gortmaker <paul.gortmaker@windriver.com>
      CC: Jon Mason <jdmason@kudzu.us>
      CC: netdev@vger.kernel.org
      CC: Mark Brown <broonie@opensource.wolfsonmicro.com>
      CC: David Laight <David.Laight@ACULAB.COM>
      CC: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b53d078
    • Francesco Ruggeri's avatar
      net: race condition in ipv6 forwarding and disable_ipv6 parameters · 013d97e9
      Francesco Ruggeri authored
      There is a race condition in addrconf_sysctl_forward() and
      addrconf_sysctl_disable().
      These functions change idev->cnf.forwarding (resp. idev->cnf.disable_ipv6)
      and then try to grab the rtnl lock before performing any actions.
      If that fails they restore the original value and restart the syscall.
      This creates race conditions if ipv6 code tries to access
      these parameters, or if multiple instances try to do the same operation.
      As an example of the former, if __ipv6_ifa_notify() finds a 0 in
      idev->cnf.forwarding when invoked by addrconf_ifdown() it may not free
      anycast addresses, ultimately resulting in the net_device not being freed.
      This patch reads the user parameters into a temporary location and only
      writes the actual parameters when the rtnl lock is acquired.
      Tested in 2.6.38.8.
      Signed-off-by: default avatarFrancesco Ruggeri <fruggeri@aristanetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      013d97e9