Message ID | 20200430131904.5847-1-hare@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | scsi: enable reserved commands for LLDDs | expand |
On 30/04/2020 14:18, Hannes Reinecke wrote: Thanks for this. > Conversion of the SAS drivers hisi_sas, pm8001, and mv_sas are > compile tested only; I'd be grateful if someone could give > these patches a spin on that hardware, too. So after some build fixups, I get this a NULL pointer deref: [ 5.565899] sas_find_dev_by_rphy+0x3c/0x104 [ 5.570182] sas_target_alloc+0x18/0x84 [ 5.574029] scsi_alloc_target+0x20c/0x304 [ 5.578136] scsi_get_virtual_dev+0x44/0xec [ 5.582331] sas_register_ha+0xd0/0x258 [ 5.586178] hisi_sas_probe+0x2ec/0x36c [ 5.590024] hisi_sas_v2_probe+0x34/0x64 [ 5.593958] platform_drv_probe+0x4c/0xa0 [ 5.597978] really_probe+0xd8/0x334 [ 5.601561] driver_probe_device+0x58/0xe8 [ 5.605669] device_driver_attach+0x68/0x70 [ 5.609864] __driver_attach+0x9c/0xf8 [ 5.613622] bus_for_each_dev+0x50/0xa0 [ 5.617468] driver_attach+0x20/0x28 [ 5.621051] bus_add_driver+0x148/0x1fc [ 5.624897] driver_register+0x6c/0x124 [ 5.628742] __platform_driver_register+0x48/0x50 [ 5.633463] hisi_sas_v2_driver_init+0x18/0x20 [ 5.637921] do_one_initcall+0x50/0x194 [ 5.641767] kernel_init_freeable+0x1e4/0x24c And so we need this change: commit 51f607bf91853026af102367d9e6666605cdec61 (HEAD) Author: John Garry <john.garry@huawei.com> Date: Fri May 1 12:30:32 2020 +0100 scsi: libsas: Don't attempt to find scsi host rphy in target alloc It doesn't have one. Signed-off-by: John Garry <john.garry@huawei.com> diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c index 585e0df5fce2..f1a823d51044 100644 --- a/drivers/scsi/libsas/sas_scsi_host.c +++ b/drivers/scsi/libsas/sas_scsi_host.c @@ -822,8 +825,15 @@ struct domain_device *sas_find_dev_by_rphy(struct sas_rphy *rphy) int sas_target_alloc(struct scsi_target *starget) { - struct sas_rphy *rphy = dev_to_rphy(starget->dev.parent); - struct domain_device *found_dev = sas_find_dev_by_rphy(rphy); + struct device *parent = starget->dev.parent; + struct sas_rphy *rphy; + struct domain_device *found_dev; + + if (scsi_is_host_device(parent)) + return 0; + + rphy = dev_to_rphy(parent); + found_dev = sas_find_dev_by_rphy(rphy); Cheers,
Can we get the basic infrastructure sorted out with just say csiostor and virtio-scsi before we get into all the more complicated bits? A 40+ series gets close to impossible to review unless it is just all mechnical changes.
On 5/1/20 2:01 PM, John Garry wrote: > On 30/04/2020 14:18, Hannes Reinecke wrote: > > Thanks for this. > >> Conversion of the SAS drivers hisi_sas, pm8001, and mv_sas are >> compile tested only; I'd be grateful if someone could give >> these patches a spin on that hardware, too. > > So after some build fixups, I get this a NULL pointer deref: > > [ 5.565899] sas_find_dev_by_rphy+0x3c/0x104 > [ 5.570182] sas_target_alloc+0x18/0x84 > [ 5.574029] scsi_alloc_target+0x20c/0x304 > [ 5.578136] scsi_get_virtual_dev+0x44/0xec > [ 5.582331] sas_register_ha+0xd0/0x258 > [ 5.586178] hisi_sas_probe+0x2ec/0x36c > [ 5.590024] hisi_sas_v2_probe+0x34/0x64 > [ 5.593958] platform_drv_probe+0x4c/0xa0 > [ 5.597978] really_probe+0xd8/0x334 > [ 5.601561] driver_probe_device+0x58/0xe8 > [ 5.605669] device_driver_attach+0x68/0x70 > [ 5.609864] __driver_attach+0x9c/0xf8 > [ 5.613622] bus_for_each_dev+0x50/0xa0 > [ 5.617468] driver_attach+0x20/0x28 > [ 5.621051] bus_add_driver+0x148/0x1fc > [ 5.624897] driver_register+0x6c/0x124 > [ 5.628742] __platform_driver_register+0x48/0x50 > [ 5.633463] hisi_sas_v2_driver_init+0x18/0x20 > [ 5.637921] do_one_initcall+0x50/0x194 > [ 5.641767] kernel_init_freeable+0x1e4/0x24c > > And so we need this change: > > commit 51f607bf91853026af102367d9e6666605cdec61 (HEAD) > Author: John Garry <john.garry@huawei.com> > Date: Fri May 1 12:30:32 2020 +0100 > > scsi: libsas: Don't attempt to find scsi host rphy in target alloc > > It doesn't have one. > > Signed-off-by: John Garry <john.garry@huawei.com> > > diff --git a/drivers/scsi/libsas/sas_scsi_host.c > b/drivers/scsi/libsas/sas_scsi_host.c > index 585e0df5fce2..f1a823d51044 100644 > --- a/drivers/scsi/libsas/sas_scsi_host.c > +++ b/drivers/scsi/libsas/sas_scsi_host.c > @@ -822,8 +825,15 @@ struct domain_device *sas_find_dev_by_rphy(struct > sas_rphy *rphy) > > int sas_target_alloc(struct scsi_target *starget) > { > - struct sas_rphy *rphy = dev_to_rphy(starget->dev.parent); > - struct domain_device *found_dev = sas_find_dev_by_rphy(rphy); > + struct device *parent = starget->dev.parent; > + struct sas_rphy *rphy; > + struct domain_device *found_dev; > + > + if (scsi_is_host_device(parent)) > + return 0; > + > + rphy = dev_to_rphy(parent); > + found_dev = sas_find_dev_by_rphy(rphy); > > Thank you, will be including it in the next round. Cheers, Hannes
On 5/1/20 7:46 PM, Christoph Hellwig wrote: > Can we get the basic infrastructure sorted out with just say csiostor > and virtio-scsi before we get into all the more complicated bits? > A 40+ series gets close to impossible to review unless it is just > all mechnical changes. > Sure. This patchset was just an RFC to show where I would want to go. I'll be restricting it to the virtio and csiostor for the next round. Cheers, Hannes
git://git.kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel.git reserved-tags.v3 As usual, comments and reviews are welcome. I cloned your tree and ran some tests using hpsa. I used 3 SATA HBA disks, 3 SAS HBA disks, 2 LOGICAL VOLUMES using HDDs, and 2 LOGICAL VOLUMES using SDDs for ioaccel path. I have an IO stress test that does mkfs, mount/umount, fio, and fsck to the above volumes while doing sg_reset opeations in parallel. The stress test has survived 2 full days of testing. However, my insmod/rmmod test causes a kernel panic. Not sure why yet. I had re-cloned yesterday an d the panic is still there. Earlier kernel versions do not panic on rmmod. -- 2.16.4
On 6/5/20 5:32 PM, Don.Brace@microchip.com wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel.git reserved-tags.v3 > > As usual, comments and reviews are welcome. > > I cloned your tree and ran some tests using hpsa. > > I used 3 SATA HBA disks, 3 SAS HBA disks, 2 LOGICAL VOLUMES using HDDs, and 2 LOGICAL VOLUMES using SDDs for ioaccel path. > > I have an IO stress test that does mkfs, mount/umount, fio, and fsck to the above volumes while doing sg_reset opeations in parallel. > > The stress test has survived 2 full days of testing. > > However, my insmod/rmmod test causes a kernel panic. > > Not sure why yet. I had re-cloned yesterday an d the panic is still there. > > Earlier kernel versions do not panic on rmmod. > > -- > 2.16.4 > Ah, right. Of course. Should be fixed with this patch:\ diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index fdc291c47b9b..87469908524c 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -1885,9 +1885,9 @@ void scsi_forget_host(struct Scsi_Host *shost) goto restart; } /* Remove virtual device last, might be needed to send commands */ + spin_unlock_irqrestore(shost->host_lock, flags); if (virtual_sdev) __scsi_remove_device(virtual_sdev); - spin_unlock_irqrestore(shost->host_lock, flags); } /** Can you test with that? Cheers, Hannes
Subject: Re: [PATCH RFC v3 00/41] scsi: enable reserved commands for LLDDs EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > However, my insmod/rmmod test causes a kernel panic. > > Ah, right. Of course. Should be fixed with this patch:\ Can you test with that? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer Yes, I'll start today.
Subject: Re: [PATCH RFC v3 00/41] scsi: enable reserved commands for LLDDs On 6/5/20 5:32 PM, Don.Brace@microchip.com wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel.git > reserved-tags.v3 > > As usual, comments and reviews are welcome. > > I cloned your tree and ran some tests using hpsa. > > I used 3 SATA HBA disks, 3 SAS HBA disks, 2 LOGICAL VOLUMES using HDDs, and 2 LOGICAL VOLUMES using SDDs for ioaccel path. > > I have an IO stress test that does mkfs, mount/umount, fio, and fsck to the above volumes while doing sg_reset opeations in parallel. > > The stress test has survived 2 full days of testing. > > However, my insmod/rmmod test causes a kernel panic. > > Not sure why yet. I had re-cloned yesterday an d the panic is still there. > > Earlier kernel versions do not panic on rmmod. > > -- > 2.16.4 > >>Ah, right. Of course. >>Should be fixed with this patch:\ >>Can you test with that? --- Applied patch... Ran 8000 iterations of my io stress script with 10K reset operations in parallel over 3 days. insmod/rmmod hpsa_ioctl testing controller FW flashing kdump/kexec testing reboot Tested-by: Don Brace <don.brace@microsemi.com> Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer