1. 16 9月, 2015 6 次提交
  2. 04 9月, 2015 3 次提交
    • J
      IB/ipoib: Suppress warning for send only join failures · d1178cbc
      Jason Gunthorpe 提交于
      We expect send only joins to fail, it just means there are no listeners
      for the group. The correct thing to do is silently drop the packet
      at source.
      
      Eg avahi will full join 224.0.0.251 which causes a send only IGMP packet
      to 224.0.0.22, and then a warning level kmessage like this:
      
       ib0: sendonly multicast join failed for ff12:401b:ffff:0000:0000:0000:0000:0016, status -22
      
      If there is no IP router listening to IGMP.
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      d1178cbc
    • D
      IB/ipoib: Clean up send-only multicast joins · c3acdc06
      Doug Ledford 提交于
      Even though we don't expect the group to be created by the SM we
      sill need to provide all the parameters to force the SM to validate
      they are correct.
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c3acdc06
    • S
      IB/srp: Fix possible protection fault · 7fbc67df
      Sagi Grimberg 提交于
      srp_destroy_qp is designed to indicate we are safe to continue with
      freeing the channel resources by modifying the qp error state,
      posting a dummy wr on the queue-pair and waiting for it to flush.
      This also holds for the channel registration pool as we are unmapping
      the memory region when handling a scsi response. Destroying the
      channel registration pool before we make sure we processed all the
      inflight IO might introduce a use-after-free of the registration pool.
      
      This use-after-free is demonstrated in the stack trace below where
      srp is trying to unmap a used FMR after the fmr_pool was already destroyed.
      
      general protection fault: 0000 [#1] SMP
      RIP: 0010:[<ffffffff8151121b>]  [<ffffffff8151121b>] _raw_spin_lock_irqsave+0x1b/0x50
      Call Trace:
       [<ffffffffa055d88a>] ib_fmr_pool_unmap+0x1a/0xb0 [ib_core]
       [<ffffffffa06c00ed>] srp_unmap_data.isra.28+0x17d/0x250 [ib_srp]
       [<ffffffffa06c01eb>] srp_free_req+0x2b/0x60 [ib_srp]
       [<ffffffffa06c0c94>] srp_recv_completion+0x174/0x580 [ib_srp]
       [<ffffffffa04580fe>] mlx4_eq_int+0x4de/0xe50 [mlx4_core]
       [<ffffffffa0458b00>] mlx4_msi_x_interrupt+0x10/0x20 [mlx4_core]
       [<ffffffff810abc45>] handle_irq_event_percpu+0x35/0x1b0
       [<ffffffff810abdf2>] handle_irq_event+0x32/0x50
       [<ffffffff810ae5cf>] handle_edge_irq+0x6f/0x120
       [<ffffffff8100455a>] handle_irq+0x1a/0x30
       [<ffffffff8151b475>] do_IRQ+0x45/0xb0
       [<ffffffff8151162d>] common_interrupt+0x6d/0x6d
       [<ffffffff813e4d2f>] cpuidle_enter_state+0x4f/0xc0
       [<ffffffff813e4e6c>] cpuidle_idle_call+0xcc/0x210
       [<ffffffff8100b9ea>] arch_cpu_idle+0xa/0x30
       [<ffffffff810ab1e1>] cpu_startup_entry+0xe1/0x270
       [<ffffffff81030b3a>] start_secondary+0x21a/0x2c0
      Reported-by: NEliott Kespi <eliottk@mellanox.com>
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      7fbc67df
  3. 31 8月, 2015 31 次提交