All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Ming Lei <tom.leiming@gmail.com>, Bart van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	Max Gurtovoy <maxg@mellanox.com>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	Linux SCSI List <linux-scsi@vger.kernel.org>,
	"megaraidlinux.pdl@broadcom.com" <megaraidlinux.pdl@broadcom.com>,
	"MPT-FusionLinux.pdl@broadcom.com"
	<MPT-FusionLinux.pdl@broadcom.com>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/8] scsi: take the DMA max mapping size into account
Date: Mon, 22 Jul 2019 07:40:20 +0000	[thread overview]
Message-ID: <BYAPR04MB58168CBFF8B691DF33C73DDBE7C40@BYAPR04MB5816.namprd04.prod.outlook.com> (raw)
In-Reply-To: CACVXFVMWM3xg6EEyoyNjkLPv=8+wQKiHj6erMS_gGX25f-Ot4g@mail.gmail.com

On 2019/07/22 15:01, Ming Lei wrote:
> On Tue, Jun 18, 2019 at 4:57 AM Bart Van Assche <bvanassche@acm.org> wrote:
>>
>> On 6/17/19 5:19 AM, Christoph Hellwig wrote:
>>> We need to limit the devices max_sectors to what the DMA mapping
>>> implementation can support.  If not we risk running out of swiotlb
>>> buffers easily.
>>>
>>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>> ---
>>>   drivers/scsi/scsi_lib.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index d333bb6b1c59..f233bfd84cd7 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1768,6 +1768,8 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct request_queue *q)
>>>               blk_queue_max_integrity_segments(q, shost->sg_prot_tablesize);
>>>       }
>>>
>>> +     shost->max_sectors = min_t(unsigned int, shost->max_sectors,
>>> +                     dma_max_mapping_size(dev) << SECTOR_SHIFT);
>>>       blk_queue_max_hw_sectors(q, shost->max_sectors);
>>>       if (shost->unchecked_isa_dma)
>>>               blk_queue_bounce_limit(q, BLK_BOUNCE_ISA);
>>
>> Does dma_max_mapping_size() return a value in bytes? Is
>> shost->max_sectors a number of sectors? If so, are you sure that "<<
>> SECTOR_SHIFT" is the proper conversion? Shouldn't that be ">>
>> SECTOR_SHIFT" instead?
> 
> Now the patch has been committed, '<< SECTOR_SHIFT' needs to be fixed.
> 
> Also the following kernel oops is triggered on qemu, and looks
> device->dma_mask is NULL.

Just hit the exact same problem using tcmu-runner (ZBC file handler) on bare
metal (no QEMU). dev->dma_mask is NULL. No problem with real disks though.

> 
> [    5.826483] scsi host0: Virtio SCSI HBA
> [    5.829302] st: Version 20160209, fixed bufsize 32768, s/g segs 256
> [    5.831042] SCSI Media Changer driver v0.25
> [    5.832491] ==================================================================
> [    5.833332] BUG: KASAN: null-ptr-deref in
> dma_direct_max_mapping_size+0x30/0x94
> [    5.833332] Read of size 8 at addr 0000000000000000 by task kworker/u17:0/7
> [    5.835506] nvme nvme0: pci function 0000:00:07.0
> [    5.833332]
> [    5.833332] CPU: 2 PID: 7 Comm: kworker/u17:0 Not tainted 5.3.0-rc1 #1328
> [    5.836999] ahci 0000:00:1f.2: version 3.0
> [    5.833332] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> BIOS ?-20180724_192412-buildhw-07.phx4
> [    5.833332] Workqueue: events_unbound async_run_entry_fn
> [    5.833332] Call Trace:
> [    5.833332]  dump_stack+0x6f/0x9d
> [    5.833332]  ? dma_direct_max_mapping_size+0x30/0x94
> [    5.833332]  __kasan_report+0x161/0x189
> [    5.833332]  ? dma_direct_max_mapping_size+0x30/0x94
> [    5.833332]  kasan_report+0xe/0x12
> [    5.833332]  dma_direct_max_mapping_size+0x30/0x94
> [    5.833332]  __scsi_init_queue+0xd8/0x1f3
> [    5.833332]  scsi_mq_alloc_queue+0x62/0x89
> [    5.833332]  scsi_alloc_sdev+0x38c/0x479
> [    5.833332]  scsi_probe_and_add_lun+0x22d/0x1093
> [    5.833332]  ? kobject_set_name_vargs+0xa4/0xb2
> [    5.833332]  ? mutex_lock+0x88/0xc4
> [    5.833332]  ? scsi_free_host_dev+0x4a/0x4a
> [    5.833332]  ? _raw_spin_lock_irqsave+0x8c/0xde
> [    5.833332]  ? _raw_write_unlock_irqrestore+0x23/0x23
> [    5.833332]  ? ata_tdev_match+0x22/0x45
> [    5.833332]  ? attribute_container_add_device+0x160/0x17e
> [    5.833332]  ? rpm_resume+0x26a/0x7c0
> [    5.833332]  ? kobject_get+0x12/0x43
> [    5.833332]  ? rpm_put_suppliers+0x7e/0x7e
> [    5.833332]  ? _raw_spin_lock_irqsave+0x8c/0xde
> [    5.833332]  ? _raw_write_unlock_irqrestore+0x23/0x23
> [    5.833332]  ? scsi_target_destroy+0x135/0x135
> [    5.833332]  __scsi_scan_target+0x14b/0x6aa
> [    5.833332]  ? pvclock_clocksource_read+0xc0/0x14e
> [    5.833332]  ? scsi_add_device+0x20/0x20
> [    5.833332]  ? rpm_resume+0x1ae/0x7c0
> [    5.833332]  ? rpm_put_suppliers+0x7e/0x7e
> [    5.833332]  ? _raw_spin_lock_irqsave+0x8c/0xde
> [    5.833332]  ? _raw_write_unlock_irqrestore+0x23/0x23
> [    5.833332]  ? pick_next_task_fair+0x976/0xa3d
> [    5.833332]  ? mutex_lock+0x88/0xc4
> [    5.833332]  scsi_scan_channel+0x76/0x9e
> [    5.833332]  scsi_scan_host_selected+0x131/0x176
> [    5.833332]  ? scsi_scan_host+0x241/0x241
> [    5.833332]  do_scan_async+0x27/0x219
> [    5.833332]  ? scsi_scan_host+0x241/0x241
> [    5.833332]  async_run_entry_fn+0xdc/0x23d
> [    5.833332]  process_one_work+0x327/0x539
> [    5.833332]  worker_thread+0x330/0x492
> [    5.833332]  ? rescuer_thread+0x41f/0x41f
> [    5.833332]  kthread+0x1c6/0x1d5
> [    5.833332]  ? kthread_park+0xd3/0xd3
> [    5.833332]  ret_from_fork+0x1f/0x30
> [    5.833332] ==================================================================
> 
> 
> 
> Thanks,
> Ming Lei
> 


-- 
Damien Le Moal
Western Digital Research

  parent reply	other threads:[~2019-07-22  7:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 12:19 properly communicate queue limits to the DMA layer v2 Christoph Hellwig
2019-06-17 12:19 ` [PATCH 1/8] scsi: add a host / host template field for the virt boundary Christoph Hellwig
2019-06-17 20:51   ` Bart Van Assche
2019-06-18  0:35   ` Ming Lei
2019-06-20  6:17     ` Kashyap Desai
2019-06-17 12:19 ` [PATCH 2/8] scsi: take the DMA max mapping size into account Christoph Hellwig
2019-06-17 20:56   ` Bart Van Assche
2019-07-22  6:00     ` Ming Lei
2019-07-22  6:18       ` Dexuan-Linux Cui
2019-07-22  7:40       ` Damien Le Moal [this message]
2019-06-17 12:19 ` [PATCH 3/8] ufshcd: set max_segment_size in the scsi host template Christoph Hellwig
2019-06-17 20:58   ` Bart Van Assche
2019-06-17 12:19 ` [PATCH 4/8] storvsc: set virt_boundary_mask " Christoph Hellwig
2019-06-17 20:59   ` Bart Van Assche
2019-06-17 12:19 ` [PATCH 5/8] IB/iser: set virt_boundary_mask in the scsi host Christoph Hellwig
2019-06-17 17:34   ` Sagi Grimberg
2019-06-24 22:32   ` Max Gurtovoy
2019-06-24 22:32     ` Max Gurtovoy
2019-06-17 12:19 ` [PATCH 6/8] IB/srp: " Christoph Hellwig
2019-06-17 17:35   ` Sagi Grimberg
2019-06-17 21:01   ` Bart Van Assche
2019-06-24 22:33   ` Max Gurtovoy
2019-06-24 22:33     ` Max Gurtovoy
2019-06-17 12:19 ` [PATCH 7/8] mpt3sas: set an unlimited max_segment_size for SAS 3.0 HBAs Christoph Hellwig
2019-06-18  0:46   ` Ming Lei
2019-06-20  7:04     ` Suganath Prabu Subramani
2019-06-20  7:08       ` Suganath Prabu Subramani
2019-06-17 12:20 ` [PATCH 8/8] megaraid_sas: set an unlimited max_segment_size Christoph Hellwig
2019-07-15 16:58 ` properly communicate queue limits to the DMA layer v2 Christoph Hellwig
2019-07-15 17:33   ` Martin K. Petersen
2019-07-15 17:46     ` Christoph Hellwig
2019-07-17  3:07       ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR04MB58168CBFF8B691DF33C73DDBE7C40@BYAPR04MB5816.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=MPT-FusionLinux.pdl@broadcom.com \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=maxg@mellanox.com \
    --cc=megaraidlinux.pdl@broadcom.com \
    --cc=sagi@grimberg.me \
    --cc=tom.leiming@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.