<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/scsi/libsas, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/scsi/libsas?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/scsi/libsas?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-10-07T19:33:18Z</updated>
<entry>
<title>Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2022-10-07T19:33:18Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-10-07T19:33:18Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=62e6e5940c0c09433efa52d0fa9a11623a4704b2'/>
<id>urn:sha1:62e6e5940c0c09433efa52d0fa9a11623a4704b2</id>
<content type='text'>
Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (qla2xxx, lpfc, ufs, hisi_sas, mpi3mr,
  mpt3sas, target). The biggest change (from my biased viewpoint) being
  that the mpi3mr now attached to the SAS transport class, making it the
  first fusion type device to do so.

  Beyond the usual bug fixing and security class reworks, there aren't a
  huge number of core changes"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (141 commits)
  scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()
  scsi: mpi3mr: Remove unnecessary cast
  scsi: stex: Properly zero out the passthrough command structure
  scsi: mpi3mr: Update driver version to 8.2.0.3.0
  scsi: mpi3mr: Fix scheduling while atomic type bug
  scsi: mpi3mr: Scan the devices during resume time
  scsi: mpi3mr: Free enclosure objects during driver unload
  scsi: mpi3mr: Handle 0xF003 Fault Code
  scsi: mpi3mr: Graceful handling of surprise removal of PCIe HBA
  scsi: mpi3mr: Schedule IRQ kthreads only on non-RT kernels
  scsi: mpi3mr: Support new power management framework
  scsi: mpi3mr: Update mpi3 header files
  scsi: mpt3sas: Revert "scsi: mpt3sas: Fix ioc-&gt;base_readl() use"
  scsi: mpt3sas: Revert "scsi: mpt3sas: Fix writel() use"
  scsi: wd33c93: Remove dead code related to the long-gone config WD33C93_PIO
  scsi: core: Add I/O timeout count for SCSI device
  scsi: qedf: Populate sysfs attributes for vport
  scsi: pm8001: Replace one-element array with flexible-array member
  scsi: 3w-xxxx: Replace one-element array with flexible-array member
  scsi: hptiop: Replace one-element array with flexible-array member in struct hpt_iop_request_ioctl_command()
  ...
</content>
</entry>
<entry>
<title>ata: libata-sata: Fix device queue depth control</title>
<updated>2022-09-28T11:47:31Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@opensource.wdc.com</email>
</author>
<published>2022-09-24T06:18:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=141f3d6256e58103ece1c3dd2835e871f1dde240'/>
<id>urn:sha1:141f3d6256e58103ece1c3dd2835e871f1dde240</id>
<content type='text'>
The function __ata_change_queue_depth() uses the helper
ata_scsi_find_dev() to get the ata_device structure of a scsi device and
set that device maximum queue depth. However, when the ata device is
managed by libsas, ata_scsi_find_dev() returns NULL, turning
__ata_change_queue_depth() into a nop, which prevents the user from
setting the maximum queue depth of ATA devices used with libsas based
HBAs.

Fix this by renaming __ata_change_queue_depth() to
ata_change_queue_depth() and adding a pointer to the ata_device
structure of the target device as argument. This pointer is provided by
ata_scsi_change_queue_depth() using ata_scsi_find_dev() in the case of
a libata managed device and by sas_change_queue_depth() using
sas_to_ata_dev() in the case of a libsas managed ata device.

Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Tested-by: John Garry &lt;john.garry@huawei.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()</title>
<updated>2022-09-25T16:56:07Z</updated>
<author>
<name>Duoming Zhou</name>
<email>duoming@zju.edu.cn</email>
</author>
<published>2022-09-20T14:42:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=46ba53c30666717cb06c2b3c5d896301cd00d0c0'/>
<id>urn:sha1:46ba53c30666717cb06c2b3c5d896301cd00d0c0</id>
<content type='text'>
When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete "slow_task-&gt;timer". However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:

      (thread 1)               |        (thread 2)
smp_execute_task_sg()          | sas_task_internal_timedout()
 ...                           |
 del_timer()                   |
 ...                           |  ...
 sas_free_task(task)           |
  kfree(task-&gt;slow_task) //FREE|
                               |  task-&gt;slow_task-&gt;... //USE

Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the "task-&gt;slow_task" is
deallocated.

Link: https://lore.kernel.org/r/20220920144213.10536-1-duoming@zju.edu.cn
Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver")
Reviewed-by: Jason Yan &lt;yanaijie@huawei.com&gt;
Signed-off-by: Duoming Zhou &lt;duoming@zju.edu.cn&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Resume SAS host for phy reset or enable via sysfs</title>
<updated>2022-07-19T03:04:12Z</updated>
<author>
<name>Xiang Chen</name>
<email>chenxiang66@hisilicon.com</email>
</author>
<published>2022-07-14T18:23:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1e82e4627a795aa33af0309c8f526df09abad188'/>
<id>urn:sha1:1e82e4627a795aa33af0309c8f526df09abad188</id>
<content type='text'>
Currently if a phy reset or enable phy is issued via sysfs when controller
is suspended, those operations will be ignored as SAS_HA_REGISTERED is
cleared. If RPM is enabled then we may aggressively suspend automatically.
In this case it may be difficult to enable or reset a phy via sysfs, so
resume the host in these scenarios.

Link: https://lore.kernel.org/r/1657823002-139010-6-git-send-email-john.garry@huawei.com
Signed-off-by: Xiang Chen &lt;chenxiang66@hisilicon.com&gt;
Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Introduce struct smp_rps_resp</title>
<updated>2022-06-10T17:08:06Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@opensource.wdc.com</email>
</author>
<published>2022-06-09T02:24:56Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3dafe0648ddd9c40666069e90b8a8a6162c452aa'/>
<id>urn:sha1:3dafe0648ddd9c40666069e90b8a8a6162c452aa</id>
<content type='text'>
Similarly to sas report general and discovery responses, define the
structure struct smp_rps_resp to handle SATA PHY report responses using a
structure with a size that is exactly equal to the sas defined response
size.

With this change, struct smp_resp becomes unused and is removed.

Link: https://lore.kernel.org/r/20220609022456.409087-4-damien.lemoal@opensource.wdc.com
Reviewed-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Introduce struct smp_rg_resp</title>
<updated>2022-06-10T17:08:06Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@opensource.wdc.com</email>
</author>
<published>2022-06-09T02:24:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=44f2bfe9ef082f76184d4a048c995729d14ec45d'/>
<id>urn:sha1:44f2bfe9ef082f76184d4a048c995729d14ec45d</id>
<content type='text'>
When compiling with gcc 12, several warnings are thrown by gcc when
compiling drivers/scsi/libsas/sas_expander.c, e.g.:

In function ‘sas_get_ex_change_count’,
    inlined from ‘sas_find_bcast_dev’ at
    drivers/scsi/libsas/sas_expander.c:1816:8:
drivers/scsi/libsas/sas_expander.c:1781:20: warning: array subscript
‘struct smp_resp[0]’ is partly outside array bounds of ‘unsigned
char[32]’ [-Warray-bounds]
 1781 |         if (rg_resp-&gt;result != SMP_RESP_FUNC_ACC) {
      |             ~~~~~~~^~~~~~~~

This is due to the use of the struct smp_resp to aggregate all possible
response types using a union but allocating a response buffer with a size
exactly equal to the size of the response type needed. This leads to access
to fields of struct smp_resp from an allocated memory area that is smaller
than the size of struct smp_resp.

Fix this by defining struct smp_rg_resp for sas report general responses.

Link: https://lore.kernel.org/r/20220609022456.409087-3-damien.lemoal@opensource.wdc.com
Reviewed-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Introduce struct smp_disc_resp</title>
<updated>2022-06-10T17:08:06Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@opensource.wdc.com</email>
</author>
<published>2022-06-09T02:24:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c3752f44604f3bc4f3ce6e169fa32d16943ff70b'/>
<id>urn:sha1:c3752f44604f3bc4f3ce6e169fa32d16943ff70b</id>
<content type='text'>
When compiling with gcc 12, several warnings are thrown by gcc when
compiling drivers/scsi/libsas/sas_expander.c, e.g.:

In function ‘sas_get_phy_change_count’,
    inlined from ‘sas_find_bcast_phy.constprop’ at
drivers/scsi/libsas/sas_expander.c:1737:9:
drivers/scsi/libsas/sas_expander.c:1697:39: warning: array subscript
‘struct smp_resp[0]’ is partly outside array bounds of ‘unsigned
char[56]’ [-Warray-bounds]
 1697 |                 *pcc = disc_resp-&gt;disc.change_count;
      |                        ~~~~~~~~~~~~~~~^~~~~~~~~~~~~

This is due to the use of the struct smp_resp to aggregate all possible
response types using a union but allocating a response buffer with a size
exactly equal to the size of the response type needed. This leads to access
to fields of struct smp_resp from an allocated memory area that is smaller
than the size of struct smp_resp.

Fix this by defining struct smp_disc_resp for sas discovery operations.
Since this structure and the generic struct smp_resp are identical for
the little endian and big endian archs, move the definition of these
structures at the end of include/scsi/sas.h to avoid repeating their
definition.

Link: https://lore.kernel.org/r/20220609022456.409087-2-damien.lemoal@opensource.wdc.com
Reviewed-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Refactor sas_ata_hard_reset()</title>
<updated>2022-05-20T00:16:25Z</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2022-05-12T11:15:32Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=057e5fc03369f8f2ed9b2ca884754b1d80b83620'/>
<id>urn:sha1:057e5fc03369f8f2ed9b2ca884754b1d80b83620</id>
<content type='text'>
Create function sas_ata_wait_after_reset() from sas_ata_hard_reset() as
some LLDDs may want to check for a remote ATA phy is up after reset.

Link: https://lore.kernel.org/r/1652354134-171343-2-git-send-email-john.garry@huawei.com
Tested-by: Yihang Li &lt;liyihang6@hisilicon.com&gt;
Reviewed-by: Xiang Chen &lt;chenxiang66@hisilicon.com&gt;
Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: hisi_sas: Use libsas internal abort support</title>
<updated>2022-03-15T03:33:24Z</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2022-03-11T12:23:52Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=095478a6e5bf590f2bbf341569eb25173c9c5f32'/>
<id>urn:sha1:095478a6e5bf590f2bbf341569eb25173c9c5f32</id>
<content type='text'>
Use the common libsas internal abort functionality.

In addition, this driver has special handling for internal abort timeouts -
specifically whether to reset the controller in that instance, so extend
the API for that.

Timeout is now increased to 20 * Hz from 6 * Hz.

We also retry for failure now, but this should not make a difference.

Link: https://lore.kernel.org/r/1647001432-239276-5-git-send-email-john.garry@huawei.com
Tested-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Acked-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
<entry>
<title>scsi: libsas: Add sas_execute_internal_abort_dev()</title>
<updated>2022-03-15T03:33:23Z</updated>
<author>
<name>John Garry</name>
<email>john.garry@huawei.com</email>
</author>
<published>2022-03-11T12:23:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6a91c3e31578979a93b500efc76af4d3499f75ad'/>
<id>urn:sha1:6a91c3e31578979a93b500efc76af4d3499f75ad</id>
<content type='text'>
Add support for a "device" variant of internal abort, which will abort all
pending I/Os for a specific device.

Link: https://lore.kernel.org/r/1647001432-239276-3-git-send-email-john.garry@huawei.com
Tested-by: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Acked-by: Jack Wang &lt;jinpu.wang@ionos.com&gt;
Signed-off-by: John Garry &lt;john.garry@huawei.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</content>
</entry>
</feed>
