From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Huajun Li <huajun.li.lee@gmail.com>
Cc: JBottomley@Parallels.com, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SCSI/sd: Fix NULL dereference in sd_revalidate_disk
Date: Sat, 26 Nov 2011 10:51:46 +0100 [thread overview]
Message-ID: <20111126105146.756a122a@stein> (raw)
In-Reply-To: <CA+v9cxbk0p_FTDq7TMEc5draOMz4n46H4t=iLe2brkosM=LHVw@mail.gmail.com>
On Nov 24 Huajun Li wrote:
> While unplugging usb disk, scsi_disk(disk)->device may be released
> before sd_revalidate_disk() is called, then there will occur Oops as
> shown below:
[...]
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2354,10 +2354,15 @@ static int sd_try_extended_inquiry(struct
> scsi_device *sdp)
> static int sd_revalidate_disk(struct gendisk *disk)
> {
> struct scsi_disk *sdkp = scsi_disk(disk);
> - struct scsi_device *sdp = sdkp->device;
> + struct scsi_device *sdp;
> unsigned char *buffer;
> unsigned flush = 0;
>
> + if (sdkp)
> + sdp = sdkp->device;
> + else
> + goto out;
> +
> SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp,
> "sd_revalidate_disk\n"));
>
Shouldn't rather the [block -- command-set-driver -- scsi-core -- lld]
stack be structured along the lines that lower-level device instances live
as long as higher levels rely on them?
For about a year now or so, I am seeing patches floating by that add NULL
pointer checks here and there (or patches that clear pointers), and every
time I wonder
- where else such NULL pointer checks might be needed,
- in what way (if at all) it is ensured that a function which is made to
check for a valid pointer at the top does not race with pointer
invalidation further down the road.
--
Stefan Richter
-=====-==-== =-== ==-=-
http://arcgraph.de/sr/
next prev parent reply other threads:[~2011-11-26 9:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-24 14:30 [PATCH] SCSI/sd: Fix NULL dereference in sd_revalidate_disk Huajun Li
2011-11-26 9:51 ` Stefan Richter [this message]
2011-11-26 14:00 ` James Bottomley
2011-11-27 1:28 ` Huajun Li
2011-11-27 2:20 ` Huajun Li
2011-11-27 2:38 ` James Bottomley
2011-11-27 3:22 ` Huajun Li
2011-11-30 14:43 ` Huajun Li
2011-11-30 14:50 ` Huajun Li
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=20111126105146.756a122a@stein \
--to=stefanr@s5r6.in-berlin.de \
--cc=JBottomley@Parallels.com \
--cc=huajun.li.lee@gmail.com \
--cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.