1. 29 10月, 2015 1 次提交
    • S
      IB/iser: set block queue_virt_boundary · dd0107a0
      Sagi Grimberg 提交于
      The block layer can reliably guarantee that SG lists won't
      contain gaps (page unaligned) if a driver set the queue
      virt_boundary.
      
      With this setting the block layer will:
      - refuse merges if bios are not aligned to the virtual boundary
      - split bios/requests that are not aligned to the virtual boundary
      - or, bounce buffer SG_IOs that are not aligned to the virtual boundary
      
      Since iser is working in 4K page size, set the virt_boundary to
      4K pages. With this setting, we can now safely remove the bounce
      buffering logic in iser.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      dd0107a0
  2. 23 10月, 2015 2 次提交
  3. 22 10月, 2015 2 次提交
  4. 14 10月, 2015 1 次提交
  5. 26 9月, 2015 3 次提交
    • D
      IB/ipoib: increase the max mcast backlog queue · 2866196f
      Doug Ledford 提交于
      When performing sendonly joins, we queue the packets that trigger
      the join until the join completes.  This may take on the order of
      hundreds of milliseconds.  It is easy to have many more than three
      packets come in during that time.  Expand the maximum queue depth
      in order to try and prevent dropped packets during the time it
      takes to join the multicast group.
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      2866196f
    • D
      IB/ipoib: Make sendonly multicast joins create the mcast group · c3852ab0
      Doug Ledford 提交于
      Since IPoIB should, as much as possible, emulate how multicast
      sends work on Ethernet for regular TCP/IP apps, there should be
      no requirement to subscribe to a multicast group before your
      sends are properly sent.  However, due to the difference in how
      multicast is handled on InfiniBand, we must join the appropriate
      multicast group before we can send to it.  Previously we tried
      not to trigger the auto-create feature of the subnet manager when
      doing this because we didn't have tracking of these sendonly
      groups and the auto-creation might never get undone.  The previous
      patch added timing to these sendonly joins and allows us to
      leave them after a reasonable idle expiration time.  So supply
      all of the information needed to auto-create group.
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c3852ab0
    • C
      IB/ipoib: Expire sendonly multicast joins · bd99b2e0
      Christoph Lameter 提交于
      On neighbor expiration, check to see if the neighbor was actually a
      sendonly multicast join, and if so, leave the multicast group as we
      expire the neighbor.
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      bd99b2e0
  6. 25 9月, 2015 1 次提交
  7. 16 9月, 2015 7 次提交
  8. 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
  9. 31 8月, 2015 20 次提交