<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi, branch v4.18.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>scsi: core: Avoid that SCSI device removal through sysfs triggers a deadlock</title>
<updated>2018-09-05T07:29:54+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@wdc.com</email>
</author>
<published>2018-08-02T17:51:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9558fc1bab40614e8cd6d97b1830501458721e6a'/>
<id>9558fc1bab40614e8cd6d97b1830501458721e6a</id>
<content type='text'>
commit 0ee223b2e1f67cb2de9c0e3247c510d846e74d63 upstream.

A long time ago the unfortunate decision was taken to add a self-deletion
attribute to the sysfs SCSI device directory. That decision was unfortunate
because self-deletion is really tricky. We can't drop that attribute
because widely used user space software depends on it, namely the
rescan-scsi-bus.sh script. Hence this patch that avoids that writing into
that attribute triggers a deadlock. See also commit 7973cbd9fbd9 ("[PATCH]
add sysfs attributes to scan and delete scsi_devices").

This patch avoids that self-removal triggers the following deadlock:

======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc2-dbg+ #5 Not tainted
------------------------------------------------------
modprobe/6539 is trying to acquire lock:
000000008323c4cd (kn-&gt;count#202){++++}, at: kernfs_remove_by_name_ns+0x45/0x90

but task is already holding lock:
00000000a6ec2c69 (&amp;shost-&gt;scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;shost-&gt;scan_mutex){+.+.}:
       __mutex_lock+0xfe/0xc70
       mutex_lock_nested+0x1b/0x20
       scsi_remove_device+0x26/0x40 [scsi_mod]
       sdev_store_delete+0x27/0x30 [scsi_mod]
       dev_attr_store+0x3e/0x50
       sysfs_kf_write+0x87/0xa0
       kernfs_fop_write+0x190/0x230
       __vfs_write+0xd2/0x3b0
       vfs_write+0x101/0x270
       ksys_write+0xab/0x120
       __x64_sys_write+0x43/0x50
       do_syscall_64+0x77/0x230
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-&gt; #0 (kn-&gt;count#202){++++}:
       lock_acquire+0xd2/0x260
       __kernfs_remove+0x424/0x4a0
       kernfs_remove_by_name_ns+0x45/0x90
       remove_files.isra.1+0x3a/0x90
       sysfs_remove_group+0x5c/0xc0
       sysfs_remove_groups+0x39/0x60
       device_remove_attrs+0x82/0xb0
       device_del+0x251/0x580
       __scsi_remove_device+0x19f/0x1d0 [scsi_mod]
       scsi_forget_host+0x37/0xb0 [scsi_mod]
       scsi_remove_host+0x9b/0x150 [scsi_mod]
       sdebug_driver_remove+0x4b/0x150 [scsi_debug]
       device_release_driver_internal+0x241/0x360
       device_release_driver+0x12/0x20
       bus_remove_device+0x1bc/0x290
       device_del+0x259/0x580
       device_unregister+0x1a/0x70
       sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
       scsi_debug_exit+0x76/0xe8 [scsi_debug]
       __x64_sys_delete_module+0x1c1/0x280
       do_syscall_64+0x77/0x230
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;shost-&gt;scan_mutex);
                               lock(kn-&gt;count#202);
                               lock(&amp;shost-&gt;scan_mutex);
  lock(kn-&gt;count#202);

 *** DEADLOCK ***

2 locks held by modprobe/6539:
 #0: 00000000efaf9298 (&amp;dev-&gt;mutex){....}, at: device_release_driver_internal+0x68/0x360
 #1: 00000000a6ec2c69 (&amp;shost-&gt;scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod]

stack backtrace:
CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
 dump_stack+0xa4/0xf5
 print_circular_bug.isra.34+0x213/0x221
 __lock_acquire+0x1a7e/0x1b50
 lock_acquire+0xd2/0x260
 __kernfs_remove+0x424/0x4a0
 kernfs_remove_by_name_ns+0x45/0x90
 remove_files.isra.1+0x3a/0x90
 sysfs_remove_group+0x5c/0xc0
 sysfs_remove_groups+0x39/0x60
 device_remove_attrs+0x82/0xb0
 device_del+0x251/0x580
 __scsi_remove_device+0x19f/0x1d0 [scsi_mod]
 scsi_forget_host+0x37/0xb0 [scsi_mod]
 scsi_remove_host+0x9b/0x150 [scsi_mod]
 sdebug_driver_remove+0x4b/0x150 [scsi_debug]
 device_release_driver_internal+0x241/0x360
 device_release_driver+0x12/0x20
 bus_remove_device+0x1bc/0x290
 device_del+0x259/0x580
 device_unregister+0x1a/0x70
 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
 scsi_debug_exit+0x76/0xe8 [scsi_debug]
 __x64_sys_delete_module+0x1c1/0x280
 do_syscall_64+0x77/0x230
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

See also https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html.

Fixes: ac0ece9174ac ("scsi: use device_remove_file_self() instead of device_schedule_callback()")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0ee223b2e1f67cb2de9c0e3247c510d846e74d63 upstream.

A long time ago the unfortunate decision was taken to add a self-deletion
attribute to the sysfs SCSI device directory. That decision was unfortunate
because self-deletion is really tricky. We can't drop that attribute
because widely used user space software depends on it, namely the
rescan-scsi-bus.sh script. Hence this patch that avoids that writing into
that attribute triggers a deadlock. See also commit 7973cbd9fbd9 ("[PATCH]
add sysfs attributes to scan and delete scsi_devices").

This patch avoids that self-removal triggers the following deadlock:

======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc2-dbg+ #5 Not tainted
------------------------------------------------------
modprobe/6539 is trying to acquire lock:
000000008323c4cd (kn-&gt;count#202){++++}, at: kernfs_remove_by_name_ns+0x45/0x90

but task is already holding lock:
00000000a6ec2c69 (&amp;shost-&gt;scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;shost-&gt;scan_mutex){+.+.}:
       __mutex_lock+0xfe/0xc70
       mutex_lock_nested+0x1b/0x20
       scsi_remove_device+0x26/0x40 [scsi_mod]
       sdev_store_delete+0x27/0x30 [scsi_mod]
       dev_attr_store+0x3e/0x50
       sysfs_kf_write+0x87/0xa0
       kernfs_fop_write+0x190/0x230
       __vfs_write+0xd2/0x3b0
       vfs_write+0x101/0x270
       ksys_write+0xab/0x120
       __x64_sys_write+0x43/0x50
       do_syscall_64+0x77/0x230
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-&gt; #0 (kn-&gt;count#202){++++}:
       lock_acquire+0xd2/0x260
       __kernfs_remove+0x424/0x4a0
       kernfs_remove_by_name_ns+0x45/0x90
       remove_files.isra.1+0x3a/0x90
       sysfs_remove_group+0x5c/0xc0
       sysfs_remove_groups+0x39/0x60
       device_remove_attrs+0x82/0xb0
       device_del+0x251/0x580
       __scsi_remove_device+0x19f/0x1d0 [scsi_mod]
       scsi_forget_host+0x37/0xb0 [scsi_mod]
       scsi_remove_host+0x9b/0x150 [scsi_mod]
       sdebug_driver_remove+0x4b/0x150 [scsi_debug]
       device_release_driver_internal+0x241/0x360
       device_release_driver+0x12/0x20
       bus_remove_device+0x1bc/0x290
       device_del+0x259/0x580
       device_unregister+0x1a/0x70
       sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
       scsi_debug_exit+0x76/0xe8 [scsi_debug]
       __x64_sys_delete_module+0x1c1/0x280
       do_syscall_64+0x77/0x230
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;shost-&gt;scan_mutex);
                               lock(kn-&gt;count#202);
                               lock(&amp;shost-&gt;scan_mutex);
  lock(kn-&gt;count#202);

 *** DEADLOCK ***

2 locks held by modprobe/6539:
 #0: 00000000efaf9298 (&amp;dev-&gt;mutex){....}, at: device_release_driver_internal+0x68/0x360
 #1: 00000000a6ec2c69 (&amp;shost-&gt;scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150 [scsi_mod]

stack backtrace:
CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Call Trace:
 dump_stack+0xa4/0xf5
 print_circular_bug.isra.34+0x213/0x221
 __lock_acquire+0x1a7e/0x1b50
 lock_acquire+0xd2/0x260
 __kernfs_remove+0x424/0x4a0
 kernfs_remove_by_name_ns+0x45/0x90
 remove_files.isra.1+0x3a/0x90
 sysfs_remove_group+0x5c/0xc0
 sysfs_remove_groups+0x39/0x60
 device_remove_attrs+0x82/0xb0
 device_del+0x251/0x580
 __scsi_remove_device+0x19f/0x1d0 [scsi_mod]
 scsi_forget_host+0x37/0xb0 [scsi_mod]
 scsi_remove_host+0x9b/0x150 [scsi_mod]
 sdebug_driver_remove+0x4b/0x150 [scsi_debug]
 device_release_driver_internal+0x241/0x360
 device_release_driver+0x12/0x20
 bus_remove_device+0x1bc/0x290
 device_del+0x259/0x580
 device_unregister+0x1a/0x70
 sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
 scsi_debug_exit+0x76/0xe8 [scsi_debug]
 __x64_sys_delete_module+0x1c1/0x280
 do_syscall_64+0x77/0x230
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

See also https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html.

Fixes: ac0ece9174ac ("scsi: use device_remove_file_self() instead of device_schedule_callback()")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: mpt3sas: Fix _transport_smp_handler() error path</title>
<updated>2018-09-05T07:29:54+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@wdc.com</email>
</author>
<published>2018-06-15T21:41:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=373a1411a10306721596f84b34d8b39ccd2309b6'/>
<id>373a1411a10306721596f84b34d8b39ccd2309b6</id>
<content type='text'>
commit 91b7bdb2c0089cbbb817df6888ab1458c645184e upstream.

This patch avoids that smatch complains about a double unlock on
ioc-&gt;transport_cmds.mutex.

Fixes: 651a01364994 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Sathya Prakash &lt;sathya.prakash@broadcom.com&gt;
Cc: Chaitra P B &lt;chaitra.basappa@broadcom.com&gt;
Cc: Suganath Prabu Subramani &lt;suganath-prabu.subramani@broadcom.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 91b7bdb2c0089cbbb817df6888ab1458c645184e upstream.

This patch avoids that smatch complains about a double unlock on
ioc-&gt;transport_cmds.mutex.

Fixes: 651a01364994 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Sathya Prakash &lt;sathya.prakash@broadcom.com&gt;
Cc: Chaitra P B &lt;chaitra.basappa@broadcom.com&gt;
Cc: Suganath Prabu Subramani &lt;suganath-prabu.subramani@broadcom.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: mpt3sas: Fix calltrace observed while running IO &amp; reset</title>
<updated>2018-09-05T07:29:53+00:00</updated>
<author>
<name>Sreekanth Reddy</name>
<email>sreekanth.reddy@broadcom.com</email>
</author>
<published>2018-07-12T16:53:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8039fa72ff4d365e7eb029a63dd3bd0c03d55d8e'/>
<id>8039fa72ff4d365e7eb029a63dd3bd0c03d55d8e</id>
<content type='text'>
commit e70183143cc472960bc60dfee1b7bbe1949feffb upstream.

Below kernel BUG was observed while running IOs with host reset (issued
from application),

mpt3sas_cm0: diag reset: SUCCESS
------------[ cut here ]------------
WARNING: CPU: 12 PID: 4336 at drivers/scsi/mpt3sas/mpt3sas_base.c:3282 mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas]
Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support
 dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod
CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G        W      ------------   3.10.0-875.el7.brdc.x86_64 #1
Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013
Call Trace:
 [&lt;ffffffff9cf16583&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff9c891698&gt;] __warn+0xd8/0x100
 [&lt;ffffffff9c8917dd&gt;] warn_slowpath_null+0x1d/0x20
 [&lt;ffffffffc04f3f4d&gt;] mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas]
 [&lt;ffffffffc05047d2&gt;] _scsih_flush_running_cmds+0x92/0xe0 [mpt3sas]
 [&lt;ffffffffc05095db&gt;] mpt3sas_scsih_reset_handler+0x43b/0xaf0 [mpt3sas]
 [&lt;ffffffff9c894829&gt;] ? vprintk_default+0x29/0x40
 [&lt;ffffffff9cf10531&gt;] ? printk+0x60/0x77
 [&lt;ffffffffc04f06c8&gt;] ? _base_diag_reset+0x238/0x340 [mpt3sas]
 [&lt;ffffffffc04f794d&gt;] mpt3sas_base_hard_reset_handler+0x1ad/0x420 [mpt3sas]
 [&lt;ffffffffc05132b9&gt;] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas]
 [&lt;ffffffffc068d585&gt;] ? xfs_file_aio_write+0x155/0x1b0 [xfs]
 [&lt;ffffffff9ca1a4e3&gt;] ? do_sync_write+0x93/0xe0
 [&lt;ffffffffc051337a&gt;] _ctl_ioctl+0x1a/0x20 [mpt3sas]
 [&lt;ffffffff9ca2fe90&gt;] do_vfs_ioctl+0x350/0x560
 [&lt;ffffffff9ca1dec1&gt;] ? __sb_end_write+0x31/0x60
 [&lt;ffffffff9ca30141&gt;] SyS_ioctl+0xa1/0xc0
 [&lt;ffffffff9cf28715&gt;] ? system_call_after_swapgs+0xa2/0x146
 [&lt;ffffffff9cf287d5&gt;] system_call_fastpath+0x1c/0x21
 [&lt;ffffffff9cf28721&gt;] ? system_call_after_swapgs+0xae/0x146
---[ end trace 5dac5b98d89aaa3c ]---
------------[ cut here ]------------
kernel BUG at block/blk-core.c:1476!
invalid opcode: 0000 [#1] SMP
Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support
 dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod
CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G        W      ------------   3.10.0-875.el7.brdc.x86_64 #1
Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013
task: ffff903fc96e0fd0 ti: ffff903fb1eec000 task.ti: ffff903fb1eec000
RIP: 0010:[&lt;ffffffff9cb19ec0&gt;]  [&lt;ffffffff9cb19ec0&gt;] blk_requeue_request+0x90/0xa0
RSP: 0018:ffff903c6b783dc0  EFLAGS: 00010087
RAX: ffff903bb67026d0 RBX: ffff903b7d6a6140 RCX: dead000000000200
RDX: ffff903bb67026d0 RSI: ffff903bb6702580 RDI: ffff903bb67026d0
RBP: ffff903c6b783dd8 R08: ffff903bb67026d0 R09: ffffd97e80000000
R10: ffff903c658bac00 R11: 0000000000000000 R12: ffff903bb6702580
R13: ffff903fa9a292f0 R14: 0000000000000246 R15: 0000000000001057
FS:  00007f7026f5b740(0000) GS:ffff903c6b780000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f298877c004 CR3: 00000000caf36000 CR4: 00000000000607e0
Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff9cca68ff&gt;] __scsi_queue_insert+0xbf/0x110
 [&lt;ffffffff9cca79ca&gt;] scsi_io_completion+0x5da/0x6a0
 [&lt;ffffffff9cc9ca3c&gt;] scsi_finish_command+0xdc/0x140
 [&lt;ffffffff9cca6aa2&gt;] scsi_softirq_done+0x132/0x160
 [&lt;ffffffff9cb240c6&gt;] blk_done_softirq+0x96/0xc0
 [&lt;ffffffff9c89a905&gt;] __do_softirq+0xf5/0x280
 [&lt;ffffffff9cf2bd2c&gt;] call_softirq+0x1c/0x30
 [&lt;ffffffff9c82d625&gt;] do_softirq+0x65/0xa0
 [&lt;ffffffff9c89ac85&gt;] irq_exit+0x105/0x110
 [&lt;ffffffff9cf2d0a8&gt;] smp_apic_timer_interrupt+0x48/0x60
 [&lt;ffffffff9cf297f2&gt;] apic_timer_interrupt+0x162/0x170
 &lt;EOI&gt;
 [&lt;ffffffff9cca5f41&gt;] ? scsi_done+0x21/0x60
 [&lt;ffffffff9cb5ac18&gt;] ? delay_tsc+0x38/0x60
 [&lt;ffffffff9cb5ab5d&gt;] __const_udelay+0x2d/0x30
 [&lt;ffffffffc04effde&gt;] _base_handshake_req_reply_wait+0x8e/0x4a0 [mpt3sas]
 [&lt;ffffffffc04f0b13&gt;] _base_get_ioc_facts+0x123/0x590 [mpt3sas]
 [&lt;ffffffffc04f06c8&gt;] ? _base_diag_reset+0x238/0x340 [mpt3sas]
 [&lt;ffffffffc04f7993&gt;] mpt3sas_base_hard_reset_handler+0x1f3/0x420 [mpt3sas]
 [&lt;ffffffffc05132b9&gt;] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas]
 [&lt;ffffffffc068d585&gt;] ? xfs_file_aio_write+0x155/0x1b0 [xfs]
 [&lt;ffffffff9ca1a4e3&gt;] ? do_sync_write+0x93/0xe0
 [&lt;ffffffffc051337a&gt;] _ctl_ioctl+0x1a/0x20 [mpt3sas]
 [&lt;ffffffff9ca2fe90&gt;] do_vfs_ioctl+0x350/0x560
 [&lt;ffffffff9ca1dec1&gt;] ? __sb_end_write+0x31/0x60
 [&lt;ffffffff9ca30141&gt;] SyS_ioctl+0xa1/0xc0
 [&lt;ffffffff9cf28715&gt;] ? system_call_after_swapgs+0xa2/0x146
 [&lt;ffffffff9cf287d5&gt;] system_call_fastpath+0x1c/0x21
 [&lt;ffffffff9cf28721&gt;] ? system_call_after_swapgs+0xae/0x146
Code: 83 c3 10 4c 89 e2 4c 89 ee e8 8d 21 04 00 48 8b 03 48 85 c0 75 e5 41 f6 44 24 4a 10 74 ad 4c 89 e6 4c 89 ef e8 b2 42 00 00 eb a0 &lt;0f&gt; 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
RIP  [&lt;ffffffff9cb19ec0&gt;] blk_requeue_request+0x90/0xa0
 RSP &lt;ffff903c6b783dc0&gt;

As a part of host reset operation, driver will flushout all IOs outstanding
at driver level with "DID_RESET" result.  To find which are all commands
outstanding at the driver level, driver loops with smid starting from one
to HBA queue depth and calls mpt3sas_scsih_scsi_lookup_get() to get scmd as
shown below

 for (smid = 1; smid &lt;= ioc-&gt;scsiio_depth; smid++) {
                scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
                if (!scmd)
                        continue;

But in mpt3sas_scsih_scsi_lookup_get() function, driver returns some scsi
cmnds which are not outstanding at the driver level (possibly request is
constructed at block layer since QUEUE_FLAG_QUIESCED is not set. Even if
driver uses scsi_block_requests and scsi_unblock_requests, issue still
persists as they will be just blocking further IO from scsi layer and not
from block layer) and these commands are flushed with DID_RESET host bytes
thus resulting into above kernel BUG.

This issue got introduced by commit dbec4c9040ed ("scsi: mpt3sas: lockless
command submission").

To fix this issue, we have modified the mpt3sas_scsih_scsi_lookup_get() to
check for smid equals to zero (note: whenever any scsi cmnd is processing
at the driver level then smid for that scsi cmnd will be non-zero, always
it starts from one) before it returns the scmd pointer to the caller. If
smid is zero then this function returns scmd pointer as NULL and driver
won't flushout those scsi cmnds at driver level with DID_RESET host byte
thus this issue will not be observed.

[mkp: amended with updated fix from Sreekanth]

Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission")
Cc: stable@vger.kernel.org # v4.16+
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e70183143cc472960bc60dfee1b7bbe1949feffb upstream.

Below kernel BUG was observed while running IOs with host reset (issued
from application),

mpt3sas_cm0: diag reset: SUCCESS
------------[ cut here ]------------
WARNING: CPU: 12 PID: 4336 at drivers/scsi/mpt3sas/mpt3sas_base.c:3282 mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas]
Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support
 dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod
CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G        W      ------------   3.10.0-875.el7.brdc.x86_64 #1
Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013
Call Trace:
 [&lt;ffffffff9cf16583&gt;] dump_stack+0x19/0x1b
 [&lt;ffffffff9c891698&gt;] __warn+0xd8/0x100
 [&lt;ffffffff9c8917dd&gt;] warn_slowpath_null+0x1d/0x20
 [&lt;ffffffffc04f3f4d&gt;] mpt3sas_base_clear_st+0x3d/0x40 [mpt3sas]
 [&lt;ffffffffc05047d2&gt;] _scsih_flush_running_cmds+0x92/0xe0 [mpt3sas]
 [&lt;ffffffffc05095db&gt;] mpt3sas_scsih_reset_handler+0x43b/0xaf0 [mpt3sas]
 [&lt;ffffffff9c894829&gt;] ? vprintk_default+0x29/0x40
 [&lt;ffffffff9cf10531&gt;] ? printk+0x60/0x77
 [&lt;ffffffffc04f06c8&gt;] ? _base_diag_reset+0x238/0x340 [mpt3sas]
 [&lt;ffffffffc04f794d&gt;] mpt3sas_base_hard_reset_handler+0x1ad/0x420 [mpt3sas]
 [&lt;ffffffffc05132b9&gt;] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas]
 [&lt;ffffffffc068d585&gt;] ? xfs_file_aio_write+0x155/0x1b0 [xfs]
 [&lt;ffffffff9ca1a4e3&gt;] ? do_sync_write+0x93/0xe0
 [&lt;ffffffffc051337a&gt;] _ctl_ioctl+0x1a/0x20 [mpt3sas]
 [&lt;ffffffff9ca2fe90&gt;] do_vfs_ioctl+0x350/0x560
 [&lt;ffffffff9ca1dec1&gt;] ? __sb_end_write+0x31/0x60
 [&lt;ffffffff9ca30141&gt;] SyS_ioctl+0xa1/0xc0
 [&lt;ffffffff9cf28715&gt;] ? system_call_after_swapgs+0xa2/0x146
 [&lt;ffffffff9cf287d5&gt;] system_call_fastpath+0x1c/0x21
 [&lt;ffffffff9cf28721&gt;] ? system_call_after_swapgs+0xae/0x146
---[ end trace 5dac5b98d89aaa3c ]---
------------[ cut here ]------------
kernel BUG at block/blk-core.c:1476!
invalid opcode: 0000 [#1] SMP
Modules linked in: macsec tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun devlink ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc vfat fat sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support
 dcdbas pcspkr joydev ipmi_ssif ses enclosure sg ipmi_devintf acpi_pad ipmi_msghandler acpi_power_meter mei_me lpc_ich wmi mei shpchp ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic ata_generic pata_acpi uas usb_storage mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ata_piix mpt3sas libata crct10dif_pclmul crct10dif_common tg3 crc32c_intel i2c_core raid_class ptp scsi_transport_sas pps_core dm_mirror dm_region_hash dm_log dm_mod
CPU: 12 PID: 4336 Comm: python Kdump: loaded Tainted: G        W      ------------   3.10.0-875.el7.brdc.x86_64 #1
Hardware name: Dell Inc. PowerEdge R820/0YWR73, BIOS 1.5.0 03/08/2013
task: ffff903fc96e0fd0 ti: ffff903fb1eec000 task.ti: ffff903fb1eec000
RIP: 0010:[&lt;ffffffff9cb19ec0&gt;]  [&lt;ffffffff9cb19ec0&gt;] blk_requeue_request+0x90/0xa0
RSP: 0018:ffff903c6b783dc0  EFLAGS: 00010087
RAX: ffff903bb67026d0 RBX: ffff903b7d6a6140 RCX: dead000000000200
RDX: ffff903bb67026d0 RSI: ffff903bb6702580 RDI: ffff903bb67026d0
RBP: ffff903c6b783dd8 R08: ffff903bb67026d0 R09: ffffd97e80000000
R10: ffff903c658bac00 R11: 0000000000000000 R12: ffff903bb6702580
R13: ffff903fa9a292f0 R14: 0000000000000246 R15: 0000000000001057
FS:  00007f7026f5b740(0000) GS:ffff903c6b780000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f298877c004 CR3: 00000000caf36000 CR4: 00000000000607e0
Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff9cca68ff&gt;] __scsi_queue_insert+0xbf/0x110
 [&lt;ffffffff9cca79ca&gt;] scsi_io_completion+0x5da/0x6a0
 [&lt;ffffffff9cc9ca3c&gt;] scsi_finish_command+0xdc/0x140
 [&lt;ffffffff9cca6aa2&gt;] scsi_softirq_done+0x132/0x160
 [&lt;ffffffff9cb240c6&gt;] blk_done_softirq+0x96/0xc0
 [&lt;ffffffff9c89a905&gt;] __do_softirq+0xf5/0x280
 [&lt;ffffffff9cf2bd2c&gt;] call_softirq+0x1c/0x30
 [&lt;ffffffff9c82d625&gt;] do_softirq+0x65/0xa0
 [&lt;ffffffff9c89ac85&gt;] irq_exit+0x105/0x110
 [&lt;ffffffff9cf2d0a8&gt;] smp_apic_timer_interrupt+0x48/0x60
 [&lt;ffffffff9cf297f2&gt;] apic_timer_interrupt+0x162/0x170
 &lt;EOI&gt;
 [&lt;ffffffff9cca5f41&gt;] ? scsi_done+0x21/0x60
 [&lt;ffffffff9cb5ac18&gt;] ? delay_tsc+0x38/0x60
 [&lt;ffffffff9cb5ab5d&gt;] __const_udelay+0x2d/0x30
 [&lt;ffffffffc04effde&gt;] _base_handshake_req_reply_wait+0x8e/0x4a0 [mpt3sas]
 [&lt;ffffffffc04f0b13&gt;] _base_get_ioc_facts+0x123/0x590 [mpt3sas]
 [&lt;ffffffffc04f06c8&gt;] ? _base_diag_reset+0x238/0x340 [mpt3sas]
 [&lt;ffffffffc04f7993&gt;] mpt3sas_base_hard_reset_handler+0x1f3/0x420 [mpt3sas]
 [&lt;ffffffffc05132b9&gt;] _ctl_ioctl_main.isra.12+0x11b9/0x1200 [mpt3sas]
 [&lt;ffffffffc068d585&gt;] ? xfs_file_aio_write+0x155/0x1b0 [xfs]
 [&lt;ffffffff9ca1a4e3&gt;] ? do_sync_write+0x93/0xe0
 [&lt;ffffffffc051337a&gt;] _ctl_ioctl+0x1a/0x20 [mpt3sas]
 [&lt;ffffffff9ca2fe90&gt;] do_vfs_ioctl+0x350/0x560
 [&lt;ffffffff9ca1dec1&gt;] ? __sb_end_write+0x31/0x60
 [&lt;ffffffff9ca30141&gt;] SyS_ioctl+0xa1/0xc0
 [&lt;ffffffff9cf28715&gt;] ? system_call_after_swapgs+0xa2/0x146
 [&lt;ffffffff9cf287d5&gt;] system_call_fastpath+0x1c/0x21
 [&lt;ffffffff9cf28721&gt;] ? system_call_after_swapgs+0xae/0x146
Code: 83 c3 10 4c 89 e2 4c 89 ee e8 8d 21 04 00 48 8b 03 48 85 c0 75 e5 41 f6 44 24 4a 10 74 ad 4c 89 e6 4c 89 ef e8 b2 42 00 00 eb a0 &lt;0f&gt; 0b 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
RIP  [&lt;ffffffff9cb19ec0&gt;] blk_requeue_request+0x90/0xa0
 RSP &lt;ffff903c6b783dc0&gt;

As a part of host reset operation, driver will flushout all IOs outstanding
at driver level with "DID_RESET" result.  To find which are all commands
outstanding at the driver level, driver loops with smid starting from one
to HBA queue depth and calls mpt3sas_scsih_scsi_lookup_get() to get scmd as
shown below

 for (smid = 1; smid &lt;= ioc-&gt;scsiio_depth; smid++) {
                scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
                if (!scmd)
                        continue;

But in mpt3sas_scsih_scsi_lookup_get() function, driver returns some scsi
cmnds which are not outstanding at the driver level (possibly request is
constructed at block layer since QUEUE_FLAG_QUIESCED is not set. Even if
driver uses scsi_block_requests and scsi_unblock_requests, issue still
persists as they will be just blocking further IO from scsi layer and not
from block layer) and these commands are flushed with DID_RESET host bytes
thus resulting into above kernel BUG.

This issue got introduced by commit dbec4c9040ed ("scsi: mpt3sas: lockless
command submission").

To fix this issue, we have modified the mpt3sas_scsih_scsi_lookup_get() to
check for smid equals to zero (note: whenever any scsi cmnd is processing
at the driver level then smid for that scsi cmnd will be non-zero, always
it starts from one) before it returns the scmd pointer to the caller. If
smid is zero then this function returns scmd pointer as NULL and driver
won't flushout those scsi cmnds at driver level with DID_RESET host byte
thus this issue will not be observed.

[mkp: amended with updated fix from Sreekanth]

Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Fixes: dbec4c9040ed ("scsi: mpt3sas: lockless command submission")
Cc: stable@vger.kernel.org # v4.16+
Reviewed-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix stalled relogin</title>
<updated>2018-09-05T07:29:51+00:00</updated>
<author>
<name>Himanshu Madhani</name>
<email>himanshu.madhani@cavium.com</email>
</author>
<published>2018-08-02T20:16:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=306f625c2231b85b5c9bfcf9da964a6939ed9c6f'/>
<id>306f625c2231b85b5c9bfcf9da964a6939ed9c6f</id>
<content type='text'>
commit 15b6c3c9568765f0717b2dd3aa67a5f7eadd9734 upstream.

This patch sets and clears FCF_ASYNC_{SENT|ACTIVE} flags to prevent
stalling of relogin attempt. Once flag are correctly set/cleared, relogin
timer can retry relogin attempt for driver to continue login.

Fixes: fa83e65885b9 ("scsi: qla2xxx: ensure async flags are reset correctly")
Cc: stable@vger.kernel.org #4.17
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 15b6c3c9568765f0717b2dd3aa67a5f7eadd9734 upstream.

This patch sets and clears FCF_ASYNC_{SENT|ACTIVE} flags to prevent
stalling of relogin attempt. Once flag are correctly set/cleared, relogin
timer can retry relogin attempt for driver to continue login.

Fixes: fa83e65885b9 ("scsi: qla2xxx: ensure async flags are reset correctly")
Cc: stable@vger.kernel.org #4.17
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: libsas: dynamically allocate and free ata host</title>
<updated>2018-09-05T07:29:40+00:00</updated>
<author>
<name>Jason Yan</name>
<email>yanaijie@huawei.com</email>
</author>
<published>2018-05-10T03:05:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84342771f595b576a2d64775c0fd88d3bb95138e'/>
<id>84342771f595b576a2d64775c0fd88d3bb95138e</id>
<content type='text'>
commit 2fa4a32613c9182b00e46872755b0662374424a7 upstream.

Commit 2623c7a5f2 ("libata: add refcounting to ata_host") v4.17+ introduced
refcounting to ata_host and will increase or decrease the refcount when
adding or deleting transport ATA port.

Now the ata host for libsas is embedded in domain_device, and the -&gt;kref
member is not initialized. Afer we add ata transport class, ata_host_get()
will be called when adding transport ATA port and a warning will be
triggered as below:

refcount_t: increment on 0; use-after-free.
WARNING: CPU: 2 PID: 103 at
lib/refcount.c:153 refcount_inc+0x40/0x48 ......  Call trace:
 refcount_inc+0x40/0x48
 ata_host_get+0x10/0x18
 ata_tport_add+0x40/0x120
 ata_sas_tport_add+0xc/0x14
 sas_ata_init+0x7c/0xc8
 sas_discover_domain+0x380/0x53c
 process_one_work+0x12c/0x288
 worker_thread+0x58/0x3f0
 kthread+0xfc/0x128
 ret_from_fork+0x10/0x18

And also when removing transport ATA port ata_host_put() will be called and
another similar warning will be triggered. If the refcount decreased to
zero, the ata host will be freed. But this ata host is only part of
domain_device, it cannot be freed directly.

So we have to change this embedded static ata host to a dynamically
allocated ata host and initialize the -&gt;kref member. To use ata_host_get()
and ata_host_put() in libsas, we need to move the declaration of these
functions to the public libata.h and export them.

Fixes: b6240a4df018 ("scsi: libsas: add transport class for ATA devices")
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
CC: Taras Kondratiuk &lt;takondra@cisco.com&gt;
CC: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2fa4a32613c9182b00e46872755b0662374424a7 upstream.

Commit 2623c7a5f2 ("libata: add refcounting to ata_host") v4.17+ introduced
refcounting to ata_host and will increase or decrease the refcount when
adding or deleting transport ATA port.

Now the ata host for libsas is embedded in domain_device, and the -&gt;kref
member is not initialized. Afer we add ata transport class, ata_host_get()
will be called when adding transport ATA port and a warning will be
triggered as below:

refcount_t: increment on 0; use-after-free.
WARNING: CPU: 2 PID: 103 at
lib/refcount.c:153 refcount_inc+0x40/0x48 ......  Call trace:
 refcount_inc+0x40/0x48
 ata_host_get+0x10/0x18
 ata_tport_add+0x40/0x120
 ata_sas_tport_add+0xc/0x14
 sas_ata_init+0x7c/0xc8
 sas_discover_domain+0x380/0x53c
 process_one_work+0x12c/0x288
 worker_thread+0x58/0x3f0
 kthread+0xfc/0x128
 ret_from_fork+0x10/0x18

And also when removing transport ATA port ata_host_put() will be called and
another similar warning will be triggered. If the refcount decreased to
zero, the ata host will be freed. But this ata host is only part of
domain_device, it cannot be freed directly.

So we have to change this embedded static ata host to a dynamically
allocated ata host and initialize the -&gt;kref member. To use ata_host_get()
and ata_host_put() in libsas, we need to move the declaration of these
functions to the public libata.h and export them.

Fixes: b6240a4df018 ("scsi: libsas: add transport class for ATA devices")
Signed-off-by: Jason Yan &lt;yanaijie@huawei.com&gt;
CC: John Garry &lt;john.garry@huawei.com&gt;
CC: Taras Kondratiuk &lt;takondra@cisco.com&gt;
CC: Tejun Heo &lt;tj@kernel.org&gt;
Acked-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2018-08-12T19:52:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-08-12T19:52:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=921195d3568cb0e4f16efe456b663ae047b075fa'/>
<id>921195d3568cb0e4f16efe456b663ae047b075fa</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:
 "Eight fixes.

  The most important one is the mpt3sas fix which makes the driver work
  again on big endian systems. The rest are mostly minor error path or
  checker issues and the vmw_scsi one fixes a performance problem"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: vmw_pvscsi: Return DID_RESET for status SAM_STAT_COMMAND_TERMINATED
  scsi: sr: Avoid that opening a CD-ROM hangs with runtime power management enabled
  scsi: mpt3sas: Swap I/O memory read value back to cpu endianness
  scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO
  scsi: fcoe: drop frames in ELS LOGO error path
  scsi: fcoe: fix use-after-free in fcoe_ctlr_els_send
  scsi: qedi: Fix a potential buffer overflow
  scsi: qla2xxx: Fix memory leak for allocating abort IOCB
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI fixes from James Bottomley:
 "Eight fixes.

  The most important one is the mpt3sas fix which makes the driver work
  again on big endian systems. The rest are mostly minor error path or
  checker issues and the vmw_scsi one fixes a performance problem"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: vmw_pvscsi: Return DID_RESET for status SAM_STAT_COMMAND_TERMINATED
  scsi: sr: Avoid that opening a CD-ROM hangs with runtime power management enabled
  scsi: mpt3sas: Swap I/O memory read value back to cpu endianness
  scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO
  scsi: fcoe: drop frames in ELS LOGO error path
  scsi: fcoe: fix use-after-free in fcoe_ctlr_els_send
  scsi: qedi: Fix a potential buffer overflow
  scsi: qla2xxx: Fix memory leak for allocating abort IOCB
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: vmw_pvscsi: Return DID_RESET for status SAM_STAT_COMMAND_TERMINATED</title>
<updated>2018-08-03T17:56:22+00:00</updated>
<author>
<name>Jim Gill</name>
<email>jgill@vmware.com</email>
</author>
<published>2018-08-02T21:13:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e95153b64d03c2b6e8d62e51bdcc33fcad6e0856'/>
<id>e95153b64d03c2b6e8d62e51bdcc33fcad6e0856</id>
<content type='text'>
Commands that are reset are returned with status
SAM_STAT_COMMAND_TERMINATED. PVSCSI currently returns DID_OK |
SAM_STAT_COMMAND_TERMINATED which fails the command. Instead, set hostbyte
to DID_RESET to allow upper layers to retry.

Tested by copying a large file between two pvscsi disks on same adapter
while performing a bus reset at 1-second intervals. Before fix, commands
sometimes fail with DID_OK. After fix, commands observed to fail with
DID_RESET.

Signed-off-by: Jim Gill &lt;jgill@vmware.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commands that are reset are returned with status
SAM_STAT_COMMAND_TERMINATED. PVSCSI currently returns DID_OK |
SAM_STAT_COMMAND_TERMINATED which fails the command. Instead, set hostbyte
to DID_RESET to allow upper layers to retry.

Tested by copying a large file between two pvscsi disks on same adapter
while performing a bus reset at 1-second intervals. Before fix, commands
sometimes fail with DID_OK. After fix, commands observed to fail with
DID_RESET.

Signed-off-by: Jim Gill &lt;jgill@vmware.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: sr: Avoid that opening a CD-ROM hangs with runtime power management enabled</title>
<updated>2018-08-03T17:53:51+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@wdc.com</email>
</author>
<published>2018-08-02T17:44:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1214fd7b497400d200e3f4e64e2338b303a20949'/>
<id>1214fd7b497400d200e3f4e64e2338b303a20949</id>
<content type='text'>
Surround scsi_execute() calls with scsi_autopm_get_device() and
scsi_autopm_put_device(). Note: removing sr_mutex protection from the
scsi_cd_get() and scsi_cd_put() calls is safe because the purpose of
sr_mutex is to serialize cdrom_*() calls.

This patch avoids that complaints similar to the following appear in the
kernel log if runtime power management is enabled:

INFO: task systemd-udevd:650 blocked for more than 120 seconds.
     Not tainted 4.18.0-rc7-dbg+ #1
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-udevd   D28176   650    513 0x00000104
Call Trace:
__schedule+0x444/0xfe0
schedule+0x4e/0xe0
schedule_preempt_disabled+0x18/0x30
__mutex_lock+0x41c/0xc70
mutex_lock_nested+0x1b/0x20
__blkdev_get+0x106/0x970
blkdev_get+0x22c/0x5a0
blkdev_open+0xe9/0x100
do_dentry_open.isra.19+0x33e/0x570
vfs_open+0x7c/0xd0
path_openat+0x6e3/0x1120
do_filp_open+0x11c/0x1c0
do_sys_open+0x208/0x2d0
__x64_sys_openat+0x59/0x70
do_syscall_64+0x77/0x230
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Cc: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Surround scsi_execute() calls with scsi_autopm_get_device() and
scsi_autopm_put_device(). Note: removing sr_mutex protection from the
scsi_cd_get() and scsi_cd_put() calls is safe because the purpose of
sr_mutex is to serialize cdrom_*() calls.

This patch avoids that complaints similar to the following appear in the
kernel log if runtime power management is enabled:

INFO: task systemd-udevd:650 blocked for more than 120 seconds.
     Not tainted 4.18.0-rc7-dbg+ #1
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-udevd   D28176   650    513 0x00000104
Call Trace:
__schedule+0x444/0xfe0
schedule+0x4e/0xe0
schedule_preempt_disabled+0x18/0x30
__mutex_lock+0x41c/0xc70
mutex_lock_nested+0x1b/0x20
__blkdev_get+0x106/0x970
blkdev_get+0x22c/0x5a0
blkdev_open+0xe9/0x100
do_dentry_open.isra.19+0x33e/0x570
vfs_open+0x7c/0xd0
path_openat+0x6e3/0x1120
do_filp_open+0x11c/0x1c0
do_sys_open+0x208/0x2d0
__x64_sys_openat+0x59/0x70
do_syscall_64+0x77/0x230
entry_SYSCALL_64_after_hwframe+0x49/0xbe

Signed-off-by: Bart Van Assche &lt;bart.vanassche@wdc.com&gt;
Cc: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Cc: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: mpt3sas: Swap I/O memory read value back to cpu endianness</title>
<updated>2018-08-03T17:52:23+00:00</updated>
<author>
<name>Sreekanth Reddy</name>
<email>sreekanth.reddy@broadcom.com</email>
</author>
<published>2018-07-31T05:36:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=09c2f95ad404bc6e9995f5bce04ae85d0fffc534'/>
<id>09c2f95ad404bc6e9995f5bce04ae85d0fffc534</id>
<content type='text'>
Swap the I/O memory read value back to cpu endianness before storing it in
a data structures which are defined in the MPI headers where u8 components
are not defined in the endianness order.

In this area from day one mpt3sas driver is using le32_to_cpu() &amp;
cpu_to_le32() APIs. But in commit cf6bf9710c
(mpt3sas: Bug fix for big endian systems) we have removed these APIs
before reading I/O memory which we should haven't done it. So
in this patch I am correcting it by adding these APIs back
before accessing I/O memory.

Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Swap the I/O memory read value back to cpu endianness before storing it in
a data structures which are defined in the MPI headers where u8 components
are not defined in the endianness order.

In this area from day one mpt3sas driver is using le32_to_cpu() &amp;
cpu_to_le32() APIs. But in commit cf6bf9710c
(mpt3sas: Bug fix for big endian systems) we have removed these APIs
before reading I/O memory which we should haven't done it. So
in this patch I am correcting it by adding these APIs back
before accessing I/O memory.

Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO</title>
<updated>2018-08-02T19:30:03+00:00</updated>
<author>
<name>Johannes Thumshirn</name>
<email>jthumshirn@suse.de</email>
</author>
<published>2018-07-31T13:46:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1550ec458e0cf1a40a170ab1f4c46e3f52860f65'/>
<id>1550ec458e0cf1a40a170ab1f4c46e3f52860f65</id>
<content type='text'>
When receiving a LOGO request we forget to clear the FC_RP_STARTED flag
before starting the rport delete routine.

As the started flag was not cleared, we're not deleting the rport but
waiting for a restart and thus are keeping the reference count of the rdata
object at 1.

This leads to the following kmemleak report:
unreferenced object 0xffff88006542aa00 (size 512):
  comm "kworker/0:2", pid 24, jiffies 4294899222 (age 226.880s)
  hex dump (first 32 bytes):
    68 96 fe 65 00 88 ff ff 00 00 00 00 00 00 00 00  h..e............
    01 00 00 00 08 00 00 00 02 c5 45 24 ac b8 00 10  ..........E$....
  backtrace:
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_vn_add.isra.5+0x7f/0x770 [libfcoe]
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_vn_recv+0x12af/0x27f0 [libfcoe]
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_recv_work+0xd01/0x32f0 [libfcoe]
    [&lt;(____ptrval____)&gt;] process_one_work+0x7ff/0x1420
    [&lt;(____ptrval____)&gt;] worker_thread+0x87/0xef0
    [&lt;(____ptrval____)&gt;] kthread+0x2db/0x390
    [&lt;(____ptrval____)&gt;] ret_from_fork+0x35/0x40
    [&lt;(____ptrval____)&gt;] 0xffffffffffffffff

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reported-by: ard &lt;ard@kwaak.net&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When receiving a LOGO request we forget to clear the FC_RP_STARTED flag
before starting the rport delete routine.

As the started flag was not cleared, we're not deleting the rport but
waiting for a restart and thus are keeping the reference count of the rdata
object at 1.

This leads to the following kmemleak report:
unreferenced object 0xffff88006542aa00 (size 512):
  comm "kworker/0:2", pid 24, jiffies 4294899222 (age 226.880s)
  hex dump (first 32 bytes):
    68 96 fe 65 00 88 ff ff 00 00 00 00 00 00 00 00  h..e............
    01 00 00 00 08 00 00 00 02 c5 45 24 ac b8 00 10  ..........E$....
  backtrace:
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_vn_add.isra.5+0x7f/0x770 [libfcoe]
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_vn_recv+0x12af/0x27f0 [libfcoe]
    [&lt;(____ptrval____)&gt;] fcoe_ctlr_recv_work+0xd01/0x32f0 [libfcoe]
    [&lt;(____ptrval____)&gt;] process_one_work+0x7ff/0x1420
    [&lt;(____ptrval____)&gt;] worker_thread+0x87/0xef0
    [&lt;(____ptrval____)&gt;] kthread+0x2db/0x390
    [&lt;(____ptrval____)&gt;] ret_from_fork+0x35/0x40
    [&lt;(____ptrval____)&gt;] 0xffffffffffffffff

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reported-by: ard &lt;ard@kwaak.net&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
