<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/scsi/device_handler, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-03-30T10:49:03+00:00</updated>
<entry>
<title>scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()</title>
<updated>2023-03-30T10:49:03+00:00</updated>
<author>
<name>Yu Kuai</name>
<email>yukuai3@huawei.com</email>
</author>
<published>2023-03-15T06:21:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1c55982beb80c7d3c30278fc6cfda8496a31dbe6'/>
<id>urn:sha1:1c55982beb80c7d3c30278fc6cfda8496a31dbe6</id>
<content type='text'>
[ Upstream commit a13faca032acbf2699293587085293bdfaafc8ae ]

If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
freed, which will cause following memleak:

unreferenced object 0xffff88810b2c6980 (size 32):
  comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff  @9$.............
  backtrace:
    [&lt;0000000098f3a26d&gt;] alua_activate+0xb0/0x320
    [&lt;000000003b529641&gt;] scsi_dh_activate+0xb2/0x140
    [&lt;000000007b296db3&gt;] activate_path_work+0xc6/0xe0 [dm_multipath]
    [&lt;000000007adc9ace&gt;] process_one_work+0x3c5/0x730
    [&lt;00000000c457a985&gt;] worker_thread+0x93/0x650
    [&lt;00000000cb80e628&gt;] kthread+0x1ba/0x210
    [&lt;00000000a1e61077&gt;] ret_from_fork+0x22/0x30

Fix the problem by freeing 'qdata' in error path.

Fixes: 625fe857e4fa ("scsi: scsi_dh_alua: Check scsi_device_get() return value")
Signed-off-by: Yu Kuai &lt;yukuai3@huawei.com&gt;
Link: https://lore.kernel.org/r/20230315062154.668812-1-yukuai1@huaweicloud.com
Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi/device_handlers: Use the new blk_opf_t type</title>
<updated>2022-07-14T18:14:32+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2022-07-14T18:07:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c15cbe9a84b05462195102bcead0213eb068c595'/>
<id>urn:sha1:c15cbe9a84b05462195102bcead0213eb068c595</id>
<content type='text'>
Improve static type checking by using the new blk_opf_t type for variables
that represent request flags.

Cc: Hannes Reinecke &lt;hare@suse.com&gt;
Cc: Martin Wilck &lt;mwilck@suse.com&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20220714180729.1065367-43-bvanassche@acm.org
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Properly handle the ALUA transitioning state</title>
<updated>2022-05-02T23:52:13+00:00</updated>
<author>
<name>Brian Bunker</name>
<email>brian@purestorage.com</email>
</author>
<published>2022-05-02T15:09:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6056a92ceb2a7705d61df7ec5370548e96aee258'/>
<id>urn:sha1:6056a92ceb2a7705d61df7ec5370548e96aee258</id>
<content type='text'>
The handling of the ALUA transitioning state is currently broken. When a
target goes into this state, it is expected that the target is allowed to
stay in this state for the implicit transition timeout without a path
failure. The handler has this logic, but it gets skipped currently.

When the target transitions, there is in-flight I/O from the initiator. The
first of these responses from the target will be a unit attention letting
the initiator know that the ALUA state has changed.  The remaining
in-flight I/Os, before the initiator finds out that the portal state has
changed, will return not ready, ALUA state is transitioning. The portal
state will change to SCSI_ACCESS_STATE_TRANSITIONING. This will lead to all
new I/O immediately failing the path unexpectedly. The path failure happens
in less than a second instead of the expected successes until the
transition timer is exceeded.

Allow I/Os to continue while the path is in the ALUA transitioning
state. The handler already takes care of a target that stays in the
transitioning state for too long by changing the state to ALUA state
standby once the transition timeout is exceeded at which point the path
will fail.

Link: https://lore.kernel.org/r/CAHZQxy+4sTPz9+pY3=7VJH+CLUJsDct81KtnR2be8ycN5mhqTg@mail.gmail.com
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Acked-by: Krishna Kant &lt;krishna.kant@purestorage.com&gt;
Acked-by: Seamus Connor &lt;sconnor@purestorage.com&gt;
Signed-off-by: Brian Bunker &lt;brian@purestorage.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_rdac: Avoid crash during rdac_bus_attach()</title>
<updated>2021-07-30T01:58:35+00:00</updated>
<author>
<name>Ye Bin</name>
<email>yebin10@huawei.com</email>
</author>
<published>2021-01-13T06:31:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc546c0c9abb3bb2fb46866b3d1e6ade9695a5f6'/>
<id>urn:sha1:bc546c0c9abb3bb2fb46866b3d1e6ade9695a5f6</id>
<content type='text'>
The following BUG_ON() was observed during RDAC scan:

[595952.944297] kernel BUG at drivers/scsi/device_handler/scsi_dh_rdac.c:427!
[595952.951143] Internal error: Oops - BUG: 0 [#1] SMP
......
[595953.251065] Call trace:
[595953.259054]  check_ownership+0xb0/0x118
[595953.269794]  rdac_bus_attach+0x1f0/0x4b0
[595953.273787]  scsi_dh_handler_attach+0x3c/0xe8
[595953.278211]  scsi_dh_add_device+0xc4/0xe8
[595953.282291]  scsi_sysfs_add_sdev+0x8c/0x2a8
[595953.286544]  scsi_probe_and_add_lun+0x9fc/0xd00
[595953.291142]  __scsi_scan_target+0x598/0x630
[595953.295395]  scsi_scan_target+0x120/0x130
[595953.299481]  fc_user_scan+0x1a0/0x1c0 [scsi_transport_fc]
[595953.304944]  store_scan+0xb0/0x108
[595953.308420]  dev_attr_store+0x44/0x60
[595953.312160]  sysfs_kf_write+0x58/0x80
[595953.315893]  kernfs_fop_write+0xe8/0x1f0
[595953.319888]  __vfs_write+0x60/0x190
[595953.323448]  vfs_write+0xac/0x1c0
[595953.326836]  ksys_write+0x74/0xf0
[595953.330221]  __arm64_sys_write+0x24/0x30

Code is in check_ownership:

	list_for_each_entry_rcu(tmp, &amp;h-&gt;ctlr-&gt;dh_list, node) {
		/* h-&gt;sdev should always be valid */
		BUG_ON(!tmp-&gt;sdev);
		tmp-&gt;sdev-&gt;access_state = access_state;
	}

	rdac_bus_attach
		initialize_controller
			list_add_rcu(&amp;h-&gt;node, &amp;h-&gt;ctlr-&gt;dh_list);
			h-&gt;sdev = sdev;

	rdac_bus_detach
		list_del_rcu(&amp;h-&gt;node);
		h-&gt;sdev = NULL;

Fix the race between rdac_bus_attach() and rdac_bus_detach() where h-&gt;sdev
is NULL when processing the RDAC attach.

Link: https://lore.kernel.org/r/20210113063103.2698953-1-yebin10@huawei.com
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Ye Bin &lt;yebin10@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()</title>
<updated>2021-06-08T01:48:16+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2021-06-03T12:33:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=80927822e8b6be46f488524cd7d5fe683de97fc4'/>
<id>urn:sha1:80927822e8b6be46f488524cd7d5fe683de97fc4</id>
<content type='text'>
The "retval" variable needs to be signed for the error handling to work.

Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda
Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value")
Reviewed-by: Martin Wilck &lt;mwilck@suse.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Check for negative result value</title>
<updated>2021-06-01T02:48:21+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2021-04-27T08:30:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7e26e3ea028740f934477ec01ba586ab033c35aa'/>
<id>urn:sha1:7e26e3ea028740f934477ec01ba586ab033c35aa</id>
<content type='text'>
scsi_execute() will now return a negative error if there was an error prior
to command submission; evaluate that instead if checking for DRIVER_ERROR.

[mkp: build fix]

Link: https://lore.kernel.org/r/20210427083046.31620-6-hare@suse.de
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Retry RTPG on a different path after failure</title>
<updated>2021-05-22T03:06:29+00:00</updated>
<author>
<name>Martin Wilck</name>
<email>mwilck@suse.com</email>
</author>
<published>2021-05-14T15:32:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee8868c5c78f16fb726775741aeab8a233373332'/>
<id>urn:sha1:ee8868c5c78f16fb726775741aeab8a233373332</id>
<content type='text'>
If an RTPG fails, we can't infer anything wrt. the state of the ports in
the port group except that we were unable to reach the one port on which
the RTPG had failed. "offline" is just a secondary port state, which means
that we can't infer the state of any port in the PG from the failure (in
fact, even the failed port might still be in "active/optimized" primary
port access state).

Therefore, when we encounter an RTPG failure, we should retry the RTPG on a
different port. This avoids falsely setting port states to offline for
unreachable ports. To do this, ports on which an RTPG has failed are
temporarily set to "disabled" to avoid repeating the failed I/O on the same
target port. Once the RTPG has either succeeded on one port or failed on
all ports of the PG, the ports are enabled again.

Link: https://lore.kernel.org/r/20210514153214.5626-1-mwilck@suse.com
Signed-off-by: Martin Wilck &lt;mwilck@suse.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: core: Introduce enum scsi_disposition</title>
<updated>2021-04-16T02:44:40+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2021-04-15T22:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8e162f9e7e2da6e823a4984d6aa0523e278babf'/>
<id>urn:sha1:b8e162f9e7e2da6e823a4984d6aa0523e278babf</id>
<content type='text'>
Improve readability of the code in the SCSI core by introducing an
enumeration type for the values used internally that decide how to continue
processing a SCSI command. The eh_*_handler return values have not been
changed because that would involve modifying all SCSI drivers.

The output of the following command has been inspected to verify that no
out-of-range values are assigned to a variable of type enum
scsi_disposition:

KCFLAGS=-Wassign-enum make CC=clang W=1 drivers/scsi/

Link: https://lore.kernel.org/r/20210415220826.29438-6-bvanassche@acm.org
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Johannes Thumshirn &lt;johannes.thumshirn@wdc.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Daniel Wagner &lt;dwagner@suse.de&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Remove check for ASC 24h in alua_rtpg()</title>
<updated>2021-04-06T03:24:18+00:00</updated>
<author>
<name>Ewan D. Milne</name>
<email>emilne@redhat.com</email>
</author>
<published>2021-03-31T20:11:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc3f2b42b70eb1b8576e753e7d0e117bbb674496'/>
<id>urn:sha1:bc3f2b42b70eb1b8576e753e7d0e117bbb674496</id>
<content type='text'>
Some arrays return ILLEGAL_REQUEST with ASC 00h if they don't support the
RTPG extended header so remove the check for INVALID FIELD IN CDB.

Link: https://lore.kernel.org/r/20210331201154.20348-1-emilne@redhat.com
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: scsi_dh_alua: Prevent duplicate pg info print in alua_rtpg()</title>
<updated>2021-04-06T03:20:38+00:00</updated>
<author>
<name>John Pittman</name>
<email>jpittman@redhat.com</email>
</author>
<published>2021-03-31T18:16:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22ec513e705735e32d4b8263c23d20c779639c7e'/>
<id>urn:sha1:22ec513e705735e32d4b8263c23d20c779639c7e</id>
<content type='text'>
Due to the frequency that alua_rtpg() is called, the path group info print
within can print the same info multiple times in the logs, subsequent
prints adding no new information or value.

To reproduce:

    # modprobe scsi_debug vpd_use_hostno=0
    # systemctl start multipathd.service

To fix, check stored values, only printing at alua attach/activate and if
any of the values change.

Link: https://lore.kernel.org/r/20210331181656.5046-1-jpittman@redhat.com
Reviewed-by: David Jeffery &lt;djeffery@redhat.com&gt;
Reviewed-by: Laurence Oberman &lt;loberman@redhat.com&gt;
Signed-off-by: John Pittman &lt;jpittman@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
</feed>
