1. 28 7月, 2015 3 次提交
  2. 09 7月, 2015 2 次提交
  3. 25 6月, 2015 4 次提交
  4. 24 6月, 2015 2 次提交
  5. 16 6月, 2015 11 次提交
  6. 13 6月, 2015 1 次提交
  7. 12 6月, 2015 2 次提交
  8. 04 6月, 2015 4 次提交
  9. 31 5月, 2015 4 次提交
  10. 28 5月, 2015 2 次提交
    • R
      cpumask_set_cpu_local_first => cpumask_local_spread, lament · f36963c9
      Rusty Russell 提交于
      da91309e (cpumask: Utility function to set n'th cpu...) created a
      genuinely weird function.  I never saw it before, it went through DaveM.
      (He only does this to make us other maintainers feel better about our own
      mistakes.)
      
      cpumask_set_cpu_local_first's purpose is say "I need to spread things
      across N online cpus, choose the ones on this numa node first"; you call
      it in a loop.
      
      It can fail.  One of the two callers ignores this, the other aborts and
      fails the device open.
      
      It can fail in two ways: allocating the off-stack cpumask, or through a
      convoluted codepath which AFAICT can only occur if cpu_online_mask
      changes.  Which shouldn't happen, because if cpu_online_mask can change
      while you call this, it could return a now-offline cpu anyway.
      
      It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
      drawn to my attention by Geert, who said this causes a warning on Sparc.
      It sets a single bit in a cpumask instead of returning a cpu number,
      because that's what the callers want.
      
      It could be made more efficient by passing the previous cpu rather than
      an index, but that would be more invasive to the callers.
      
      Fixes: da91309e
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
      Tested-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NAmir Vadai <amirv@mellanox.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      f36963c9
    • B
      mlx4_core: Fix fallback from MSI-X to INTx · f4ecf29f
      Benjamin Poirier 提交于
      The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
      fail with -EBUSY. It is also necessary to avoid the reset since the device
      is not fully reinitialized before calling mlx4_start_hca() a second time.
      
      Note that this will also affect mlx4_test_interrupts(), the only other user
      of MLX4_CMD_NOP.
      
      Fixes: f5aef5aa ("net/mlx4_core: Activate reset flow upon fatal command cases")
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4ecf29f
  11. 25 5月, 2015 5 次提交