[PATCH V3 00/24] aacraid: Patchset for Smart Family Support

[Raghava Aditya Renukunta]

This patchset adds support to the HBA1000 and SMARTIOC2000
family of cards. The driver version is now updated to 50740

Changes in V2:
Fixed kbuild test robot warnings

Changes in V3:
Removed Camel case definitions
Misc fixes

Raghava Aditya Renukunta (24):
 [SCSI] aacraid: Remove duplicate irq management code
 [SCSI] aacraid: Added aacraid.h include guard
 [SCSI] aacraid: added support for init_struct_8
 [SCSI] aacraid: Added sa firmware support
 [SCSI] aacraid: Retrieve and update the device types
 [SCSI] aacraid: Reworked scsi command submission path
 [SCSI] aacraid: Process Error for response I/O
 [SCSI] aacraid: Added support for response path
 [SCSI] aacraid: Added support for read medium error
 [SCSI] aacraid: Reworked aac_command_thread
 [SCSI] aacraid: Added support for periodic wellness sync
 [SCSI] aacraid: Retrieve Queue Depth from Adapter FW
 [SCSI] aacraid: Added support to set QD of attached drives
 [SCSI] aacraid: Added support for hotplug
 [SCSI] aacraid: Include HBA direct interface
 [SCSI] aacraid: Add task management functionality
 [SCSI] aacraid: Added support to abort cmd and reset lun
 [SCSI] aacraid: VPD 83 type3 support
 [SCSI] aacraid: Added new IWBR reset
 [SCSI] aacraid: Added ioctl to trigger IOP/IWBR reset
 [SCSI] aacraid: Retrieve HBA host information ioctl
 [SCSI] aacraid: Update copyrights
 [SCSI] aacraid: Change Driver Version Prefix
 [SCSI] aacraid: update version

 drivers/scsi/aacraid/aachba.c   | 1294 +--
 drivers/scsi/aacraid/aacraid.h  |  648 +---
 drivers/scsi/aacraid/commctrl.c |  342 ---
 drivers/scsi/aacraid/comminit.c |  330 +-
 drivers/scsi/aacraid/commsup.c  |  901 +++
 drivers/scsi/aacraid/dpcsup.c   |  159 +++--
 drivers/scsi/aacraid/linit.c|  556 +++--
 drivers/scsi/aacraid/nark.c |3 +-
 drivers/scsi/aacraid/rkt.c  |5 +-
 drivers/scsi/aacraid/rx.c   |   17 +-
 drivers/scsi/aacraid/sa.c   |9 +-
 drivers/scsi/aacraid/src.c  |  336 +++---
 12 files changed, 3390 insertions(+), 1210 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 21/24] aacraid: Retrieve HBA host information ioctl

[Raghava Aditya Renukunta]

Added a new ioctl interface to retrieve the host device information.

Signed-off-by: Raghava Aditya Renukunta 
Signed-off-by: Dave Carroll 

---
Changes in  V2:
None

Changes in  V3:
None

 drivers/scsi/aacraid/aacraid.h  | 52 +
 drivers/scsi/aacraid/commctrl.c | 26 +
 2 files changed, 78 insertions(+)

diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h
index 6b80a63..e14916e 100644
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -2338,6 +2338,7 @@ struct revision
 #define FSACTL_GET_CONTAINERS  2131
 #define FSACTL_SEND_LARGE_FIB  CTL_CODE(2138, METHOD_BUFFERED)
 #define FSACTL_RESET_IOP   CTL_CODE(2140, METHOD_BUFFERED)
+#define FSACTL_GET_HBA_INFOCTL_CODE(2150, METHOD_BUFFERED)
 /* flags defined for IOP & HW SOFT RESET */
 #define HW_IOP_RESET   0x01
 #define HW_SOFT_RESET  0x02
@@ -2377,6 +2378,57 @@ struct aac_common
 extern struct aac_common aac_config;
 
 /*
+ * This is for management ioctl purpose only.
+ */
+struct aac_hba_info {
+
+   u8  DriverName[50];
+   u8  AdapterNumber;
+   u8  SystemIoBusNumber;
+   u8  DeviceNumber;
+   u32 FunctionNumber;
+   u32 VendorID;
+   u32 DeviceID;
+   u32 SubVendorID;
+   u32 SubSystemID;
+   u32 MappedBaseAddressSize;
+   u32 BasePhysicalAddress_HighPart;
+   u32 BasePhysicalAddress_LowPart;
+
+   u32 MaxCommandSize;
+   u32 MaxFibSize;
+   u32 MaxScatterGatherFromOs;
+   u32 MaxScatterGatherToFw;
+   u32 MaxOutstandingFibs;
+
+   u32 QueueStartThreshold;
+   u32 QueueDumpThreshold;
+   u32 MaxIoSizeQueued;
+   u32 OutstandingIO;
+
+   u32 FirmwareBuildNumber;
+   u32 BIOSBuildNumber;
+   u32 DriverBuildNumber;
+   u32 SerialNumber_HighPart;
+   u32 SerialNumber_LowPart;
+   u32 SupportedOptions;
+   u32 FeatureBits;
+   u32 currentnumberPorts;
+
+   u8  NewCommInterface:1;
+   u8  NewCommandsSupported:1;
+   u8  DisablePassthrough:1;
+   u8  ExposeNonDasd:1;
+   u8  QueueAllowed:1;
+   u8  BLEDCheckEnabled:1;
+   u8  reserved1:1;
+   u8  reserted2:1;
+
+   u32 reserved3[10];
+
+};
+
+/*
  * The following macro is used when sending and receiving FIBs. It is
  * only used for debugging.
  */
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 4b65b91..9ade2b4 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -1011,6 +1011,29 @@ static int aac_get_pci_info(struct aac_dev* dev, void 
__user *arg)
}
return 0;
 }
+
+static int aac_get_hba_info(struct aac_dev *dev, void __user *arg)
+{
+   struct aac_hba_info hbainfo;
+
+   hbainfo.AdapterNumber   = (u8) dev->id;
+   hbainfo.SystemIoBusNumber   = dev->pdev->bus->number;
+   hbainfo.DeviceNumber= (dev->pdev->devfn >> 3);
+   hbainfo.FunctionNumber  = (dev->pdev->devfn & 0x0007);
+
+   hbainfo.VendorID= dev->pdev->vendor;
+   hbainfo.DeviceID= dev->pdev->device;
+   hbainfo.SubVendorID = dev->pdev->subsystem_vendor;
+   hbainfo.SubSystemID = dev->pdev->subsystem_device;
+
+   if (copy_to_user(arg, , sizeof(struct aac_hba_info))) {
+   dprintk((KERN_DEBUG "aacraid: Could not copy hba info\n"));
+   return -EFAULT;
+   }
+
+   return 0;
+}
+
 struct aac_reset_iop {
u8  reset_type;
 };
@@ -1070,6 +1093,9 @@ int aac_do_ioctl(struct aac_dev * dev, int cmd, void 
__user *arg)
case FSACTL_GET_PCI_INFO:
status = aac_get_pci_info(dev,arg);
break;
+   case FSACTL_GET_HBA_INFO:
+   status = aac_get_hba_info(dev, arg);
+   break;
case FSACTL_RESET_IOP:
status = aac_send_reset_adapter(dev, arg);
break;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/18] block: allow specifying size for extra command data

[Jens Axboe]

On 01/27/2017 10:30 AM, Bart Van Assche wrote:
> On Fri, 2017-01-27 at 10:26 -0700, Jens Axboe wrote:
>> On 01/27/2017 10:21 AM, Bart Van Assche wrote:
>>> On Fri, 2017-01-27 at 17:12 +0100, Christoph Hellwig wrote:
 On Wed, Jan 25, 2017 at 10:15:55PM -0500, Martin K. Petersen wrote:
> +static void *alloc_request_size(gfp_t gfp_mask, void *data)
>
> I like alloc_request_simple() but alloc_request_size() seems a bit
> contrived. _reserve? _extra? _special? Don't have any good suggestions,
> I'm afraid.

 Not that I'm a fan of _size, but I like the other suggestions even less.
>>>
>>> Hello Christoph and Martin,
>>>
>>> How about using the function names alloc_full_request() / 
>>> free_full_request()
>>> together with a comment that mentions that cmd_size is set by the LLD?
>>
>> Since we use pdu in other places, how about alloc_request_pdu() or
>> alloc_request_with_pdu()?
>>
>> And since it's all queued up, any bike shedding changes will have to be
>> incremental.
> 
> Hello Jens,
> 
> Other Linux subsystems use the term "private data" instead of PDU. How about
> modifying the block layer such that it uses the same terminology? I'm
> referring to function names like blk_mq_rq_from_pdu() and blk_mq_rq_to_pdu()

It's been pdu since it was introduced in 3.13, I really don't see a good
reason to change it. At least pdu or payload means something, where as
private is just... Well, not a big fan.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Jens Axboe]

On 01/27/2017 09:34 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:27:02AM -0700, Jens Axboe wrote:
>> Feel free to repost it, I have no problem rebasing that branch as it's
>> standalone for now.
> 
> Ok, I'll repost what I have right now, which is on top of a merge
> of your block/for-4.11/next and your for-next from this morning
> my time.

Perfect.

> Btw, I disagred with your patch to use op_is_flush in
> generic_make_request_checks - given that we clear these flags just
> below I think using the helper obsfucates what's really going on.

Why? It's the exact same check. The ugly part is the fact that
we strip the flags later on, imho.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/18] block: allow specifying size for extra command data

[Jens Axboe]

On 01/27/2017 10:21 AM, Bart Van Assche wrote:
> On Fri, 2017-01-27 at 17:12 +0100, Christoph Hellwig wrote:
>> On Wed, Jan 25, 2017 at 10:15:55PM -0500, Martin K. Petersen wrote:
>>> +static void *alloc_request_size(gfp_t gfp_mask, void *data)
>>>
>>> I like alloc_request_simple() but alloc_request_size() seems a bit
>>> contrived. _reserve? _extra? _special? Don't have any good suggestions,
>>> I'm afraid.
>>
>> Not that I'm a fan of _size, but I like the other suggestions even less.
> 
> Hello Christoph and Martin,
> 
> How about using the function names alloc_full_request() / free_full_request()
> together with a comment that mentions that cmd_size is set by the LLD?

Since we use pdu in other places, how about alloc_request_pdu() or
alloc_request_with_pdu()?

And since it's all queued up, any bike shedding changes will have to be
incremental.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] split scsi passthrough fields out of struct request V2

[Bart Van Assche]

On Fri, 2017-01-27 at 01:04 -0700, Jens Axboe wrote:
> The previous patch had a bug if you didn't use a scheduler, here's a
> version that should work fine in both cases. I've also updated the
> above mentioned branch, so feel free to pull that as well and merge to
> master like before.

Booting time is back to normal with commit f3a8ab7d55bc merged with
v4.10-rc5. That's a great improvement. However, running the srp-test
software triggers now a new complaint:

[  215.600386] sd 11:0:0:0: [sdh] Attached SCSI disk
[  215.609485] sd 11:0:0:0: alua: port group 00 state A non-preferred supports 
TOlUSNA
[  215.722900] scsi 13:0:0:0: alua: Detached
[  215.724452] general protection fault:  [#1] SMP
[  215.724484] Modules linked in: dm_service_time ib_srp scsi_transport_srp 
target_core_user uio target_core_pscsi target_core_file ib_srpt 
target_core_iblock target_core_mod brd netconsole xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT 
nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter ebtables 
ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet ib_ipoib 
rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm msr configfs ib_cm iw_cm mlx4_ib 
ib_core sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp ipmi_ssif 
coretemp kvm_intel hid_generic kvm usbhid irqbypass crct10dif_pclmul 
crc32_pclmul crc32c_intel mlx4_core ghash_clmulni_intel iTCO_wdt dcdbas pcbc tg3
[  215.724629]  iTCO_vendor_support ptp aesni_intel pps_core aes_x86_64 pcspkr 
crypto_simd libphy ipmi_si glue_helper cryptd ipmi_devintf tpm_tis devlink fjes 
ipmi_msghandler tpm_tis_core tpm mei_me lpc_ich mei mfd_core button shpchp wmi 
mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops ttm drm sr_mod cdrom ehci_pci ehci_hcd usbcore usb_common sg 
dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua autofs4
[  215.724719] CPU: 9 PID: 8043 Comm: multipathd Not tainted 4.10.0-rc5-dbg+ #1
[  215.724748] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 
11/17/2014
[  215.724775] task: 8801717998c0 task.stack: c90002a9c000
[  215.724804] RIP: 0010:scsi_device_put+0xb/0x30
[  215.724829] RSP: 0018:c90002a9faa0 EFLAGS: 00010246
[  215.724855] RAX: 6b6b6b6b6b6b6b6b RBX: 88038bf85698 RCX: 0006
[  215.724880] RDX: 0006 RSI: 88017179a108 RDI: 88038bf85698
[  215.724906] RBP: c90002a9faa8 R08: 880384786008 R09: 000100170007
[  215.724932] R10:  R11:  R12: 88038bf85698
[  215.724958] R13: 88038919f090 R14: dead0100 R15: 88038a41dd28
[  215.724983] FS:  7fbf8c6cf700() GS:88046f44() 
knlGS:
[  215.725010] CS:  0010 DS:  ES:  CR0: 80050033
[  215.725035] CR2: 7f1262ef3ee0 CR3: 00044f6cc000 CR4: 001406e0
[  215.725060] Call Trace:
[  215.725086]  scsi_disk_put+0x2d/0x40
[  215.725110]  sd_release+0x3d/0xb0
[  215.725137]  __blkdev_put+0x29e/0x360
[  215.725163]  blkdev_put+0x49/0x170
[  215.725192]  dm_put_table_device+0x58/0xc0 [dm_mod]
[  215.725219]  dm_put_device+0x70/0xc0 [dm_mod]
[  215.725269]  free_priority_group+0x92/0xc0 [dm_multipath]
[  215.725295]  free_multipath+0x70/0xc0 [dm_multipath]
[  215.725320]  multipath_dtr+0x19/0x20 [dm_multipath]
[  215.725348]  dm_table_destroy+0x67/0x120 [dm_mod]
[  215.725379]  dev_suspend+0xde/0x240 [dm_mod]
[  215.725434]  ctl_ioctl+0x1f5/0x520 [dm_mod]
[  215.725489]  dm_ctl_ioctl+0xe/0x20 [dm_mod]
[  215.725515]  do_vfs_ioctl+0x8f/0x700
[  215.725589]  SyS_ioctl+0x3c/0x70
[  215.725614]  entry_SYSCALL_64_fastpath+0x18/0xad
[  215.725641] RIP: 0033:0x7fbf8aca0667
[  215.725665] RSP: 002b:7fbf8c6cd668 EFLAGS: 0246 ORIG_RAX: 
0010
[  215.725692] RAX: ffda RBX: 0046 RCX: 7fbf8aca0667
[  215.725716] RDX: 7fbf8006b940 RSI: c138fd06 RDI: 0007
[  215.725743] RBP: 0009 R08: 7fbf8c6cb3c0 R09: 7fbf8b68d8d8
[  215.725768] R10: 0075 R11: 0246 R12: 7fbf8c6cd770
[  215.725793] R13: 0013 R14: 006168f0 R15: 00f74780
[  215.725820] Code: bc 24 b8 00 00 00 e8 55 c8 1c 00 48 83 c4 08 48 89 d8 5b 
41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 00 55 48 89 e5 53 48 8b 07 48 89 fb <48> 8b 
80 a8 01 00 00 48 8b 38 e8 f6 68 c5 ff 48 8d bb 38 02 00 
[  215.725903] RIP: scsi_device_put+0xb/0x30 RSP: c90002a9faa0

(gdb) list *(scsi_device_put+0xb)
0x8149fc2b is in scsi_device_put (drivers/scsi/scsi.c:957).
952  * count of the underlying LLDD module.  The device is freed once the 
last
953  * user vanishes.
954  */
955 void scsi_device_put(struct scsi_device *sdev)
956 {
957 module_put(sdev->host->hostt->module);
958 put_device(>sdev_gendev);
959 }
960 

Re: [dm-devel] split scsi passthrough fields out of struct request V2

[Jens Axboe]

On 01/27/2017 09:52 AM, Bart Van Assche wrote:
> On Fri, 2017-01-27 at 01:04 -0700, Jens Axboe wrote:
>> The previous patch had a bug if you didn't use a scheduler, here's a
>> version that should work fine in both cases. I've also updated the
>> above mentioned branch, so feel free to pull that as well and merge to
>> master like before.
> 
> Booting time is back to normal with commit f3a8ab7d55bc merged with
> v4.10-rc5. That's a great improvement. However, running the srp-test
> software triggers now a new complaint:
> 
> [  215.600386] sd 11:0:0:0: [sdh] Attached SCSI disk
> [  215.609485] sd 11:0:0:0: alua: port group 00 state A non-preferred 
> supports TOlUSNA
> [  215.722900] scsi 13:0:0:0: alua: Detached
> [  215.724452] general protection fault:  [#1] SMP
> [  215.724484] Modules linked in: dm_service_time ib_srp scsi_transport_srp 
> target_core_user uio target_core_pscsi target_core_file ib_srpt 
> target_core_iblock target_core_mod brd netconsole xt_CHECKSUM iptable_mangle 
> ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
> libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack 
> ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter 
> ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables 
> af_packet ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm msr configfs 
> ib_cm iw_cm mlx4_ib ib_core sb_edac edac_core x86_pkg_temp_thermal 
> intel_powerclamp ipmi_ssif coretemp kvm_intel hid_generic kvm usbhid 
> irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel mlx4_core 
> ghash_clmulni_intel iTCO_wdt dcdbas pcbc tg3
> [  215.724629]  iTCO_vendor_support ptp aesni_intel pps_core aes_x86_64 
> pcspkr crypto_simd libphy ipmi_si glue_helper cryptd ipmi_devintf tpm_tis 
> devlink fjes ipmi_msghandler tpm_tis_core tpm mei_me lpc_ich mei mfd_core 
> button shpchp wmi mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect 
> sysimgblt fb_sys_fops ttm drm sr_mod cdrom ehci_pci ehci_hcd usbcore 
> usb_common sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua 
> autofs4
> [  215.724719] CPU: 9 PID: 8043 Comm: multipathd Not tainted 4.10.0-rc5-dbg+ 
> #1
> [  215.724748] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 
> 11/17/2014
> [  215.724775] task: 8801717998c0 task.stack: c90002a9c000
> [  215.724804] RIP: 0010:scsi_device_put+0xb/0x30
> [  215.724829] RSP: 0018:c90002a9faa0 EFLAGS: 00010246
> [  215.724855] RAX: 6b6b6b6b6b6b6b6b RBX: 88038bf85698 RCX: 
> 0006
> [  215.724880] RDX: 0006 RSI: 88017179a108 RDI: 
> 88038bf85698
> [  215.724906] RBP: c90002a9faa8 R08: 880384786008 R09: 
> 000100170007
> [  215.724932] R10:  R11:  R12: 
> 88038bf85698
> [  215.724958] R13: 88038919f090 R14: dead0100 R15: 
> 88038a41dd28
> [  215.724983] FS:  7fbf8c6cf700() GS:88046f44() 
> knlGS:
> [  215.725010] CS:  0010 DS:  ES:  CR0: 80050033
> [  215.725035] CR2: 7f1262ef3ee0 CR3: 00044f6cc000 CR4: 
> 001406e0
> [  215.725060] Call Trace:
> [  215.725086]  scsi_disk_put+0x2d/0x40
> [  215.725110]  sd_release+0x3d/0xb0
> [  215.725137]  __blkdev_put+0x29e/0x360
> [  215.725163]  blkdev_put+0x49/0x170
> [  215.725192]  dm_put_table_device+0x58/0xc0 [dm_mod]
> [  215.725219]  dm_put_device+0x70/0xc0 [dm_mod]
> [  215.725269]  free_priority_group+0x92/0xc0 [dm_multipath]
> [  215.725295]  free_multipath+0x70/0xc0 [dm_multipath]
> [  215.725320]  multipath_dtr+0x19/0x20 [dm_multipath]
> [  215.725348]  dm_table_destroy+0x67/0x120 [dm_mod]
> [  215.725379]  dev_suspend+0xde/0x240 [dm_mod]
> [  215.725434]  ctl_ioctl+0x1f5/0x520 [dm_mod]
> [  215.725489]  dm_ctl_ioctl+0xe/0x20 [dm_mod]
> [  215.725515]  do_vfs_ioctl+0x8f/0x700
> [  215.725589]  SyS_ioctl+0x3c/0x70
> [  215.725614]  entry_SYSCALL_64_fastpath+0x18/0xad
> [  215.725641] RIP: 0033:0x7fbf8aca0667
> [  215.725665] RSP: 002b:7fbf8c6cd668 EFLAGS: 0246 ORIG_RAX: 
> 0010
> [  215.725692] RAX: ffda RBX: 0046 RCX: 
> 7fbf8aca0667
> [  215.725716] RDX: 7fbf8006b940 RSI: c138fd06 RDI: 
> 0007
> [  215.725743] RBP: 0009 R08: 7fbf8c6cb3c0 R09: 
> 7fbf8b68d8d8
> [  215.725768] R10: 0075 R11: 0246 R12: 
> 7fbf8c6cd770
> [  215.725793] R13: 0013 R14: 006168f0 R15: 
> 00f74780
> [  215.725820] Code: bc 24 b8 00 00 00 e8 55 c8 1c 00 48 83 c4 08 48 89 d8 5b 
> 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 00 55 48 89 e5 53 48 8b 07 48 89 fb <48> 
> 8b 80 a8 01 00 00 48 8b 38 e8 f6 68 c5 ff 48 8d bb 38 02 00 
> [  215.725903] RIP: scsi_device_put+0xb/0x30 RSP: c90002a9faa0
> 
> (gdb) list *(scsi_device_put+0xb)
> 0x8149fc2b is in scsi_device_put (drivers/scsi/scsi.c:957).
> 952  * count of the underlying LLDD module.  The device is freed once the 
> 

Re: [dm-devel] split scsi passthrough fields out of struct request V2

[Bart Van Assche]

On Thu, 2017-01-26 at 18:22 -0700, Jens Axboe wrote:
> What's your boot device? I've been booting this on a variety of setups,
> no problems observed. It's booting my laptop, and on SCSI and SATA as
> well. What is your root drive? What is the queue depth of it?
> Controller?

The boot device in my test setup is a SATA hard disk:

# cat /proc/cmdline  
BOOT_IMAGE=/boot/vmlinuz-4.10.0-rc5-dbg+ 
root=UUID=60a4b064-b3ef-4d28-96d3-3c13ecbec43e resume=/dev/sda2 showopts
# ls -l /dev/disk/by-uuid/60a4b064-b3ef-4d28-96d3-3c13ecbec43e
lrwxrwxrwx 1 root root 10 Jan 27 08:43 
/dev/disk/by-uuid/60a4b064-b3ef-4d28-96d3-3c13ecbec43e -> ../../sda1
# cat /sys/block/sda/queue/nr_requests  
31
# lsscsi | grep sda
[0:0:0:0]    disk    ATA  ST1000NM0033-9ZM GA67  /dev/sda
# hdparm -i /dev/sda

/dev/sda:
 Model=ST1000NM0033-9ZM173, FwRev=GA67, SerialNo=Z1W2HM75
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4  
 DMA modes:  mdma0 mdma1 mdma2  
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6  
 AdvancedPM=no WriteCache=disabled
 Drive conforms to: Unspecified:  ATA/ATAPI-4,5,6,7

 * signifies the current active mode

Bart.--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Christoph Hellwig]

On Fri, Jan 27, 2017 at 09:38:40AM -0700, Jens Axboe wrote:
> > Ok, I'll repost what I have right now, which is on top of a merge
> > of your block/for-4.11/next and your for-next from this morning
> > my time.
> 
> Perfect.

At least I tried, looks like the mail server is overloaded and crapped
out three mails into it.  For now there is a git tree here:

http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/block-pc-refactor

> 
> > Btw, I disagred with your patch to use op_is_flush in
> > generic_make_request_checks - given that we clear these flags just
> > below I think using the helper obsfucates what's really going on.
> 
> Why? It's the exact same check. The ugly part is the fact that
> we strip the flags later on, imho.

But before it was pretty obvious that it clears exactly the flags checked
two lines earlier.  Now it's not as obvious.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

[Mike Snitzer]

On Fri, Jan 27 2017 at 11:36am -0500,
Christoph Hellwig  wrote:

> On Fri, Jan 27, 2017 at 11:34:34AM -0500, Mike Snitzer wrote:
> > Noticed after further review that it seems a bit weird to have the non
> > blk-mq support in drivers calling blk_mq_rq_to_pdu().  But I'm not sure
> > a blk_rq_to_pdu() macro to blk_mq_rq_to_pdu() is the right thing.  What
> > do you guys think?
> 
> My first version had an additional name for it, but it caused more
> confusion than help.

And renaming blk_mq_rq_to_pdu() to blk_rq_to_pdu() tree-wide would be
too much churn?

I can live with blk_mq_rq_to_pdu(); just figured I'd ask.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Christoph Hellwig]

On Fri, Jan 27, 2017 at 09:21:46AM -0700, Jens Axboe wrote:
> On 01/27/2017 09:17 AM, Christoph Hellwig wrote:
> > On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
> >> I've queued this up for 4.11. Since some of the patches had dependencies
> >> on changes in master since for-4.11/block was forked, they are sitting
> >> in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
> >> in first. for-next has everything, as usual.
> > 
> > Eww.  I just had a couple non-trivial updates that I now do again.
> > In case you haven't pushed it out yet can you let me repost first?
> 
> Why the eww?! You can't fix this with a repost.

Not because of the merge, mostly because I just spent two same
time adding all the ACKs, fixing typos and adding the removal of
the ->cmd tracing to the series and was getting ready for a repost.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Jens Axboe]

On 01/27/2017 09:17 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
>> I've queued this up for 4.11. Since some of the patches had dependencies
>> on changes in master since for-4.11/block was forked, they are sitting
>> in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
>> in first. for-next has everything, as usual.
> 
> Eww.  I just had a couple non-trivial updates that I now do again.
> In case you haven't pushed it out yet can you let me repost first?

Why the eww?! You can't fix this with a repost.

It's fine, I'll just ship off for-4.11/block first (as usual), then
for-4.11/rq-refactor.

The two issues is in virtio_blk and raid1. For some reason, raid1
included a refactor of a function later in the cycle (hrmpf). So there's
really no good way to solve this, unless I pull in v4.10-rc5 into
for-4.11/block.  And I don't want to do that. Hence the topic branch for
this work.

I have pushed it out, but it's not merged into for-next yet, it's just
standalone. When I've done some sanity testing, I'll push it out.


-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

[Christoph Hellwig]

On Fri, Jan 27, 2017 at 11:34:34AM -0500, Mike Snitzer wrote:
> Noticed after further review that it seems a bit weird to have the non
> blk-mq support in drivers calling blk_mq_rq_to_pdu().  But I'm not sure
> a blk_rq_to_pdu() macro to blk_mq_rq_to_pdu() is the right thing.  What
> do you guys think?

My first version had an additional name for it, but it caused more
confusion than help.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

[Mike Snitzer]

On Wed, Jan 25 2017 at 12:25pm -0500,
Christoph Hellwig  wrote:

> DM already calls blk_mq_alloc_request on the request_queue of the
> underlying device if it is a blk-mq device.  But now that we allow drivers
> to allocate additional data and initialize it ahead of time we need to do
> the same for all drivers.   Doing so and using the new cmd_size
> infrastructure in the block layer greatly simplifies the dm-rq and mpath
> code, and should also make arbitrary combinations of SQ and MQ devices
> with SQ or MQ device mapper tables easily possible as a further step.
> 
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: Mike Snitzer 
...
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index 3f12916..8d06834 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -185,7 +163,7 @@ static void end_clone_bio(struct bio *clone)
>  
>  static struct dm_rq_target_io *tio_from_request(struct request *rq)
>  {
> - return (rq->q->mq_ops ? blk_mq_rq_to_pdu(rq) : rq->special);
> + return blk_mq_rq_to_pdu(rq);
>  }

Noticed after further review that it seems a bit weird to have the non
blk-mq support in drivers calling blk_mq_rq_to_pdu().  But I'm not sure
a blk_rq_to_pdu() macro to blk_mq_rq_to_pdu() is the right thing.  What
do you guys think?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Christoph Hellwig]

On Fri, Jan 27, 2017 at 09:27:02AM -0700, Jens Axboe wrote:
> Feel free to repost it, I have no problem rebasing that branch as it's
> standalone for now.

Ok, I'll repost what I have right now, which is on top of a merge
of your block/for-4.11/next and your for-next from this morning
my time.

Btw, I disagred with your patch to use op_is_flush in
generic_make_request_checks - given that we clear these flags just
below I think using the helper obsfucates what's really going on.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/19] block: add a op_is_flush helper

[Christoph Hellwig]

This centralizes the checks for bios that needs to be go into the flush
state machine.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Reviewed-by: Martin K. Petersen 
---
 block/blk-core.c |  8 
 block/blk-mq-sched.c |  5 ++---
 block/blk-mq.c   |  4 ++--
 drivers/md/bcache/request.c  |  2 +-
 drivers/md/dm-cache-target.c | 13 +++--
 drivers/md/dm-thin.c | 13 +
 include/linux/blk_types.h|  9 +
 7 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 78daf5b..4bfd867 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1035,7 +1035,7 @@ static bool blk_rq_should_init_elevator(struct bio *bio)
 * Flush requests do not use the elevator so skip initialization.
 * This allows a request to share the flush and elevator data.
 */
-   if (bio->bi_opf & (REQ_PREFLUSH | REQ_FUA))
+   if (op_is_flush(bio->bi_opf))
return false;
 
return true;
@@ -1641,7 +1641,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   if (bio->bi_opf & (REQ_PREFLUSH | REQ_FUA)) {
+   if (op_is_flush(bio->bi_opf)) {
spin_lock_irq(q->queue_lock);
where = ELEVATOR_INSERT_FLUSH;
goto get_rq;
@@ -2145,7 +2145,7 @@ int blk_insert_cloned_request(struct request_queue *q, 
struct request *rq)
 */
BUG_ON(blk_queued_rq(rq));
 
-   if (rq->cmd_flags & (REQ_PREFLUSH | REQ_FUA))
+   if (op_is_flush(rq->cmd_flags))
where = ELEVATOR_INSERT_FLUSH;
 
add_acct_request(q, rq, where);
@@ -3256,7 +3256,7 @@ void blk_flush_plug_list(struct blk_plug *plug, bool 
from_schedule)
/*
 * rq is already accounted, so use raw insert
 */
-   if (rq->cmd_flags & (REQ_PREFLUSH | REQ_FUA))
+   if (op_is_flush(rq->cmd_flags))
__elv_add_request(q, rq, ELEVATOR_INSERT_FLUSH);
else
__elv_add_request(q, rq, ELEVATOR_INSERT_SORT_MERGE);
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index 5e91743..1112752 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -111,7 +111,6 @@ struct request *blk_mq_sched_get_request(struct 
request_queue *q,
struct blk_mq_hw_ctx *hctx;
struct blk_mq_ctx *ctx;
struct request *rq;
-   const bool is_flush = op & (REQ_PREFLUSH | REQ_FUA);
 
blk_queue_enter_live(q);
ctx = blk_mq_get_ctx(q);
@@ -126,7 +125,7 @@ struct request *blk_mq_sched_get_request(struct 
request_queue *q,
 * Flush requests are special and go directly to the
 * dispatch list.
 */
-   if (!is_flush && e->type->ops.mq.get_request) {
+   if (!op_is_flush(op) && e->type->ops.mq.get_request) {
rq = e->type->ops.mq.get_request(q, op, data);
if (rq)
rq->rq_flags |= RQF_QUEUED;
@@ -139,7 +138,7 @@ struct request *blk_mq_sched_get_request(struct 
request_queue *q,
}
 
if (rq) {
-   if (!is_flush) {
+   if (!op_is_flush(op)) {
rq->elv.icq = NULL;
if (e && e->type->icq_cache)
blk_mq_sched_assign_ioc(q, rq, bio);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 68b..ff70219 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1405,7 +1405,7 @@ static void blk_mq_try_issue_directly(struct request *rq, 
blk_qc_t *cookie)
 static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
 {
const int is_sync = op_is_sync(bio->bi_opf);
-   const int is_flush_fua = bio->bi_opf & (REQ_PREFLUSH | REQ_FUA);
+   const int is_flush_fua = op_is_flush(bio->bi_opf);
struct blk_mq_alloc_data data = { .flags = 0 };
struct request *rq;
unsigned int request_count = 0, srcu_idx;
@@ -1527,7 +1527,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue 
*q, struct bio *bio)
 static blk_qc_t blk_sq_make_request(struct request_queue *q, struct bio *bio)
 {
const int is_sync = op_is_sync(bio->bi_opf);
-   const int is_flush_fua = bio->bi_opf & (REQ_PREFLUSH | REQ_FUA);
+   const int is_flush_fua = op_is_flush(bio->bi_opf);
struct blk_plug *plug;
unsigned int request_count = 0;
struct blk_mq_alloc_data data = { .flags = 0 };
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 76d2087..01035e7 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -666,7 +666,7 @@ static inline struct search *search_alloc(struct bio *bio,
s->iop.write_prio   = 

split scsi passthrough fields out of struct request V3

[Christoph Hellwig]

Hi all,

this series splits the support for SCSI passthrough commands from the
main struct request used all over the block layer into a separate
scsi_request structure that drivers that want to support SCSI passthough
need to embedded as the first thing into their request-private data,
similar to how we handle NVMe passthrough commands.

To support this I've added support for that the private data after
request structure to the legacy request path instead, so that it can
be treated the same way as the blk-mq path.  Compare to the current
scsi_cmnd allocator that actually is a major simplification.

Changes since V2:
 - remove req->cmd tracing
 - minor spelling fixes

Changes since V1:
 - fix handling of a NULL sense pointer in __scsi_execute
 - clean up handling of the flush flags in the block layer and MD
 - additional small cleanup in dm-rq
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/19] md: cleanup bio op / flags handling in raid1_write_request

[Christoph Hellwig]

No need for the local variables, the bio is still live and we can just
assign the bits we want directly.  Make me wonder why we can't assign
all the bio flags to start with.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Bart Van Assche 
Reviewed-by: Martin K. Petersen 
---
 drivers/md/raid1.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 7b0f647..67b0365 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1170,10 +1170,6 @@ static void raid1_write_request(struct mddev *mddev, 
struct bio *bio,
int i, disks;
struct bitmap *bitmap = mddev->bitmap;
unsigned long flags;
-   const int op = bio_op(bio);
-   const unsigned long do_sync = (bio->bi_opf & REQ_SYNC);
-   const unsigned long do_flush_fua = (bio->bi_opf &
-   (REQ_PREFLUSH | REQ_FUA));
struct md_rdev *blocked_rdev;
struct blk_plug_cb *cb;
struct raid1_plug_cb *plug = NULL;
@@ -1389,7 +1385,8 @@ static void raid1_write_request(struct mddev *mddev, 
struct bio *bio,
   conf->mirrors[i].rdev->data_offset);
mbio->bi_bdev = conf->mirrors[i].rdev->bdev;
mbio->bi_end_io = raid1_end_write_request;
-   bio_set_op_attrs(mbio, op, do_flush_fua | do_sync);
+   mbio->bi_opf = bio_op(bio) |
+   (bio->bi_opf & (REQ_SYNC | REQ_PREFLUSH | REQ_FUA));
if (test_bit(FailFast, >mirrors[i].rdev->flags) &&
!test_bit(WriteMostly, >mirrors[i].rdev->flags) &&
conf->raid_disks - mddev->degraded > 1)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Jens Axboe]

On 01/27/2017 09:23 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:21:46AM -0700, Jens Axboe wrote:
>> On 01/27/2017 09:17 AM, Christoph Hellwig wrote:
>>> On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
 I've queued this up for 4.11. Since some of the patches had dependencies
 on changes in master since for-4.11/block was forked, they are sitting
 in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
 in first. for-next has everything, as usual.
>>>
>>> Eww.  I just had a couple non-trivial updates that I now do again.
>>> In case you haven't pushed it out yet can you let me repost first?
>>
>> Why the eww?! You can't fix this with a repost.
> 
> Not because of the merge, mostly because I just spent two same
> time adding all the ACKs, fixing typos and adding the removal of
> the ->cmd tracing to the series and was getting ready for a repost.

Feel free to repost it, I have no problem rebasing that branch as it's
standalone for now.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Christoph Hellwig]

On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
> I've queued this up for 4.11. Since some of the patches had dependencies
> on changes in master since for-4.11/block was forked, they are sitting
> in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
> in first. for-next has everything, as usual.

Eww.  I just had a couple non-trivial updates that I now do again.
In case you haven't pushed it out yet can you let me repost first?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/18] block: allow specifying size for extra command data

[Christoph Hellwig]

On Wed, Jan 25, 2017 at 10:15:55PM -0500, Martin K. Petersen wrote:
> +static void *alloc_request_size(gfp_t gfp_mask, void *data)
> 
> I like alloc_request_simple() but alloc_request_size() seems a bit
> contrived. _reserve? _extra? _special? Don't have any good suggestions,
> I'm afraid.

Not that I'm a fan of _size, but I like the other suggestions even less.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: split scsi passthrough fields out of struct request V2

[Jens Axboe]

On Wed, Jan 25 2017, Christoph Hellwig wrote:
> Hi all,
> 
> this series splits the support for SCSI passthrough commands from the
> main struct request used all over the block layer into a separate
> scsi_request structure that drivers that want to support SCSI passthough
> need to embedded as the first thing into their request-private data,
> similar to how we handle NVMe passthrough commands.
> 
> To support this I've added support for that the private data after
> request structure to the legacy request path instead, so that it can
> be treated the same way as the blk-mq path.  Compare to the current
> scsi_cmnd allocator that actually is a major simplification.
> 
> Changes since V1:
>  - fix handling of a NULL sense pointer in __scsi_execute
>  - clean up handling of the flush flags in the block layer and MD
>  - additional small cleanup in dm-rq

I've queued this up for 4.11. Since some of the patches had dependencies
on changes in master since for-4.11/block was forked, they are sitting
in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
in first. for-next has everything, as usual.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/2] scsi: scsi_transport_fc: Provide a lightweight option for Virtual FC Hosts.

[KY Srinivasan]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Thursday, January 19, 2017 7:12 AM
> To: Cathy Avery 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH 1/2] scsi: scsi_transport_fc: Provide a lightweight option
> for Virtual FC Hosts.
> 
> On Wed, Jan 18, 2017 at 03:28:57PM -0500, Cathy Avery wrote:
> > The patch provides a means to offer a lightweight option to the
> > current FC transport class. The new option is selected by a
> > driver when it indicates it wants the lightweight
> > transport via fc_function_template.
> 
> This need some really good documentation in the code and changelog
> what "lightweight" means.  It's a pretty horrible term, btw.

This was a concept that James proposed almost a year ago. I agree, we need to 
document this
better.

K. Y

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: srp_transport: Fix 'always false comparison' in srp_tmo_valid()

[Augusto Mecking Caringi]

On Thu, Jan 26, 2017 at 3:11 PM, Bart Van Assche
 wrote:
> This patch is wrong. The purpose of the dev_loss_tmo >= LONG_MAX / HZ check
> is to avoid that the expression 1UL * dev_loss_tmo * HZ further down
> overflows. Can you check whether changing the if-statement into if (1UL *
> dev_loss_tmo >= LONG_MAX / HZ) also suppresses the compiler warning?

Hi Bart,

Right, now a I see...

Doing your proposed change the warning go away...

Do you want me to send a new patch for that?

-- 
Augusto Mecking Caringi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [dm-devel] split scsi passthrough fields out of struct request V2

[Jens Axboe]

On 01/26/2017 11:40 PM, Jens Axboe wrote:
> On 01/26/2017 06:22 PM, Jens Axboe wrote:
>> On 01/26/2017 06:15 PM, Bart Van Assche wrote:
>>> On Thu, 2017-01-26 at 17:41 -0700, Jens Axboe wrote:
 On 01/26/2017 05:38 PM, Bart Van Assche wrote:
> I see similar behavior with the blk-mq-sched branch of
> git://git.kernel.dk/linux-block.git (git commit ID 0efe27068ecf):
> booting happens much slower than usual and I/O hangs if I run the
> srp-test software.

 Please don't run that, run for-4.11/block and merge it to master.
 Same behavior?
>>>
>>> I have not yet had the chance to run the srp-test software against that
>>> kernel. But I already see that booting takes more than ten times longer
>>> than usual. Note: as far as I know the dm-mpath driver is not involved
>>> in the boot process of my test system.
>>
>> What's your boot device? I've been booting this on a variety of setups,
>> no problems observed. It's booting my laptop, and on SCSI and SATA as
>> well. What is your root drive? What is the queue depth of it?
>> Controller?
> 
> Are you using dm for your root device?
> 
> I think I see what is going on. The scheduler framework put the
> insertion of flushes on the side, whereas it's integrated "nicely"
> on the legacy side.
> 
> Can you try with this applied? This is on top of the previous two that
> we already went through. Or, you can just pull:
> 
> git://git.kernel.dk/linux-block for-4.11/next
> 
> which is for-4.11/block with the next set of fixes on top that I haven't
> pulled in yet.

The previous patch had a bug if you didn't use a scheduler, here's a
version that should work fine in both cases. I've also updated the
above mentioned branch, so feel free to pull that as well and merge to
master like before.

commit 2f54ba92a274a7c1a5ceb34a56565f84f7b994b7
Author: Jens Axboe 
Date:   Fri Jan 27 01:00:47 2017 -0700

blk-mq-sched: add flush insertion into blk_mq_sched_insert_request()

Instead of letting the caller check this and handle the details
of inserting a flush request, put the logic in the scheduler
insertion function. This fixes direct flush insertion outside
of the usual make_request_fn calls, like from dm via
blk_insert_cloned_request().

Signed-off-by: Jens Axboe 

diff --git a/block/blk-core.c b/block/blk-core.c
index a61f1407f4f6..78daf5b6d7cb 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2129,7 +2129,7 @@ int blk_insert_cloned_request(struct request_queue *q, 
struct request *rq)
if (q->mq_ops) {
if (blk_queue_io_stat(q))
blk_account_io_start(rq, true);
-   blk_mq_sched_insert_request(rq, false, true, false);
+   blk_mq_sched_insert_request(rq, false, true, false, false);
return 0;
}
 
diff --git a/block/blk-exec.c b/block/blk-exec.c
index 86656fdfa637..ed1f10165268 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -66,7 +66,7 @@ void blk_execute_rq_nowait(struct request_queue *q, struct 
gendisk *bd_disk,
 * be reused after dying flag is set
 */
if (q->mq_ops) {
-   blk_mq_sched_insert_request(rq, at_head, true, false);
+   blk_mq_sched_insert_request(rq, at_head, true, false, false);
return;
}
 
diff --git a/block/blk-flush.c b/block/blk-flush.c
index d7de34ee39c2..4427896641ac 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -456,7 +456,7 @@ void blk_insert_flush(struct request *rq)
if ((policy & REQ_FSEQ_DATA) &&
!(policy & (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH))) {
if (q->mq_ops)
-   blk_mq_sched_insert_request(rq, false, true, false);
+   blk_mq_sched_insert_request(rq, false, true, false, 
false);
else
list_add_tail(>queuelist, >queue_head);
return;
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index c27613de80c5..5e91743e193a 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -336,6 +336,64 @@ void blk_mq_sched_restart_queues(struct blk_mq_hw_ctx 
*hctx)
}
 }
 
+/*
+ * Add flush/fua to the queue. If we fail getting a driver tag, then
+ * punt to the requeue list. Requeue will re-invoke us from a context
+ * that's safe to block from.
+ */
+static void blk_mq_sched_insert_flush(struct blk_mq_hw_ctx *hctx,
+ struct request *rq, bool can_block)
+{
+   if (blk_mq_get_driver_tag(rq, , can_block)) {
+   blk_insert_flush(rq);
+   blk_mq_run_hw_queue(hctx, true);
+   } else
+   blk_mq_add_to_requeue_list(rq, true, true);
+}
+
+void blk_mq_sched_insert_request(struct request *rq, bool at_head,
+bool run_queue, bool async, bool can_block)
+{
+   struct request_queue *q = rq->q;
+   struct elevator_queue *e = 

Re: [PATCH V2 05/24] aacraid: Retrieve and update the device types

[Johannes Thumshirn]

On Thu, Jan 26, 2017 at 09:00:42PM +, Raghava Aditya Renukunta wrote:
> 
> 
> > -Original Message-
> > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> > ow...@vger.kernel.org] On Behalf Of Raghava Aditya Renukunta
> > Sent: Thursday, January 26, 2017 10:44 AM
> > To: Johannes Thumshirn 
> > Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; linux-
> > s...@vger.kernel.org; Dave Carroll ; Gana
> > Sridaran ; Scott Benesh
> > 
> > Subject: RE: [PATCH V2 05/24] aacraid: Retrieve and update the device types
> > 
> > EXTERNAL EMAIL
> > 
> > 
> > > -Original Message-
> > > From: Johannes Thumshirn [mailto:jthumsh...@suse.de]
> > > Sent: Thursday, January 26, 2017 1:00 AM
> > > To: Raghava Aditya Renukunta
> > > 
> > > Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com; linux-
> > > s...@vger.kernel.org; Dave Carroll ; Gana
> > > Sridaran ; Scott Benesh
> > > 
> > > Subject: Re: [PATCH V2 05/24] aacraid: Retrieve and update the device
> > types
> > >
> > > EXTERNAL EMAIL
> > >
> > >
> > > On Wed, Jan 25, 2017 at 10:00:52AM -0800, Raghava Aditya Renukunta
> > wrote:
> > > > This patch adds support to retrieve the type of each adapter connected
> > > > device. Applicable to HBA1000 and SmartIOC2000 products
> > > >
> > > > Signed-off-by: Raghava Aditya Renukunta
> > > 
> > > > Signed-off-by: Dave Carroll 
> > > >
> > > > ---
> > >
> > > [...]
> > >
> > > >  /*
> > > >   *   Adapter Information Block
> > > >   *
> > > > @@ -1056,7 +1091,28 @@ struct aac_supplement_adapter_info
> > > >   /* StructExpansion == 1 */
> > > >   __le32  FeatureBits3;
> > > >   __le32  SupportedPerformanceModes;
> > > > - __le32  ReservedForFutureGrowth[80];
> > > > + u8  HostBusType;/* uses HOST_BUS_TYPE_xxx defines 
> > > > */
> > > > + u8  HostBusWidth;   /* actual width in bits or links 
> > > > */
> > > > + u16 HostBusSpeed;   /* actual bus speed/link rate in 
> > > > MHz */
> > > > + u8  MaxRRCDrives;   /* max. number of ITP-RRC 
> > > > drives/pool */
> > > > + u8  MaxDiskXtasks;  /* max. possible num of DiskX 
> > > > Tasks */
> > > > +
> > > > + u8  CpldVerLoaded;
> > > > + u8  CpldVerInFlash;
> > > > +
> > > > + __le64  MaxRRCCapacity;
> > > > + __le32  CompiledMaxHistLogLevel;
> > > > + u8  CustomBoardName[12];
> > > > + u16 SupportedCntlrMode; /* identify supported controller 
> > > > mode
> > */
> > > > + u16 ReservedForFuture16;
> > > > + __le32  SupportedOptions3;  /* reserved for future options */
> > > > +
> > > > + __le16  VirtDeviceBus;  /* virt. SCSI device for Thor */
> > > > + __le16  VirtDeviceTarget;
> > > > + __le16  VirtDeviceLUN;
> > > > + __le16  Unused;
> > > > + __le32  ReservedForFutureGrowth[68];
> > > > +
> > 
> > Same here.
> 
> On second thought changing all of the variables here will open up 
> Pandoras  box. I will leave them as it is for now  and change the whole
>  structure and anything attached it in one of my next patch submission series.
> 
> Will that be ok?

Yes that's something I can live with, *iff* it really happens.

Thanks,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html