1. 12 1月, 2017 3 次提交
  2. 10 1月, 2017 2 次提交
    • D
      scsi: qla2xxx: Fix apparent cut-n-paste error. · c3c42394
      Dave Jones 提交于
      Commit 093df737 ("scsi: qla2xxx: Fix Target mode handling with
      Multiqueue changes.") introduces two bodies of code that look similar
      but with s/req/rsp/ in the second instance.  But in one case, it looks
      like this conversion was missed.
      Signed-off-by: NDave Jones <davej@codemonkey.org.uk>
      Reviewed-by: NLaurence Oberman <loberman@redhat.com>
      Acked-by: NQuinn Tran <Quinn.Tran@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c3c42394
    • M
      scsi: qla2xxx: Get mutex lock before checking optrom_state · c7702b8c
      Milan P. Gandhi 提交于
      There is a race condition with qla2xxx optrom functions where one thread
      might modify optrom buffer, optrom_state while other thread is still
      reading from it.
      
      In couple of crashes, it was found that we had successfully passed the
      following 'if' check where we confirm optrom_state to be
      QLA_SREADING. But by the time we acquired mutex lock to proceed with
      memory_read_from_buffer function, some other thread/process had already
      modified that option rom buffer and optrom_state from QLA_SREADING to
      QLA_SWAITING. Then we got ha->optrom_buffer 0x0 and crashed the system:
      
              if (ha->optrom_state != QLA_SREADING)
                      return 0;
      
              mutex_lock(&ha->optrom_mutex);
              rval = memory_read_from_buffer(buf, count, &off, ha->optrom_buffer,
                  ha->optrom_region_size);
              mutex_unlock(&ha->optrom_mutex);
      
      With current optrom function we get following crash due to a race
      condition:
      
      [ 1479.466679] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [ 1479.466707] IP: [<ffffffff81326756>] memcpy+0x6/0x110
      [...]
      [ 1479.473673] Call Trace:
      [ 1479.474296]  [<ffffffff81225cbc>] ? memory_read_from_buffer+0x3c/0x60
      [ 1479.474941]  [<ffffffffa01574dc>] qla2x00_sysfs_read_optrom+0x9c/0xc0 [qla2xxx]
      [ 1479.475571]  [<ffffffff8127e76b>] read+0xdb/0x1f0
      [ 1479.476206]  [<ffffffff811fdf9e>] vfs_read+0x9e/0x170
      [ 1479.476839]  [<ffffffff811feb6f>] SyS_read+0x7f/0xe0
      [ 1479.477466]  [<ffffffff816964c9>] system_call_fastpath+0x16/0x1b
      
      Below patch modifies qla2x00_sysfs_read_optrom,
      qla2x00_sysfs_write_optrom functions to get the mutex_lock before
      checking ha->optrom_state to avoid similar crashes.
      
      The patch was applied and tested and same crashes were no longer
      observed again.
      Tested-by: NMilan P. Gandhi <mgandhi@redhat.com>
      Signed-off-by: NMilan P. Gandhi <mgandhi@redhat.com>
      Reviewed-by: NLaurence Oberman <loberman@redhat.com>
      Acked-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c7702b8c
  3. 06 1月, 2017 3 次提交
  4. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      Thomas Gleixner 提交于
      ktime_set(S,N) was required for the timespec storage type and is still
      useful for situations where a Seconds and Nanoseconds part of a time value
      needs to be converted. For anything where the Seconds argument is 0, this
      is pointless and can be replaced with a simple assignment.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  5. 25 12月, 2016 4 次提交
  6. 23 12月, 2016 1 次提交
  7. 21 12月, 2016 2 次提交
  8. 15 12月, 2016 15 次提交
  9. 14 12月, 2016 1 次提交
  10. 10 12月, 2016 2 次提交
  11. 09 12月, 2016 6 次提交