1. 10 4月, 2018 1 次提交
  2. 22 3月, 2018 5 次提交
  3. 13 3月, 2018 1 次提交
  4. 02 3月, 2018 5 次提交
    • D
      scsi: qla2xxx: Fix FC-NVMe LUN discovery · 2b5b9647
      Darren Trapp 提交于
      commit a4239945 ("scsi: qla2xxx: Add switch command to simplify
      fabric discovery") introduced regression when it did not consider
      FC-NVMe code path which broke NVMe LUN discovery.
      
      Fixes: a4239945 ("scsi: qla2xxx: Add switch command to simplify fabric discovery")
      Signed-off-by: NDarren Trapp <darren.trapp@cavium.com>
      Signed-off-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      2b5b9647
    • H
      scsi: qla2xxx: ensure async flags are reset correctly · fa83e658
      Hannes Reinecke 提交于
      The fcport flags FCF_ASYNC_ACTIVE and FCF_ASYNC_SENT are used to
      throttle the state machine, so we need to ensure to always set and unset
      them correctly. Not doing so will lead to the state machine getting
      confused and no login attempt into remote ports.
      
      Cc: Quinn Tran <quinn.tran@cavium.com>
      Cc: Himanshu Madhani <himanshu.madhani@cavium.com>
      Fixes: 3dbec59b ("scsi: qla2xxx: Prevent multiple active discovery commands per session")
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Acked-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      fa83e658
    • H
      scsi: qla2xxx: do not check login_state if no loop id is assigned · 07ea4b60
      Hannes Reinecke 提交于
      When no loop id is assigned in qla24xx_fcport_handle_login() the login
      state needs to be ignored; it will get set later on in
      qla_chk_n2n_b4_login().
      
      Cc: Quinn Tran <quinn.tran@cavium.com>
      Cc: Himanshu Madhani <himanshu.madhani@cavium.com>
      Fixes: 040036bb ("scsi: qla2xxx: Delay loop id allocation at login")
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Acked-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      07ea4b60
    • H
      scsi: qla2xxx: Fixup locking for session deletion · 1c6cacf4
      Hannes Reinecke 提交于
      Commit d8630bb9 ('Serialize session deletion by using work_lock')
      tries to fixup a deadlock when deleting sessions, but fails to take into
      account the locking rules. This patch resolves the situation by
      introducing a separate lock for processing the GNLIST response, and
      ensures that sess_lock is released before calling
      qlt_schedule_sess_delete().
      
      Cc: Himanshu Madhani <himanshu.madhani@cavium.com>
      Cc: Quinn Tran <quinn.tran@cavium.com>
      Fixes: d8630bb9 ("scsi: qla2xxx: Serialize session deletion by using work_lock")
      Signed-off-by: NHannes Reinecke <hare@suse.com>
      Acked-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      1c6cacf4
    • H
      scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS · 1514839b
      himanshu.madhani@cavium.com 提交于
      This patch fixes NULL pointer crash due to active timer running for abort
      IOCB.
      
      From crash dump analysis it was discoverd that get_next_timer_interrupt()
      encountered a corrupted entry on the timer list.
      
       #9 [ffff95e1f6f0fd40] page_fault at ffffffff914fe8f8
          [exception RIP: get_next_timer_interrupt+440]
          RIP: ffffffff90ea3088  RSP: ffff95e1f6f0fdf0  RFLAGS: 00010013
          RAX: ffff95e1f6451028  RBX: 000218e2389e5f40  RCX: 00000001232ad600
          RDX: 0000000000000001  RSI: ffff95e1f6f0fdf0  RDI: 0000000001232ad6
          RBP: ffff95e1f6f0fe40   R8: ffff95e1f6451188   R9: 0000000000000001
          R10: 0000000000000016  R11: 0000000000000016  R12: 00000001232ad5f6
          R13: ffff95e1f6450000  R14: ffff95e1f6f0fdf8  R15: ffff95e1f6f0fe10
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
      
      Looking at the assembly of get_next_timer_interrupt(), address came
      from %r8 (ffff95e1f6451188) which is pointing to list_head with single
      entry at ffff95e5ff621178.
      
       0xffffffff90ea307a <get_next_timer_interrupt+426>:      mov    (%r8),%rdx
       0xffffffff90ea307d <get_next_timer_interrupt+429>:      cmp    %r8,%rdx
       0xffffffff90ea3080 <get_next_timer_interrupt+432>:      je     0xffffffff90ea30a7 <get_next_timer_interrupt+471>
       0xffffffff90ea3082 <get_next_timer_interrupt+434>:      nopw   0x0(%rax,%rax,1)
       0xffffffff90ea3088 <get_next_timer_interrupt+440>:      testb  $0x1,0x18(%rdx)
      
       crash> rd ffff95e1f6451188 10
       ffff95e1f6451188:  ffff95e5ff621178 ffff95e5ff621178   x.b.....x.b.....
       ffff95e1f6451198:  ffff95e1f6451198 ffff95e1f6451198   ..E.......E.....
       ffff95e1f64511a8:  ffff95e1f64511a8 ffff95e1f64511a8   ..E.......E.....
       ffff95e1f64511b8:  ffff95e77cf509a0 ffff95e77cf509a0   ...|.......|....
       ffff95e1f64511c8:  ffff95e1f64511c8 ffff95e1f64511c8   ..E.......E.....
      
       crash> rd ffff95e5ff621178 10
       ffff95e5ff621178:  0000000000000001 ffff95e15936aa00   ..........6Y....
       ffff95e5ff621188:  0000000000000000 00000000ffffffff   ................
       ffff95e5ff621198:  00000000000000a0 0000000000000010   ................
       ffff95e5ff6211a8:  ffff95e5ff621198 000000000000000c   ..b.............
       ffff95e5ff6211b8:  00000f5800000000 ffff95e751f8d720   ....X... ..Q....
      
       ffff95e5ff621178 belongs to freed mempool object at ffff95e5ff621080.
      
       CACHE            NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE
       ffff95dc7fd74d00 mnt_cache                384      19785     24948    594    16k
         SLAB              MEMORY            NODE  TOTAL  ALLOCATED  FREE
         ffffdc5dabfd8800  ffff95e5ff620000     1     42         29    13
         FREE / [ALLOCATED]
          ffff95e5ff621080  (cpu 6 cache)
      
      Examining the contents of that memory reveals a pointer to a constant string
      in the driver, "abort\0", which is set by qla24xx_async_abort_cmd().
      
       crash> rd ffffffffc059277c 20
       ffffffffc059277c:  6e490074726f6261 0074707572726574   abort.Interrupt.
       ffffffffc059278c:  00676e696c6c6f50 6920726576697244   Polling.Driver i
       ffffffffc059279c:  646f6d207325206e 6974736554000a65   n %s mode..Testi
       ffffffffc05927ac:  636976656420676e 786c252074612065   ng device at %lx
       ffffffffc05927bc:  6b63656843000a2e 646f727020676e69   ...Checking prod
       ffffffffc05927cc:  6f20444920746375 0a2e706968632066   uct ID of chip..
       ffffffffc05927dc:  5120646e756f4600 204130303232414c   .Found QLA2200A
       ffffffffc05927ec:  43000a2e70696843 20676e696b636568   Chip...Checking
       ffffffffc05927fc:  65786f626c69616d 6c636e69000a2e73   mailboxes...incl
       ffffffffc059280c:  756e696c2f656475 616d2d616d642f78   ude/linux/dma-ma
      
       crash> struct -ox srb_iocb
       struct srb_iocb {
                 union {
                     struct {...} logio;
                     struct {...} els_logo;
                     struct {...} tmf;
                     struct {...} fxiocb;
                     struct {...} abt;
                     struct ct_arg ctarg;
                     struct {...} mbx;
                     struct {...} nack;
          [0x0 ] } u;
          [0xb8] struct timer_list timer;
          [0x108] void (*timeout)(void *);
       }
       SIZE: 0x110
      
       crash> ! bc
       ibase=16
       obase=10
       B8+40
       F8
      
      The object is a srb_t, and at offset 0xf8 within that structure
      (i.e. ffff95e5ff621080 + f8 -> ffff95e5ff621178) is a struct timer_list.
      
      Cc: <stable@vger.kernel.org> #4.4+
      Fixes: 4440e46d ("[SCSI] qla2xxx: Add IOCB Abort command asynchronous handling.")
      Signed-off-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      1514839b
  5. 14 2月, 2018 1 次提交
    • Q
      scsi: qla2xxx: Fix double free bug after firmware timeout · eaf75d18
      Quinn Tran 提交于
      This patch is based on Max's original patch.
      
      When the qla2xxx firmware is unavailable, eventually
      qla2x00_sp_timeout() is reached, which calls the timeout function and
      frees the srb_t instance.
      
      The timeout function always resolves to qla2x00_async_iocb_timeout(),
      which invokes another callback function called "done".  All of these
      qla2x00_*_sp_done() callbacks also free the srb_t instance; after
      returning to qla2x00_sp_timeout(), it is freed again.
      
      The fix is to remove the "sp->free(sp)" call from qla2x00_sp_timeout()
      and add it to those code paths in qla2x00_async_iocb_timeout() which
      do not already free the object.
      
      This is how it looks like with KASAN:
      
      BUG: KASAN: use-after-free in qla2x00_sp_timeout+0x228/0x250
      Read of size 8 at addr ffff88278147a590 by task swapper/2/0
      
      Allocated by task 1502:
      save_stack+0x33/0xa0
      kasan_kmalloc+0xa0/0xd0
      kmem_cache_alloc+0xb8/0x1c0
      mempool_alloc+0xd6/0x260
      qla24xx_async_gnl+0x3c5/0x1100
      
      Freed by task 0:
      save_stack+0x33/0xa0
      kasan_slab_free+0x72/0xc0
      kmem_cache_free+0x75/0x200
      qla24xx_async_gnl_sp_done+0x556/0x9e0
      qla2x00_async_iocb_timeout+0x1c7/0x420
      qla2x00_sp_timeout+0x16d/0x250
      call_timer_fn+0x36/0x200
      
      The buggy address belongs to the object at ffff88278147a440
      which belongs to the cache qla2xxx_srbs of size 344
      The buggy address is located 336 bytes inside of
      344-byte region [ffff88278147a440, ffff88278147a598)
      Reported-by: NMax Kellermann <mk@cm4all.com>
      Signed-off-by: NQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Cc: Max Kellermann <mk@cm4all.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      eaf75d18
  6. 13 2月, 2018 2 次提交
  7. 23 1月, 2018 1 次提交
  8. 17 1月, 2018 2 次提交
  9. 04 1月, 2018 22 次提交