On 05/24/2011 03:05 PM, Kevin Wolf wrote:
Maybe the callback should be done from a BH then? It sounds like this
could cause more bugs than what you're fixing here.
Not sure, after all it makes sense to answer some queries synchronously
(e.g. TEST_UNIT_READY). It's just the convoluted control
Am 20.05.2011 19:43, schrieb Paolo Bonzini:
> On 05/20/2011 06:04 PM, Christoph Hellwig wrote:
>>> -void scsi_req_enqueue(SCSIRequest *req)
>>> +int32_t scsi_req_enqueue(SCSIRequest *req, uint8_t *buf)
>>> {
>>> +int32_t rc;
>>> assert(!req->enqueued);
>>> scsi_req_ref(req);
>>>
On 05/20/2011 06:04 PM, Christoph Hellwig wrote:
-void scsi_req_enqueue(SCSIRequest *req)
+int32_t scsi_req_enqueue(SCSIRequest *req, uint8_t *buf)
{
+int32_t rc;
assert(!req->enqueued);
scsi_req_ref(req);
req->enqueued = true;
QTAILQ_INSERT_TAIL(&req->dev->requests,
> -void scsi_req_enqueue(SCSIRequest *req)
> +int32_t scsi_req_enqueue(SCSIRequest *req, uint8_t *buf)
> {
> +int32_t rc;
> assert(!req->enqueued);
> scsi_req_ref(req);
> req->enqueued = true;
> QTAILQ_INSERT_TAIL(&req->dev->requests, req, next);
> +
> +/* Make sure the
Move the common part of scsi-disk.c and scsi-generic.c to the SCSI layer.
At the same time, protect against the request being freed under the
feet of the send_command callback.
This fixes a use-after-free that happened when scsi-disk's
scsi_disk_emulate_command completed an illegal request, and st
