<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/scsi, branch v6.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-04-15T17:49:47Z</updated>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2023-04-15T17:49:47Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-15T17:49:47Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9772f14f557de9d4056212c84a0a4f64b7b09f31'/>
<id>urn:sha1:9772f14f557de9d4056212c84a0a4f64b7b09f31</id>
<content type='text'>
Pull SCSI fix from James Bottomley:
 "One small fix to SCSI Enclosure Services to fix a regression caused by
  another recent fix"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: ses: Handle enclosure with just a primary component gracefully
</content>
</entry>
<entry>
<title>scsi: ses: Handle enclosure with just a primary component gracefully</title>
<updated>2023-04-12T01:11:39Z</updated>
<author>
<name>Jiri Kosina</name>
<email>jkosina@suse.cz</email>
</author>
<published>2023-04-04T19:23:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c8e22b7a1694bb8d025ea636816472739d859145'/>
<id>urn:sha1:c8e22b7a1694bb8d025ea636816472739d859145</id>
<content type='text'>
This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure
has no components") and introduces proper handling of case where there are
no detected secondary components, but primary component (enumerated in
num_enclosures) does exist. That fix was originally proposed by Ding Hui
&lt;dinghui@sangfor.com.cn&gt;.

Completely ignoring devices that have one primary enclosure and no
secondary one results in ses_intf_add() bailing completely

	scsi 2:0:0:254: enclosure has no enumerated components
        scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such

even on valid configurations with 1 primary and 0 secondary enclosures as
below:

	# sg_ses /dev/sg0
	  3PARdata  SES               3321
	Supported diagnostic pages:
	  Supported Diagnostic Pages [sdp] [0x0]
	  Configuration (SES) [cf] [0x1]
	  Short Enclosure Status (SES) [ses] [0x8]
	# sg_ses -p cf /dev/sg0
	  3PARdata  SES               3321
	Configuration diagnostic page:
	  number of secondary subenclosures: 0
	  generation code: 0x0
	  enclosure descriptor list
	    Subenclosure identifier: 0 [primary]
	      relative ES process id: 0, number of ES processes: 1
	      number of type descriptor headers: 1
	      enclosure logical identifier (hex): 20000002ac02068d
	      enclosure vendor: 3PARdata  product: VV                rev: 3321
	  type descriptor header and text list
	    Element type: Unspecified, subenclosure id: 0
	      number of possible elements: 1

The changelog for the original fix follows

=====
We can get a crash when disconnecting the iSCSI session,
the call trace like this:

  [ffff00002a00fb70] kfree at ffff00000830e224
  [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4
  [ffff00002a00fbd0] device_del at ffff0000086b6a98
  [ffff00002a00fc50] device_unregister at ffff0000086b6d58
  [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c
  [ffff00002a00fca0] scsi_remove_device at ffff000008706134
  [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4
  [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0
  [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4
  [ffff00002a00fdb0] process_one_work at ffff00000810f35c
  [ffff00002a00fe00] worker_thread at ffff00000810f648
  [ffff00002a00fe70] kthread at ffff000008116e98

In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,
but not saved in edev-&gt;component[i].scratch

In this situation, edev-&gt;component[0].scratch is an invalid pointer,
when kfree it in ses_intf_remove_enclosure, a crash like above would happen
The call trace also could be other random cases when kfree cannot catch
the invalid pointer

We should not use edev-&gt;component[] array when the components count is 0
We also need check index when use edev-&gt;component[] array in
ses_enclosure_data_process
=====

Reported-by: Michal Kolar &lt;mich.k@seznam.cz&gt;
Originally-by: Ding Hui &lt;dinghui@sangfor.com.cn&gt;
Cc: stable@vger.kernel.org
Fixes: 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components")
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2304042122270.29760@cbobk.fhfr.pm
Tested-by: Michal Kolar &lt;mich.k@seznam.cz&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2023-04-08T18:57:05Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-04-08T18:57:05Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a79d5c76f705de81cb6b55ad279dde9759da06d2'/>
<id>urn:sha1:a79d5c76f705de81cb6b55ad279dde9759da06d2</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:
 "Four small fixes, all in drivers. They're all one or two lines except
  for the ufs one, but that's a simple revert of a previous feature"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()
  scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()
  scsi: mpi3mr: Handle soft reset in progress fault code (0xF002)
  scsi: Revert "scsi: ufs: core: Initialize devfreq synchronously"
</content>
</entry>
<entry>
<title>scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()</title>
<updated>2023-04-03T01:44:27Z</updated>
<author>
<name>Zhong Jinghua</name>
<email>zhongjinghua@huawei.com</email>
</author>
<published>2023-03-29T07:17:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=48b19b79cfa37b1e50da3b5a8af529f994c08901'/>
<id>urn:sha1:48b19b79cfa37b1e50da3b5a8af529f994c08901</id>
<content type='text'>
The validity of sock should be checked before assignment to avoid incorrect
values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref
while calling getpeername()") introduced this change which may lead to
inconsistent values of tcp_sw_conn-&gt;sendpage and conn-&gt;datadgst_en.

Fix the issue by moving the position of the assignment.

Fixes: 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()")
Signed-off-by: Zhong Jinghua &lt;zhongjinghua@huawei.com&gt;
Link: https://lore.kernel.org/r/20230329071739.2175268-1-zhongjinghua@huaweicloud.com
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()</title>
<updated>2023-04-03T01:40:19Z</updated>
<author>
<name>Li Zetao</name>
<email>lizetao1@huawei.com</email>
</author>
<published>2023-03-25T11:00:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=85ade4010e13ef152ea925c74d94253db92e5428'/>
<id>urn:sha1:85ade4010e13ef152ea925c74d94253db92e5428</id>
<content type='text'>
There is a memory leak reported by kmemleak:

  unreferenced object 0xffffc900003f0000 (size 12288):
    comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [&lt;00000000629261a8&gt;] __vmalloc_node_range+0xe56/0x1110
      [&lt;0000000001906886&gt;] __vmalloc_node+0xbd/0x150
      [&lt;000000005bb4dc34&gt;] vmalloc+0x25/0x30
      [&lt;00000000a2dc1194&gt;] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]
      [&lt;0000000062b14b47&gt;] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]
      [&lt;00000000641ccc04&gt;] local_pci_probe+0xeb/0x1a0

The root cause is traced to an error-handling path in qla2x00_probe_one()
when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is
used to record the port information and it is allocated in
qla2x00_create_host(). However, it is not released in the error handling
path "probe_failed".

Fix this by freeing the memory of "scan.l" when an error occurs in the
adapter initialization process.

Fixes: a4239945b8ad ("scsi: qla2xxx: Add switch command to simplify fabric discovery")
Signed-off-by: Li Zetao &lt;lizetao1@huawei.com&gt;
Link: https://lore.kernel.org/r/20230325110004.363898-1-lizetao1@huawei.com
Reviewed-by: Himanshu Madhani &lt;himanshu.madhani@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: mpi3mr: Handle soft reset in progress fault code (0xF002)</title>
<updated>2023-04-03T01:22:28Z</updated>
<author>
<name>Ranjan Kumar</name>
<email>ranjan.kumar@broadcom.com</email>
</author>
<published>2023-03-31T12:23:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a3d27dfdcfc27ac3f46de5391bb6d24f04af7941'/>
<id>urn:sha1:a3d27dfdcfc27ac3f46de5391bb6d24f04af7941</id>
<content type='text'>
The driver is exiting from the fault watchdog thread if it sees the 0xF002
(Soft reset in progress) fault code.

If the driver initiates the soft reset, then the driver restarts the
watchdog at the end of the soft reset completion.  However, if the soft
reset is initiated by the firmware asynchronously, then the driver will
never restart the watchdog and never re-initialize the controller after the
asynchronous soft reset completion.

Signed-off-by: Ranjan Kumar &lt;ranjan.kumar@broadcom.com&gt;
Link: https://lore.kernel.org/r/20230331122317.11391-1-ranjan.kumar@broadcom.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2023-03-30T22:52:45Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-03-30T22:52:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=10f76dc3abb4d8fbc2cee7a63fda22e8b08628b2'/>
<id>urn:sha1:10f76dc3abb4d8fbc2cee7a63fda22e8b08628b2</id>
<content type='text'>
Pull SCSI fixes from James Bottomley:
 "Four small fixes, three in drivers. The core fix is yet another
  attempt to insulate us from UFS devices' weird behaviour for VPD
  pages"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: mpt3sas: Don't print sense pool info twice
  scsi: core: Improve scsi_vpd_inquiry() checks
  scsi: megaraid_sas: Fix crash after a double completion
  scsi: megaraid_sas: Fix fw_crash_buffer_show()
</content>
</entry>
<entry>
<title>scsi: mpt3sas: Don't print sense pool info twice</title>
<updated>2023-03-25T01:07:42Z</updated>
<author>
<name>Jerry Snitselaar</name>
<email>jsnitsel@redhat.com</email>
</author>
<published>2023-03-24T19:32:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d684a7a26f7d2c7122a4581ac966ed64e88fb29c'/>
<id>urn:sha1:d684a7a26f7d2c7122a4581ac966ed64e88fb29c</id>
<content type='text'>
_base_allocate_sense_dma_pool() already prints out the sense pool
information, so don't print it a second time after calling it in
_base_allocate_memory_pools(). In addition the version in
_base_allocate_memory_pools() was using the wrong size value, sz, which was
last assigned when doing some nvme calculations instead of sense_sz to
determine the pool size in kilobytes.

Cc: Sathya Prakash &lt;sathya.prakash@broadcom.com&gt;
Cc: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Cc: Suganath Prabu Subramani &lt;suganath-prabu.subramani@broadcom.com&gt;
Cc: MPT-FusionLinux.pdl@broadcom.com
Cc: "Martin K. Petersen" &lt;martin.petersen@oracle.com&gt;
Cc: "James E.J. Bottomley" &lt;jejb@linux.ibm.com&gt;
Fixes: 970ac2bb70e7 ("scsi: mpt3sas: Force sense buffer allocations to be within same 4 GB region")
Signed-off-by: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Link: https://lore.kernel.org/r/20230324193204.567932-1-jsnitsel@redhat.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: core: Improve scsi_vpd_inquiry() checks</title>
<updated>2023-03-25T01:01:32Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@opensource.wdc.com</email>
</author>
<published>2023-03-22T02:22:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f0aa59a33d2ac2267d260fe21eaf92500df8e7b4'/>
<id>urn:sha1:f0aa59a33d2ac2267d260fe21eaf92500df8e7b4</id>
<content type='text'>
Some USB-SATA adapters have broken behavior when an unsupported VPD page is
probed: Depending on the VPD page number, a 4-byte header with a valid VPD
page number but with a 0 length is returned. Currently, scsi_vpd_inquiry()
only checks that the page number is valid to determine if the page is
valid, which results in receiving only the 4-byte header for the
non-existent page. This error manifests itself very often with page 0xb9
for the Concurrent Positioning Ranges detection done by sd_read_cpr(),
resulting in the following error message:

sd 0:0:0:0: [sda] Invalid Concurrent Positioning Ranges VPD page

Prevent such misleading error message by adding a check in
scsi_vpd_inquiry() to verify that the page length is not 0.

Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Link: https://lore.kernel.org/r/20230322022211.116327-1-damien.lemoal@opensource.wdc.com
Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: megaraid_sas: Fix crash after a double completion</title>
<updated>2023-03-25T00:58:29Z</updated>
<author>
<name>Tomas Henzl</name>
<email>thenzl@redhat.com</email>
</author>
<published>2023-03-24T15:01:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2309df27111a51734cb9240b4d3c25f2f3c6ab06'/>
<id>urn:sha1:2309df27111a51734cb9240b4d3c25f2f3c6ab06</id>
<content type='text'>
When a physical disk is attached directly "without JBOD MAP support" (see
megasas_get_tm_devhandle()) then there is no real error handling in the
driver.  Return FAILED instead of SUCCESS.

Fixes: 18365b138508 ("megaraid_sas: Task management support")
Signed-off-by: Tomas Henzl &lt;thenzl@redhat.com&gt;
Link: https://lore.kernel.org/r/20230324150134.14696-1-thenzl@redhat.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
</feed>
