From: Bart Van Assche <bvanassche@acm.org>
To: Michael Christie <michaelc@cs.wisc.edu>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
James Bottomley <jbottomley@parallels.com>,
Jens Axboe <axboe@kernel.dk>, Tejun Heo <tj@kernel.org>,
Chanho Min <chanho.min@lge.com>
Subject: Re: [PATCH] Fix a use-after-free triggered by device removal
Date: Thu, 06 Sep 2012 19:58:54 +0200 [thread overview]
Message-ID: <5048E45E.1070302@acm.org> (raw)
In-Reply-To: <91D94272-CA62-4E68-87D7-CE77DE776CC9@cs.wisc.edu>
_suOn 09/06/12 18:27, Michael Christie wrote:
> On Sep 3, 2012, at 9:12 AM, Bart Van Assche <bvanassche@acm.org> wrote:
>> If the put_device() call in scsi_request_fn() drops the sdev refcount
>> to zero then the spin_lock() call after the put_device() call triggers
>> a use-after-free. Avoid that by making sure that blk_cleanup_queue()
>> can only finish after all active scsi_request_fn() calls have returned.
>
> If we have this patch http://marc.info/?l=linux-scsi&m=134453905402413&w=2
> it seems we have all the scsi layer callers of the request_fn/
> *blk_run_queue holding a reference to the device when they make the call.
> Right, or are there some other places missing?
>
> What are the other places we can call the request_fn without already
> holding a reference to the device? Is it the block layer? Is that why we
> need this patch?
Hello Mike,
The purpose of this patch is indeed to make *blk_run_queue() calls from
the block layer safe. There are several direct or indirect
*blk_run_queue() calls in the block layer where a reference on the queue
is held but not on the sdev, e.g. in the md, dm and bsg drivers.
Bart.
next prev parent reply other threads:[~2012-09-06 17:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-03 14:12 [PATCH] Fix a use-after-free triggered by device removal Bart Van Assche
2012-09-06 16:27 ` Michael Christie
2012-09-06 17:58 ` Bart Van Assche [this message]
2012-09-06 18:14 ` Mike Christie
2012-09-06 18:52 ` Bart Van Assche
2012-09-06 23:20 ` Tejun Heo
2012-09-07 6:57 ` Bart Van Assche
2012-09-10 23:38 ` Tejun Heo
2012-09-11 6:42 ` Bart Van Assche
2012-09-12 20:53 ` Tejun Heo
2012-09-13 7:26 ` Bart Van Assche
2012-09-13 16:53 ` Tejun Heo
2012-09-13 18:27 ` Bart Van Assche
2012-09-13 19:25 ` Tejun Heo
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=5048E45E.1070302@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=chanho.min@lge.com \
--cc=jbottomley@parallels.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=tj@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.