<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/scsi/scsi_error.c, branch v6.6</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>scsi: sd: Handle read/write CDL timeout failures</title>
<updated>2023-05-22T21:05:19+00:00</updated>
<author>
<name>Niklas Cassel</name>
<email>niklas.cassel@wdc.com</email>
</author>
<published>2023-05-11T01:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=390e2d1a587405a522dc6b433d45648f895a352c'/>
<id>390e2d1a587405a522dc6b433d45648f895a352c</id>
<content type='text'>
Commands using a duration limit descriptor that has limit policies set to a
value other than 0x0 may be failed by the device if one of the limits are
exceeded. For such commands, since the failure is the result of the user
duration limit configuration and workload, the commands should not be
retried and terminated immediately. Furthermore, to allow the user to
differentiate these "soft" failures from hard errors due to hardware
problem, a different error code than EIO should be returned.

There are 2 cases to consider:

(1) The failure is due to a limit policy failing the command with a check
condition sense key, that is, any limit policy other than 0xD.  For this
case, scsi_check_sense() is modified to detect failures with the ABORTED
COMMAND sense key and the COMMAND TIMEOUT BEFORE PROCESSING or COMMAND
TIMEOUT DURING PROCESSING or COMMAND TIMEOUT DURING PROCESSING DUE TO ERROR
RECOVERY additional sense code. For these failures, a SUCCESS disposition
is returned so that scsi_finish_command() is called to terminate the
command.

(2) The failure is due to a limit policy set to 0xD, which result in the
command being terminated with a GOOD status, COMPLETED sense key, and DATA
CURRENTLY UNAVAILABLE additional sense code. To handle this case, the
scsi_check_sense() is modified to return a SUCCESS disposition so that
scsi_finish_command() is called to terminate the command.  In addition,
scsi_decide_disposition() has to be modified to see if a command being
terminated with GOOD status has sense data.  This is as defined in SCSI
Primary Commands - 6 (SPC-6), so all according to spec, even if GOOD status
commands were not checked before.

If scsi_check_sense() detects sense data representing a duration limit,
scsi_check_sense() will set the newly introduced SCSI ML byte
SCSIML_STAT_DL_TIMEOUT. This SCSI ML byte is checked in scsi_noretry_cmd(),
so that a command that failed because of a CDL timeout cannot be
retried. The SCSI ML byte is also checked in scsi_result_to_blk_status() to
complete the command request with the BLK_STS_DURATION_LIMIT status, which
result in the user seeing ETIME errors for the failed commands.

Co-developed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20230511011356.227789-12-nks@flawful.org
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 using a duration limit descriptor that has limit policies set to a
value other than 0x0 may be failed by the device if one of the limits are
exceeded. For such commands, since the failure is the result of the user
duration limit configuration and workload, the commands should not be
retried and terminated immediately. Furthermore, to allow the user to
differentiate these "soft" failures from hard errors due to hardware
problem, a different error code than EIO should be returned.

There are 2 cases to consider:

(1) The failure is due to a limit policy failing the command with a check
condition sense key, that is, any limit policy other than 0xD.  For this
case, scsi_check_sense() is modified to detect failures with the ABORTED
COMMAND sense key and the COMMAND TIMEOUT BEFORE PROCESSING or COMMAND
TIMEOUT DURING PROCESSING or COMMAND TIMEOUT DURING PROCESSING DUE TO ERROR
RECOVERY additional sense code. For these failures, a SUCCESS disposition
is returned so that scsi_finish_command() is called to terminate the
command.

(2) The failure is due to a limit policy set to 0xD, which result in the
command being terminated with a GOOD status, COMPLETED sense key, and DATA
CURRENTLY UNAVAILABLE additional sense code. To handle this case, the
scsi_check_sense() is modified to return a SUCCESS disposition so that
scsi_finish_command() is called to terminate the command.  In addition,
scsi_decide_disposition() has to be modified to see if a command being
terminated with GOOD status has sense data.  This is as defined in SCSI
Primary Commands - 6 (SPC-6), so all according to spec, even if GOOD status
commands were not checked before.

If scsi_check_sense() detects sense data representing a duration limit,
scsi_check_sense() will set the newly introduced SCSI ML byte
SCSIML_STAT_DL_TIMEOUT. This SCSI ML byte is checked in scsi_noretry_cmd(),
so that a command that failed because of a CDL timeout cannot be
retried. The SCSI ML byte is also checked in scsi_result_to_blk_status() to
complete the command request with the BLK_STS_DURATION_LIMIT status, which
result in the user seeing ETIME errors for the failed commands.

Co-developed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20230511011356.227789-12-nks@flawful.org
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: Allow libata to complete successful commands via EH</title>
<updated>2023-05-22T21:05:18+00:00</updated>
<author>
<name>Niklas Cassel</name>
<email>niklas.cassel@wdc.com</email>
</author>
<published>2023-05-11T01:13:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3d848ca1ebc8d8864f25bd461914c93eff82a2d2'/>
<id>3d848ca1ebc8d8864f25bd461914c93eff82a2d2</id>
<content type='text'>
In SCSI, we get the sense data as part of the completion, for ATA however,
we need to fetch the sense data as an extra step. For an aborted ATA
command the sense data is fetched via libata's -&gt;eh_strategy_handler().

For Command Duration Limits policy 0xD:

  The device shall complete the command without error with the additional
  sense code set to DATA CURRENTLY UNAVAILABLE.

In order to handle this policy in libata, we intend to send a successful
command via SCSI EH, and let libata's -&gt;eh_strategy_handler() fetch the
sense data for the good command. This is similar to how we handle an
aborted ATA command, just that we need to read the Successful NCQ Commands
log instead of the NCQ Command Error log.

When we get a SATA completion with successful commands, ATA_SENSE will be
set, indicating that some commands in the completion have sense data.

The sense_valid bitmask in the Sense Data for Successful NCQ Commands log
will inform exactly which commands that had sense data, which might be a
subset of all the commands that was completed in the same completion. (Yet
all will have ATA_SENSE set, since the status is per completion.)

The successful commands that have e.g. a "DATA CURRENTLY UNAVAILABLE" sense
data will have a SCSI ML byte set, so scsi_eh_flush_done_q() will not set
the scmd-&gt;result to DID_TIME_OUT for these commands. However, the
successful commands that did not have sense data, must not get their result
marked as DID_TIME_OUT by SCSI EH.

Add a new flag SCMD_FORCE_EH_SUCCESS, which tells SCSI EH to not mark a
command as DID_TIME_OUT, even if it has scmd-&gt;result == SAM_STAT_GOOD.

This will be used by libata in a subsequent commit.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20230511011356.227789-5-nks@flawful.org
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>
In SCSI, we get the sense data as part of the completion, for ATA however,
we need to fetch the sense data as an extra step. For an aborted ATA
command the sense data is fetched via libata's -&gt;eh_strategy_handler().

For Command Duration Limits policy 0xD:

  The device shall complete the command without error with the additional
  sense code set to DATA CURRENTLY UNAVAILABLE.

In order to handle this policy in libata, we intend to send a successful
command via SCSI EH, and let libata's -&gt;eh_strategy_handler() fetch the
sense data for the good command. This is similar to how we handle an
aborted ATA command, just that we need to read the Successful NCQ Commands
log instead of the NCQ Command Error log.

When we get a SATA completion with successful commands, ATA_SENSE will be
set, indicating that some commands in the completion have sense data.

The sense_valid bitmask in the Sense Data for Successful NCQ Commands log
will inform exactly which commands that had sense data, which might be a
subset of all the commands that was completed in the same completion. (Yet
all will have ATA_SENSE set, since the status is per completion.)

The successful commands that have e.g. a "DATA CURRENTLY UNAVAILABLE" sense
data will have a SCSI ML byte set, so scsi_eh_flush_done_q() will not set
the scmd-&gt;result to DID_TIME_OUT for these commands. However, the
successful commands that did not have sense data, must not get their result
marked as DID_TIME_OUT by SCSI EH.

Add a new flag SCMD_FORCE_EH_SUCCESS, which tells SCSI EH to not mark a
command as DID_TIME_OUT, even if it has scmd-&gt;result == SAM_STAT_GOOD.

This will be used by libata in a subsequent commit.

Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20230511011356.227789-5-nks@flawful.org
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: Declare most SCSI host template pointers const</title>
<updated>2023-03-24T23:19:19+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2023-03-22T19:53:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=31435de9746670d884f84a3c094a401aa27747aa'/>
<id>31435de9746670d884f84a3c094a401aa27747aa</id>
<content type='text'>
Prepare for constifying most SCSI host template pointers by constifying the
SCSI host template pointer arguments and variables in the SCSI core.

Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Reviewed-by: John Garry &lt;john.g.garry@oracle.com&gt;
Reviewed-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20230322195515.1267197-3-bvanassche@acm.org
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>
Prepare for constifying most SCSI host template pointers by constifying the
SCSI host template pointer arguments and variables in the SCSI core.

Reviewed-by: Benjamin Block &lt;bblock@linux.ibm.com&gt;
Reviewed-by: John Garry &lt;john.g.garry@oracle.com&gt;
Reviewed-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Cc: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20230322195515.1267197-3-bvanassche@acm.org
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch '6.2/scsi-queue' into 6.2/scsi-fixes</title>
<updated>2022-12-30T16:29:34+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2022-12-30T16:29:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6b1c374c45605504ed32e855c4e0f9b652a1978e'/>
<id>6b1c374c45605504ed32e855c4e0f9b652a1978e</id>
<content type='text'>
Pull in remaining patches from the 6.2 queue.

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>
Pull in remaining patches from the 6.2 queue.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi</title>
<updated>2022-12-14T16:58:51+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-12-14T16:58:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=aa5ad10f6cca6d42f3fef6cb862e03b220ea19a6'/>
<id>aa5ad10f6cca6d42f3fef6cb862e03b220ea19a6</id>
<content type='text'>
Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (target, ufs, smartpqi, lpfc).

  There are some core changes, mostly around reworking some of our user
  context assumptions in device put and moving some code around.

  The remaining updates are bug fixes and minor changes"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (138 commits)
  scsi: sg: Fix get_user() in call sg_scsi_ioctl()
  scsi: megaraid_sas: Fix some spelling mistakes in comment
  scsi: core: Use SCSI_SCAN_INITIAL in do_scsi_scan_host()
  scsi: core: Use SCSI_SCAN_RESCAN in __scsi_add_device()
  scsi: ufs: ufs-mediatek: Remove unnecessary return code
  scsi: ufs: core: Fix the polling implementation
  scsi: libsas: Do not export sas_ata_wait_after_reset()
  scsi: hisi_sas: Fix SATA devices missing issue during I_T nexus reset
  scsi: libsas: Add smp_ata_check_ready_type()
  scsi: Revert "scsi: hisi_sas: Don't send bcast events from HW during nexus HA reset"
  scsi: Revert "scsi: hisi_sas: Drain bcast events in hisi_sas_rescan_topology()"
  scsi: ufs: ufs-mediatek: Modify the return value
  scsi: ufs: ufs-mediatek: Remove unneeded code
  scsi: device_handler: alua: Call scsi_device_put() from non-atomic context
  scsi: device_handler: alua: Revert "Move a scsi_device_put() call out of alua_check_vpd()"
  scsi: snic: Fix possible UAF in snic_tgt_create()
  scsi: qla2xxx: Initialize vha-&gt;unknown_atio_[list, work] for NPIV hosts
  scsi: qla2xxx: Remove duplicate of vha-&gt;iocb_work initialization
  scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
  scsi: sd: Use 16-byte SYNCHRONIZE CACHE on ZBC devices
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (target, ufs, smartpqi, lpfc).

  There are some core changes, mostly around reworking some of our user
  context assumptions in device put and moving some code around.

  The remaining updates are bug fixes and minor changes"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (138 commits)
  scsi: sg: Fix get_user() in call sg_scsi_ioctl()
  scsi: megaraid_sas: Fix some spelling mistakes in comment
  scsi: core: Use SCSI_SCAN_INITIAL in do_scsi_scan_host()
  scsi: core: Use SCSI_SCAN_RESCAN in __scsi_add_device()
  scsi: ufs: ufs-mediatek: Remove unnecessary return code
  scsi: ufs: core: Fix the polling implementation
  scsi: libsas: Do not export sas_ata_wait_after_reset()
  scsi: hisi_sas: Fix SATA devices missing issue during I_T nexus reset
  scsi: libsas: Add smp_ata_check_ready_type()
  scsi: Revert "scsi: hisi_sas: Don't send bcast events from HW during nexus HA reset"
  scsi: Revert "scsi: hisi_sas: Drain bcast events in hisi_sas_rescan_topology()"
  scsi: ufs: ufs-mediatek: Modify the return value
  scsi: ufs: ufs-mediatek: Remove unneeded code
  scsi: device_handler: alua: Call scsi_device_put() from non-atomic context
  scsi: device_handler: alua: Revert "Move a scsi_device_put() call out of alua_check_vpd()"
  scsi: snic: Fix possible UAF in snic_tgt_create()
  scsi: qla2xxx: Initialize vha-&gt;unknown_atio_[list, work] for NPIV hosts
  scsi: qla2xxx: Remove duplicate of vha-&gt;iocb_work initialization
  scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
  scsi: sd: Use 16-byte SYNCHRONIZE CACHE on ZBC devices
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: scsi_error: Do not queue pointless abort workqueue functions</title>
<updated>2022-12-14T02:58:32+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@suse.de</email>
</author>
<published>2022-12-06T13:13:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d0b9025540ef57cc4464ab2fc64ed8ddc49b5658'/>
<id>d0b9025540ef57cc4464ab2fc64ed8ddc49b5658</id>
<content type='text'>
If a host template doesn't implement the .eh_abort_handler() there is no
point in queueing the abort workqueue function; all it does is invoking
SCSI EH anyway.  So return 'FAILED' from scsi_abort_command() if the
.eh_abort_handler() is not implemented and save us from having to wait for
the abort workqueue function to complete.

Cc: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Cc: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Cc: John Garry &lt;john.g.garry@oracle.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
[niklas: moved the check to the top of scsi_abort_command()]
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20221206131346.2045375-1-niklas.cassel@wdc.com
Reviewed-by: John Garry &lt;john.g.garry@oracle.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>
If a host template doesn't implement the .eh_abort_handler() there is no
point in queueing the abort workqueue function; all it does is invoking
SCSI EH anyway.  So return 'FAILED' from scsi_abort_command() if the
.eh_abort_handler() is not implemented and save us from having to wait for
the abort workqueue function to complete.

Cc: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Cc: Damien Le Moal &lt;damien.lemoal@opensource.wdc.com&gt;
Cc: John Garry &lt;john.g.garry@oracle.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
[niklas: moved the check to the top of scsi_abort_command()]
Signed-off-by: Niklas Cassel &lt;niklas.cassel@wdc.com&gt;
Link: https://lore.kernel.org/r/20221206131346.2045375-1-niklas.cassel@wdc.com
Reviewed-by: John Garry &lt;john.g.garry@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi/scsi_error: Use call_rcu_hurry() instead of call_rcu()</title>
<updated>2022-11-29T22:04:33+00:00</updated>
<author>
<name>Uladzislau Rezki</name>
<email>urezki@gmail.com</email>
</author>
<published>2022-10-16T16:23:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=54d87b0a0c19bc3f740e4cd4b87ba14ce2e4ea73'/>
<id>54d87b0a0c19bc3f740e4cd4b87ba14ce2e4ea73</id>
<content type='text'>
Earlier commits in this series allow battery-powered systems to build
their kernels with the default-disabled CONFIG_RCU_LAZY=y Kconfig option.
This Kconfig option causes call_rcu() to delay its callbacks in order
to batch them.  This means that a given RCU grace period covers more
callbacks, thus reducing the number of grace periods, in turn reducing
the amount of energy consumed, which increases battery lifetime which
can be a very good thing.  This is not a subtle effect: In some important
use cases, the battery lifetime is increased by more than 10%.

This CONFIG_RCU_LAZY=y option is available only for CPUs that offload
callbacks, for example, CPUs mentioned in the rcu_nocbs kernel boot
parameter passed to kernels built with CONFIG_RCU_NOCB_CPU=y.

Delaying callbacks is normally not a problem because most callbacks do
nothing but free memory.  If the system is short on memory, a shrinker
will kick all currently queued lazy callbacks out of their laziness,
thus freeing their memory in short order.  Similarly, the rcu_barrier()
function, which blocks until all currently queued callbacks are invoked,
will also kick lazy callbacks, thus enabling rcu_barrier() to complete
in a timely manner.

However, there are some cases where laziness is not a good option.
For example, synchronize_rcu() invokes call_rcu(), and blocks until
the newly queued callback is invoked.  It would not be a good for
synchronize_rcu() to block for ten seconds, even on an idle system.
Therefore, synchronize_rcu() invokes call_rcu_hurry() instead of
call_rcu().  The arrival of a non-lazy call_rcu_hurry() callback on a
given CPU kicks any lazy callbacks that might be already queued on that
CPU.  After all, if there is going to be a grace period, all callbacks
might as well get full benefit from it.

Yes, this could be done the other way around by creating a
call_rcu_lazy(), but earlier experience with this approach and
feedback at the 2022 Linux Plumbers Conference shifted the approach
to call_rcu() being lazy with call_rcu_hurry() for the few places
where laziness is inappropriate.

And another call_rcu() instance that cannot be lazy is the one in the
scsi_eh_scmd_add() function.  Leaving this instance lazy results in
unacceptably slow boot times.

Therefore, make scsi_eh_scmd_add() use call_rcu_hurry() in order to
revert to the old behavior.

[ paulmck: Apply s/call_rcu_flush/call_rcu_hurry/ feedback from Tejun Heo. ]

Tested-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Signed-off-by: Uladzislau Rezki &lt;urezki@gmail.com&gt;
Signed-off-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Cc: "James E.J. Bottomley" &lt;jejb@linux.ibm.com&gt;
Cc: &lt;linux-scsi@vger.kernel.org&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Acked-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Earlier commits in this series allow battery-powered systems to build
their kernels with the default-disabled CONFIG_RCU_LAZY=y Kconfig option.
This Kconfig option causes call_rcu() to delay its callbacks in order
to batch them.  This means that a given RCU grace period covers more
callbacks, thus reducing the number of grace periods, in turn reducing
the amount of energy consumed, which increases battery lifetime which
can be a very good thing.  This is not a subtle effect: In some important
use cases, the battery lifetime is increased by more than 10%.

This CONFIG_RCU_LAZY=y option is available only for CPUs that offload
callbacks, for example, CPUs mentioned in the rcu_nocbs kernel boot
parameter passed to kernels built with CONFIG_RCU_NOCB_CPU=y.

Delaying callbacks is normally not a problem because most callbacks do
nothing but free memory.  If the system is short on memory, a shrinker
will kick all currently queued lazy callbacks out of their laziness,
thus freeing their memory in short order.  Similarly, the rcu_barrier()
function, which blocks until all currently queued callbacks are invoked,
will also kick lazy callbacks, thus enabling rcu_barrier() to complete
in a timely manner.

However, there are some cases where laziness is not a good option.
For example, synchronize_rcu() invokes call_rcu(), and blocks until
the newly queued callback is invoked.  It would not be a good for
synchronize_rcu() to block for ten seconds, even on an idle system.
Therefore, synchronize_rcu() invokes call_rcu_hurry() instead of
call_rcu().  The arrival of a non-lazy call_rcu_hurry() callback on a
given CPU kicks any lazy callbacks that might be already queued on that
CPU.  After all, if there is going to be a grace period, all callbacks
might as well get full benefit from it.

Yes, this could be done the other way around by creating a
call_rcu_lazy(), but earlier experience with this approach and
feedback at the 2022 Linux Plumbers Conference shifted the approach
to call_rcu() being lazy with call_rcu_hurry() for the few places
where laziness is inappropriate.

And another call_rcu() instance that cannot be lazy is the one in the
scsi_eh_scmd_add() function.  Leaving this instance lazy results in
unacceptably slow boot times.

Therefore, make scsi_eh_scmd_add() use call_rcu_hurry() in order to
revert to the old behavior.

[ paulmck: Apply s/call_rcu_flush/call_rcu_hurry/ feedback from Tejun Heo. ]

Tested-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Signed-off-by: Uladzislau Rezki &lt;urezki@gmail.com&gt;
Signed-off-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Cc: "James E.J. Bottomley" &lt;jejb@linux.ibm.com&gt;
Cc: &lt;linux-scsi@vger.kernel.org&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Acked-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: Increase scsi_device's iodone_cnt in scsi_timeout()</title>
<updated>2022-11-24T03:41:31+00:00</updated>
<author>
<name>Wenchao Hao</name>
<email>haowenchao@huawei.com</email>
</author>
<published>2022-11-23T12:21:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ec9780e48c77f469c339b53940ef0c5eacc8b9d2'/>
<id>ec9780e48c77f469c339b53940ef0c5eacc8b9d2</id>
<content type='text'>
If a SCSI command times out and is going to be aborted, we should increase
the iodone_cnt of the related scsi_device. Otherwise the iodone_cnt would
be smaller than iorequest_cnt.

Increasing iodone_cnt in scsi_timeout() would not cause a double accounting
issue. Brief analysis follows:

 - We add the iodone_cnt when BLK_EH_DONE is returned in
   scsi_timeout(). The related command's timeout event would not happen.

 - If the abort succeeds and the command is not retried, the command would
   be completed with scsi_finish_command() which would not increase
   iodone_cnt.

 - If the abort succeeds and the command is retried, it would be requeue. A
   scsi_dispatch_cmd() would be called and iorequest_cnt would be increased
   again.

 - If the abort fails, the error handler successfully recovers the device,
   and the command is not retried, the command would be completed with
   scsi_finish_command() which would not increase iodone_cnt.

 - If the abort fails, the error handler successfully recovers the device,
   and the command is retried, the iorequest_cnt would be increased again.

Signed-off-by: Wenchao Hao &lt;haowenchao@huawei.com&gt;
Link: https://lore.kernel.org/r/20221123122137.150776-2-haowenchao@huawei.com
Reviewed-by: Mike Christie &lt;michael.christie@oracle.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>
If a SCSI command times out and is going to be aborted, we should increase
the iodone_cnt of the related scsi_device. Otherwise the iodone_cnt would
be smaller than iorequest_cnt.

Increasing iodone_cnt in scsi_timeout() would not cause a double accounting
issue. Brief analysis follows:

 - We add the iodone_cnt when BLK_EH_DONE is returned in
   scsi_timeout(). The related command's timeout event would not happen.

 - If the abort succeeds and the command is not retried, the command would
   be completed with scsi_finish_command() which would not increase
   iodone_cnt.

 - If the abort succeeds and the command is retried, it would be requeue. A
   scsi_dispatch_cmd() would be called and iorequest_cnt would be increased
   again.

 - If the abort fails, the error handler successfully recovers the device,
   and the command is not retried, the command would be completed with
   scsi_finish_command() which would not increase iodone_cnt.

 - If the abort fails, the error handler successfully recovers the device,
   and the command is retried, the iorequest_cnt would be increased again.

Signed-off-by: Wenchao Hao &lt;haowenchao@huawei.com&gt;
Link: https://lore.kernel.org/r/20221123122137.150776-2-haowenchao@huawei.com
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: Change the return type of .eh_timed_out()</title>
<updated>2022-10-22T03:25:59+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2022-10-18T20:29:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dee7121e8c0a3ce41af2b02d516f54eaec32abcd'/>
<id>dee7121e8c0a3ce41af2b02d516f54eaec32abcd</id>
<content type='text'>
Commit 6600593cbd93 ("block: rename BLK_EH_NOT_HANDLED to BLK_EH_DONE")
made it impossible for .eh_timed_out() implementations to call
scsi_done() without causing a crash.

Restore support for SCSI timeout handlers to call scsi_done() as follows:

 * Change all .eh_timed_out() handlers as follows:

   - Change the return type into enum scsi_timeout_action.
   - Change BLK_EH_RESET_TIMER into SCSI_EH_RESET_TIMER.
   - Change BLK_EH_DONE into SCSI_EH_NOT_HANDLED.

 * In scsi_timeout(), convert the SCSI_EH_* values into BLK_EH_* values.

Reviewed-by: Lee Duncan &lt;lduncan@suse.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: John Garry &lt;john.garry@huawei.com&gt;
Cc: Mike Christie &lt;michael.christie@oracle.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20221018202958.1902564-3-bvanassche@acm.org
Reviewed-by: Mike Christie &lt;michael.christie@oracle.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>
Commit 6600593cbd93 ("block: rename BLK_EH_NOT_HANDLED to BLK_EH_DONE")
made it impossible for .eh_timed_out() implementations to call
scsi_done() without causing a crash.

Restore support for SCSI timeout handlers to call scsi_done() as follows:

 * Change all .eh_timed_out() handlers as follows:

   - Change the return type into enum scsi_timeout_action.
   - Change BLK_EH_RESET_TIMER into SCSI_EH_RESET_TIMER.
   - Change BLK_EH_DONE into SCSI_EH_NOT_HANDLED.

 * In scsi_timeout(), convert the SCSI_EH_* values into BLK_EH_* values.

Reviewed-by: Lee Duncan &lt;lduncan@suse.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: John Garry &lt;john.garry@huawei.com&gt;
Cc: Mike Christie &lt;michael.christie@oracle.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20221018202958.1902564-3-bvanassche@acm.org
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: core: Fix a race between scsi_done() and scsi_timeout()</title>
<updated>2022-10-22T03:25:59+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bvanassche@acm.org</email>
</author>
<published>2022-10-18T20:29:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=978b7922d3dca672b41bb4b8ce6c06ab77112741'/>
<id>978b7922d3dca672b41bb4b8ce6c06ab77112741</id>
<content type='text'>
If there is a race between scsi_done() and scsi_timeout() and if
scsi_timeout() loses the race, scsi_timeout() should not reset the request
timer. Hence change the return value for this case from BLK_EH_RESET_TIMER
into BLK_EH_DONE.

Although the block layer holds a reference on a request (req-&gt;ref) while
calling a timeout handler, restarting the timer (blk_add_timer()) while a
request is being completed is racy.

Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Cc: Keith Busch &lt;kbusch@kernel.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: John Garry &lt;john.garry@huawei.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Reported-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20221018202958.1902564-2-bvanassche@acm.org
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>
If there is a race between scsi_done() and scsi_timeout() and if
scsi_timeout() loses the race, scsi_timeout() should not reset the request
timer. Hence change the return value for this case from BLK_EH_RESET_TIMER
into BLK_EH_DONE.

Although the block layer holds a reference on a request (req-&gt;ref) while
calling a timeout handler, restarting the timer (blk_add_timer()) while a
request is being completed is racy.

Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Cc: Keith Busch &lt;kbusch@kernel.org&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Ming Lei &lt;ming.lei@redhat.com&gt;
Cc: John Garry &lt;john.garry@huawei.com&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Reported-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Fixes: 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request")
Signed-off-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Link: https://lore.kernel.org/r/20221018202958.1902564-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
