Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Tomas Henzl <thenzl@redhat.com>
To: "Michal Rábek" <mrabek@redhat.com>,
	linux-scsi@vger.kernel.org, dgilbert@interlog.com
Cc: Changhui Zhong <czhong@redhat.com>,
	"Ewan D. Milne" <emilne@redhat.com>,
	John Meneghini <jmeneghi@redhat.com>
Subject: Re: [PATCH] scsi: sg: fix occasional bogus elapsed time that exceeds timeout
Date: Mon, 15 Dec 2025 16:09:54 +0100	[thread overview]
Message-ID: <39e41ce3-3fe8-456f-a886-868934b84e5e@redhat.com> (raw)
In-Reply-To: <20251212160900.64924-1-mrabek@redhat.com>

On 12/12/25 5:08 PM, Michal Rábek wrote:
> A race condition was found in sg_proc_debug_helper(). It was observed on
> a system using an IBM LTO-9 SAS Tape Drive (ULTRIUM-TD9) and monitoring
> /proc/scsi/sg/debug every second. A very large elapsed time would
> sometimes appear. This is caused by two race conditions.
> 
> We reproduced the issue with an IBM ULTRIUM-HH9 tape drive on an x86_64
> architecture. A patched kernel was built, and the race condition could
> not be observed anymore after the application of this patch. A reproducer
> C program utilising the scsi_debug module was also built by
> Changhui Zhong and can be viewed here:
> 
> https://github.com/MichaelRabek/linux-tests/blob/master/drivers/scsi/sg/sg_race_trigger.c
> 
> The first race happens between the reading of hp->duration in
> sg_proc_debug_helper() and request completion in sg_rq_end_io().
> The hp->duration member variable may hold either of two types of
> information:
>  #1 - The start time of the request. This value is present while
>       the request is not yet finished.
> 
>  #2 - The total execution time of the request (end_time - start_time).
> 
> If sg_proc_debug_helper() executes *after* the value of hp->duration
> was changed from #1 to #2, but *before* srp->done is set to 1 in
> sg_rq_end_io(), a fresh timestamp is taken in the else branch, and the
> elapsed time (value type #2) is subtracted from a timestamp, which
> cannot yield a valid elapsed time (which is a type #2 value as well).
> 
> To fix this issue, the value of hp->duration must change under the
> protection of the sfp->rq_list_lock in sg_rq_end_io().
> Since sg_proc_debug_helper() takes this read lock, the change to
> srp->done and srp->header.duration will happen atomically from the
> perspective of sg_proc_debug_helper() and the race condition is thus
> eliminated.
> 
> The second race condition happens between sg_proc_debug_helper() and
> sg_new_write(). Even though hp->duration is set to the current time
> stamp in sg_add_request() under the write lock's protection, it gets
> overwritten by a call to get_sg_io_hdr(), which calls copy_from_user() to
> copy struct sg_io_hdr from userspace into kernel space. hp->duration is
> set to the start time again in sg_common_write(). If
> sg_proc_debug_helper() is called between these two calls, an arbitrary
> value set by userspace (usually zero) is used to compute the elapsed time.
> 
> To fix this issue, hp->duration must be set to the current timestamp again
> after get_sg_io_hdr() returns successfully. A small race window still
> exists between get_sg_io_hdr() and setting hp->duration, but this window
> is only a few instructions wide and does not result in observable issues
> in practice, as confirmed by testing.
> 
> Additionally, we fix the format specifier from %d to %u for printing
> unsigned int values in sg_proc_debug_helper().
> 
> Signed-off-by: Michal Rábek <mrabek@redhat.com>
> Suggested-by: Tomas Henzl <thenzl@redhat.com>
> Tested-by: Changhui Zhong <czhong@redhat.com>
> Reviewed-by: Ewan D. Milne <emilne@redhat.com>
> Reviewed-by: John Meneghini <jmeneghi@redhat.com>

Looks good, thanks.
tomash
Reviewed-by: Tomas Henzl <thenzl@redhat.com>

> ---
>  drivers/scsi/sg.c | 20 +++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index b3af9b78fa12..57fba34832ad 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -731,6 +731,8 @@ sg_new_write(Sg_fd *sfp, struct file *file, const char __user *buf,
>  		sg_remove_request(sfp, srp);
>  		return -EFAULT;
>  	}
> +	hp->duration = jiffies_to_msecs(jiffies);
> +
>  	if (hp->interface_id != 'S') {
>  		sg_remove_request(sfp, srp);
>  		return -ENOSYS;
> @@ -815,7 +817,6 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
>  		return -ENODEV;
>  	}
>  
> -	hp->duration = jiffies_to_msecs(jiffies);
>  	if (hp->interface_id != '\0' &&	/* v3 (or later) interface */
>  	    (SG_FLAG_Q_AT_TAIL & hp->flags))
>  		at_head = 0;
> @@ -1338,9 +1339,6 @@ sg_rq_end_io(struct request *rq, blk_status_t status)
>  				      "sg_cmd_done: pack_id=%d, res=0x%x\n",
>  				      srp->header.pack_id, result));
>  	srp->header.resid = resid;
> -	ms = jiffies_to_msecs(jiffies);
> -	srp->header.duration = (ms > srp->header.duration) ?
> -				(ms - srp->header.duration) : 0;
>  	if (0 != result) {
>  		struct scsi_sense_hdr sshdr;
>  
> @@ -1389,6 +1387,9 @@ sg_rq_end_io(struct request *rq, blk_status_t status)
>  			done = 0;
>  	}
>  	srp->done = done;
> +	ms = jiffies_to_msecs(jiffies);
> +	srp->header.duration = (ms > srp->header.duration) ?
> +				(ms - srp->header.duration) : 0;
>  	write_unlock_irqrestore(&sfp->rq_list_lock, iflags);
>  
>  	if (likely(done)) {
> @@ -2533,6 +2534,7 @@ static void sg_proc_debug_helper(struct seq_file *s, Sg_device * sdp)
>  	const sg_io_hdr_t *hp;
>  	const char * cp;
>  	unsigned int ms;
> +	unsigned int duration;
>  
>  	k = 0;
>  	list_for_each_entry(fp, &sdp->sfds, sfd_siblings) {
> @@ -2570,13 +2572,17 @@ static void sg_proc_debug_helper(struct seq_file *s, Sg_device * sdp)
>  			seq_printf(s, " id=%d blen=%d",
>  				   srp->header.pack_id, blen);
>  			if (srp->done)
> -				seq_printf(s, " dur=%d", hp->duration);
> +				seq_printf(s, " dur=%u", hp->duration);
>  			else {
>  				ms = jiffies_to_msecs(jiffies);
> -				seq_printf(s, " t_o/elap=%d/%d",
> +				duration = READ_ONCE(hp->duration);
> +				if (duration)
> +					duration = (ms > duration ?
> +						    ms - duration : 0);
> +				seq_printf(s, " t_o/elap=%u/%u",
>  					(new_interface ? hp->timeout :
>  						  jiffies_to_msecs(fp->timeout)),
> -					(ms > hp->duration ? ms - hp->duration : 0));
> +					duration);
>  			}
>  			seq_printf(s, "ms sgat=%d op=0x%02x\n", usg,
>  				   (int) srp->data.cmd_opcode);


  reply	other threads:[~2025-12-15 15:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 16:08 [PATCH] scsi: sg: fix occasional bogus elapsed time that exceeds timeout Michal Rábek
2025-12-15 15:09 ` Tomas Henzl [this message]
2025-12-17  3:40 ` Martin K. Petersen

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=39e41ce3-3fe8-456f-a886-868934b84e5e@redhat.com \
    --to=thenzl@redhat.com \
    --cc=czhong@redhat.com \
    --cc=dgilbert@interlog.com \
    --cc=emilne@redhat.com \
    --cc=jmeneghi@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mrabek@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