1. 31 5月, 2019 2 次提交
    • S
      nvme-tcp: fix queue mapping when queue count is limited · 64861993
      Sagi Grimberg 提交于
      When the controller supports less queues than requested, we
      should make sure that queue mapping does the right thing and
      not assume that all queues are available. This fixes a crash
      when the controller supports less queues than requested.
      
      The rules are:
      1. if no write queues are requested, we assign the available queues
         to the default queue map. The default and read queue maps share the
         existing queues.
      2. if write queues are requested:
        - first make sure that read queue map gets the requested
          nr_io_queues count
        - then grant the default queue map the minimum between the requested
          nr_write_queues and the remaining queues. If there are no available
          queues to dedicate to the default queue map, fallback to (1) and
          share all the queues in the existing queue map.
      
      Also, provide a log indication on how we constructed the different
      queue maps.
      Reported-by: NHarris, James R <james.r.harris@intel.com>
      Tested-by: NJim Harris <james.r.harris@intel.com>
      Cc: <stable@vger.kernel.org> # v5.0+
      Suggested-by: NRoy Shterman <roys@lightbitslabs.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      64861993
    • S
      nvme-rdma: fix queue mapping when queue count is limited · 5651cd3c
      Sagi Grimberg 提交于
      When the controller supports less queues than requested, we
      should make sure that queue mapping does the right thing and
      not assume that all queues are available. This fixes a crash
      when the controller supports less queues than requested.
      
      The rules are:
      1. if no write/poll queues are requested, we assign the available queues
         to the default queue map. The default and read queue maps share the
         existing queues.
      2. if write queues are requested:
        - first make sure that read queue map gets the requested
          nr_io_queues count
        - then grant the default queue map the minimum between the requested
          nr_write_queues and the remaining queues. If there are no available
          queues to dedicate to the default queue map, fallback to (1) and
          share all the queues in the existing queue map.
      3. if poll queues are requested:
        - map the remaining queues to the poll queue map.
      
      Also, provide a log indication on how we constructed the different
      queue maps.
      Reported-by: NHarris, James R <james.r.harris@intel.com>
      Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
      Tested-by: NJim Harris <james.r.harris@intel.com>
      Cc: <stable@vger.kernel.org> # v5.0+
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      5651cd3c
  2. 23 5月, 2019 1 次提交
    • K
      nvme-pci: use blk-mq mapping for unmanaged irqs · cb9e0e50
      Keith Busch 提交于
      If a device is providing a single IRQ vector, the IO queue will share
      that vector with the admin queue. This is an unmanaged vector, so does
      not have a valid PCI IRQ affinity. Avoid trying to extract a managed
      affinity in this case and let blk-mq set up the cpu:queue mapping instead.
      Otherwise we'd hit the following warning when the device is using MSI:
      
       WARNING: CPU: 4 PID: 7 at drivers/pci/msi.c:1272 pci_irq_get_affinity+0x66/0x80
       Modules linked in: nvme nvme_core serio_raw
       CPU: 4 PID: 7 Comm: kworker/u16:0 Tainted: G        W         5.2.0-rc1+ #494
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
       Workqueue: nvme-reset-wq nvme_reset_work [nvme]
       RIP: 0010:pci_irq_get_affinity+0x66/0x80
       Code: 0b 31 c0 c3 83 e2 10 48 c7 c0 b0 83 35 91 74 2a 48 8b 87 d8 03 00 00 48 85 c0 74 0e 48 8b 50 30 48 85 d2 74 05 39 70 14 77 05 <0f> 0b 31 c0 c3 48 63 f6 48 8d 04 76 48 8d 04 c2 f3 c3 48 8b 40 30
       RSP: 0000:ffffb5abc01d3cc8 EFLAGS: 00010246
       RAX: ffff9536786a39c0 RBX: 0000000000000000 RCX: 0000000000000080
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9536781ed000
       RBP: ffff95367346a008 R08: ffff95367d43f080 R09: ffff953678c07800
       R10: ffff953678164800 R11: 0000000000000000 R12: 0000000000000000
       R13: ffff9536781ed000 R14: 00000000ffffffff R15: ffff95367346a008
       FS:  0000000000000000(0000) GS:ffff95367d400000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007fdf814a3ff0 CR3: 000000001a20f000 CR4: 00000000000006e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        blk_mq_pci_map_queues+0x37/0xd0
        nvme_pci_map_queues+0x80/0xb0 [nvme]
        blk_mq_alloc_tag_set+0x133/0x2f0
        nvme_reset_work+0x105d/0x1590 [nvme]
        process_one_work+0x291/0x530
        worker_thread+0x218/0x3d0
        ? process_one_work+0x530/0x530
        kthread+0x111/0x130
        ? kthread_park+0x90/0x90
        ret_from_fork+0x1f/0x30
       ---[ end trace 74587339d93c83c0 ]---
      
      Fixes: 22b55601 ("nvme-pci: Separate IO and admin queue IRQ vectors")
      Reported-by: NIván Chavero <ichavero@chavero.com.mx>
      Reviewed-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      cb9e0e50
  3. 21 5月, 2019 1 次提交
  4. 18 5月, 2019 10 次提交
  5. 14 5月, 2019 4 次提交
  6. 13 5月, 2019 6 次提交
  7. 07 5月, 2019 1 次提交
  8. 01 5月, 2019 11 次提交
  9. 25 4月, 2019 4 次提交