Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 7月, 2018 5 次提交
    • M
      scsi: core: fix scsi_host_queue_ready · 265d59aa
      由 Ming Lei 提交于 
      32872863 ("scsi: avoid to hold host-wide counter of host_busy for
scsi_mq") adds one extra check on scsi_host_busy(shost) in
scsi_host_queue_ready(), which is wrong and not necessary, can causes
booting stall on LSI53c895A.

So remove the check.

Cc: Omar Sandoval <osandov@fb.com>,
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Cc: James Bottomley <james.bottomley@hansenpartnership.com>,
Cc: Christoph Hellwig <hch@lst.de>,
Cc: Don Brace <don.brace@microsemi.com>
Cc: Kashyap Desai <kashyap.desai@broadcom.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Laurence Oberman <loberman@redhat.com>
Cc: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Fixes: 32872863 ("scsi: avoid to hold host-wide counter of host_busy for scsi_mq")
Signed-off-by: NMing Lei <ming.lei@redhat.com>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      265d59aa
    • B
      scsi: klist: Make it safe to use klists in atomic context · 624fa779
      由 Bart Van Assche 提交于 
      In the scsi_transport_srp implementation it cannot be avoided to
iterate over a klist from atomic context when using the legacy block
layer instead of blk-mq. Hence this patch that makes it safe to use
klists in atomic context. This patch avoids that lockdep reports the
following:

WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&k->k_lock)->rlock);
                               local_irq_disable();
                               lock(&(&q->__queue_lock)->rlock);
                               lock(&(&k->k_lock)->rlock);
  <Interrupt>
    lock(&(&q->__queue_lock)->rlock);

stack backtrace:
Workqueue: kblockd blk_timeout_work
Call Trace:
 dump_stack+0xa4/0xf5
 check_usage+0x6e6/0x700
 __lock_acquire+0x185d/0x1b50
 lock_acquire+0xd2/0x260
 _raw_spin_lock+0x32/0x50
 klist_next+0x47/0x190
 device_for_each_child+0x8e/0x100
 srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
 scsi_times_out+0xd4/0x410 [scsi_mod]
 blk_rq_timed_out+0x36/0x70
 blk_timeout_work+0x1b5/0x220
 process_one_work+0x4fe/0xad0
 worker_thread+0x63/0x5a0
 kthread+0x1c1/0x1e0
 ret_from_fork+0x24/0x30

See also commit c9ddf734 ("scsi: scsi_transport_srp: Fix shost to
rport translation").
Signed-off-by: NBart Van Assche <bart.vanassche@wdc.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      624fa779
    • B
      scsi: sd_zbc: Remove an assignment from sd_zbc_setup_report_cmnd() · 68c3f904
      由 Bart Van Assche 提交于 
      Since nr_bytes == blk_rq_bytes(rq) == rq->__data_len, the
rq->__data_len = nr_bytes assignment does not modify the value of
rq->__data_len. Hence remove that assignment. Note: the code in
sd_done() that sets the residual to zero for zone report requests
is not affected by this patch.
Signed-off-by: NBart Van Assche <bart.vanassche@wdc.com>
Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      68c3f904
    • D
      scsi: qedi: tidy up a size calculation · 915d9b71
      由 Dan Carpenter 提交于 
      The id_tbl->table pointer points to unsigned long so static checkers
complain that instead of 4 we should be allocating sizeof(long) bytes.

We're trying to allocate enough bits for the bitmap.  The size variable is
always 1024.  (1024 / 32 * 4) is the same as (1024 / 64 * 8) so this
doesn't change runtime, but this is the more idiomatic way to do it and
makes the static checker happy.

[mkp: typo]
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NManish Rangankar <Manish.Rangankar@cavium.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      915d9b71
    • B
      scsi: ibmvscsi: Improve strings handling · 1262dc09
      由 Breno Leitao 提交于 
      Currently an open firmware property is copied into partition_name variable
without keeping a room for \0.

Later one, this variable (partition_name), which is 97 bytes long, is
strncpyed into ibmvcsci_host_data->madapter_info->partition_name, which is
96 bytes long, possibly truncating it 'again' and removing the \0.

This patch simply decreases the partition name to 96 and just copy using
strlcpy() which guarantees that the string is \0 terminated. I think there
is no issue if this there is a truncation in this very first copy, i.e,
when the open firmware property is read and copied into the driver for the
very first time;

This issue also causes the following warning on GCC 8:

	drivers/scsi/ibmvscsi/ibmvscsi.c:281:2: warning:  strncpy  output may be truncated copying 96 bytes from a string of length 96 [-Wstringop-truncation]
	...
	inlined from  ibmvscsi_probe  at drivers/scsi/ibmvscsi/ibmvscsi.c:2221:7:
	drivers/scsi/ibmvscsi/ibmvscsi.c:265:3: warning:  strncpy  specified bound 97 equals destination size [-Wstringop-truncation]

CC: Bart Van Assche <bart.vanassche@wdc.com>
CC: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: NBreno Leitao <leitao@debian.org>
Acked-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      1262dc09
  3. 27 6月, 2018 21 次提交
  5. 26 6月, 2018 2 次提交
  7. 22 6月, 2018 1 次提交
  9. 20 6月, 2018 11 次提交