public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Alexander Wetzel <Alexander@wetzel-home.de>, dgilbert@interlog.com
Cc: gregkh@linuxfoundation.org, sachinp@linux.ibm.com,
	linux-scsi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	martin.petersen@oracle.com, stable@vger.kernel.org
Subject: Re: [PATCH v3] scsi: sg: Avoid race in error handling & drop bogus warn
Date: Wed, 3 Apr 2024 16:24:30 -0700	[thread overview]
Message-ID: <bc800bdd-6563-40ba-bc8d-e98b87748c15@acm.org> (raw)
In-Reply-To: <20240401191038.18359-1-Alexander@wetzel-home.de>

On 4/1/24 12:10 PM, Alexander Wetzel wrote:
> @@ -301,11 +302,12 @@ sg_open(struct inode *inode, struct file *filp)
>   
>   	/* This driver's module count bumped by fops_get in <linux/fs.h> */
>   	/* Prevent the device driver from vanishing while we sleep */
> -	retval = scsi_device_get(sdp->device);
> +	device = sdp->device;
> +	retval = scsi_device_get(device);
>   	if (retval)
>   		goto sg_put;

Are all the sdp->device -> device changes essential? Isn't there a
preference to minimize patches that will end up in the stable trees?

Thanks,

Bart.

  parent reply	other threads:[~2024-04-03 23:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29  9:08 [powerpc] WARN at drivers/scsi/sg.c:2236 (sg_remove_sfp_usercontext) Sachin Sant
2024-03-29 11:10 ` Alexander Wetzel
2024-03-29 14:37   ` Sachin Sant
2024-04-01  9:56     ` [PATCH] scsi: sg: Avoid race in error handling & drop bogus warn Alexander Wetzel
2024-04-01 10:03     ` [PATCH v2] " Alexander Wetzel
2024-04-01 17:09       ` Bart Van Assche
2024-04-01 19:01         ` Alexander Wetzel
2024-04-01 19:10     ` [PATCH v3] " Alexander Wetzel
2024-04-02  6:01       ` Sachin Sant
2024-04-03 23:24       ` Bart Van Assche [this message]
2024-04-04  6:55         ` Alexander Wetzel
2024-04-04 16:34       ` Bart Van Assche
2024-04-04 22:22       ` Martin K. Petersen
2024-04-06  1:58       ` 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=bc800bdd-6563-40ba-bc8d-e98b87748c15@acm.org \
    --to=bvanassche@acm.org \
    --cc=Alexander@wetzel-home.de \
    --cc=dgilbert@interlog.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=martin.petersen@oracle.com \
    --cc=sachinp@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    /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