public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <jejb@linux.ibm.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	Avri Altman <avri.altman@wdc.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-scsi@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Ming Lei <ming.lei@redhat.com>, Hannes Reinecke <hare@suse.de>,
	Mike Christie <michael.christie@oracle.com>,
	Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH v2 1/4] scsi: sd: Let sd_shutdown() fail future I/O
Date: Tue, 18 Apr 2023 10:36:52 -0400	[thread overview]
Message-ID: <cdd6b413085dc606c351f3c10ea82774498171e1.camel@linux.ibm.com> (raw)
In-Reply-To: <20230417230656.523826-2-bvanassche@acm.org>

On Mon, 2023-04-17 at 16:06 -0700, Bart Van Assche wrote:
> System shutdown happens as follows (see e.g. the systemd source file
> src/shutdown/shutdown.c):
> * sync() is called.
> * reboot(RB_AUTOBOOT/RB_HALT_SYSTEM/RB_POWER_OFF) is called.
> * If the reboot() system call returns, log an error message.
> 
> The reboot() system call causes the kernel to call kernel_restart(),
> kernel_halt() or kernel_power_off(). Each of these functions calls
> device_shutdown(). device_shutdown() calls sd_shutdown(). After
> sd_shutdown() has been called the .shutdown() callback of the LLD
> will be called. Hence, I/O submitted after sd_shutdown() will hang or
> may even cause a kernel crash.
> 
> Let sd_shutdown() fail future I/O such that LLD .shutdown() callbacks
> can be simplified.

What is the actual reason for this?  What is it you think might be
submitting I/O after the system gets into this state?  Current
sd_shutdown is constructed on the premise that it's the last thing that
ever happens to the device before reboot/power off which is why it
flushes the cache if necessary and stops the device if required, but
for most standard devices neither is required because we don't expect
Linux to go down with pending items in the block queue and for a write
through disk cache anything that's completed on the block queue is
safely durable on the device.

James


  parent reply	other threads:[~2023-04-18 14:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17 23:06 [PATCH v2 0/4] SCSI core and UFS patches for kernel v6.4 Bart Van Assche
2023-04-17 23:06 ` [PATCH v2 1/4] scsi: sd: Let sd_shutdown() fail future I/O Bart Van Assche
2023-04-18  4:37   ` Ming Lei
2023-04-18 14:09     ` Bart Van Assche
2023-04-18  5:06   ` Christoph Hellwig
2023-04-18 14:36   ` James Bottomley [this message]
2023-04-18 18:37     ` Bart Van Assche
2023-04-19  2:34       ` James Bottomley
2023-04-19 13:36         ` Tomas Henzl
2023-04-19 14:02           ` James Bottomley
2023-04-19 17:58             ` Bart Van Assche
2023-04-19 18:33               ` James Bottomley
2023-04-19 19:24                 ` Bart Van Assche
2023-04-19 19:29                   ` James Bottomley
2023-04-17 23:06 ` [PATCH v2 2/4] scsi: ufs: Simplify ufshcd_wl_shutdown() Bart Van Assche
2023-04-18 13:45   ` Adrian Hunter
2023-04-18 14:06     ` Bart Van Assche
2023-04-18 14:13       ` Adrian Hunter
2023-04-18 20:14         ` Bart Van Assche
2023-04-19  5:23           ` Adrian Hunter
2023-04-17 23:06 ` [PATCH v2 3/4] scsi: ufs: Increase the START STOP UNIT timeout from one to ten seconds Bart Van Assche
2023-04-18  7:30   ` Adrian Hunter
2023-04-18  7:57   ` Stanley Chu
2023-04-17 23:06 ` [PATCH v2 4/4] scsi: ufs: Fix handling of lrbp->cmd Bart Van Assche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cdd6b413085dc606c351f3c10ea82774498171e1.camel@linux.ibm.com \
    --to=jejb@linux.ibm.com \
    --cc=adrian.hunter@intel.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jaegeuk@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=thenzl@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox