The CFQ elevator may BUG if the direction flags on an I/O request are
changed after allocation. cfq_set_request() and cfq_put_request()
count READ and WRITE requests separately. Changing the I/O request
direction after blk_get_request() allocates the request throws off
this CFQ accounting.
Signed-off-by: Hugh Daschbach <hda...@broadcom.com>
---
drivers/scsi/device_handler/scsi_dh_emc.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_emc.c b/drivers/scsi/device_handler/scsi_dh_emc.c
index 6196675..3709342 100644
--- a/drivers/scsi/device_handler/scsi_dh_emc.c
+++ b/drivers/scsi/device_handler/scsi_dh_emc.c
@@ -269,10 +269,12 @@ static struct request *get_req(struct scsi_device *sdev, int cmd,
unsigned char *buffer)
{
struct request *rq;
+ int mode = READ;
int len = 0;
- rq = blk_get_request(sdev->request_queue,
- (cmd == MODE_SELECT) ? WRITE : READ, GFP_NOIO);
+ if (cmd == MODE_SELECT || cmd == MODE_SELECT_10)
+ mode = WRITE;
+ rq = blk_get_request(sdev->request_queue, mode, GFP_NOIO);
if (!rq) {
sdev_printk(KERN_INFO, sdev, "get_req: blk_get_request failed");
return NULL;
@@ -284,12 +286,10 @@ static struct request *get_req(struct scsi_device *sdev, int cmd,
switch (cmd) {
case MODE_SELECT:
len = sizeof(short_trespass);
- rq->cmd_flags |= REQ_RW;
rq->cmd[1] = 0x10;
break;
case MODE_SELECT_10:
len = sizeof(long_trespass);
- rq->cmd_flags |= REQ_RW;
rq->cmd[1] = 0x10;
break;
case INQUIRY:
--
1.6.6.196.g1f735
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This description doesn't really match what the problem seems to be
below:
> Signed-off-by: Hugh Daschbach <hda...@broadcom.com>
> ---
> drivers/scsi/device_handler/scsi_dh_emc.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/device_handler/scsi_dh_emc.c b/drivers/scsi/device_handler/scsi_dh_emc.c
> index 6196675..3709342 100644
> --- a/drivers/scsi/device_handler/scsi_dh_emc.c
> +++ b/drivers/scsi/device_handler/scsi_dh_emc.c
> @@ -269,10 +269,12 @@ static struct request *get_req(struct scsi_device *sdev, int cmd,
> unsigned char *buffer)
> {
> struct request *rq;
> + int mode = READ;
> int len = 0;
>
> - rq = blk_get_request(sdev->request_queue,
> - (cmd == MODE_SELECT) ? WRITE : READ, GFP_NOIO);
> + if (cmd == MODE_SELECT || cmd == MODE_SELECT_10)
> + mode = WRITE;
> + rq = blk_get_request(sdev->request_queue, mode, GFP_NOIO);
So the actual bug is failure to set WRITE for MODE_SELECT_10.
> if (!rq) {
> sdev_printk(KERN_INFO, sdev, "get_req: blk_get_request failed");
> return NULL;
> @@ -284,12 +286,10 @@ static struct request *get_req(struct scsi_device *sdev, int cmd,
> switch (cmd) {
> case MODE_SELECT:
> len = sizeof(short_trespass);
> - rq->cmd_flags |= REQ_RW;
And this is just cosmetic ... the flags already having been set by the
allocation, they don't need to be set again.
> rq->cmd[1] = 0x10;
> break;
> case MODE_SELECT_10:
> len = sizeof(long_trespass);
> - rq->cmd_flags |= REQ_RW;
> rq->cmd[1] = 0x10;
> break;
> case INQUIRY:
Chandra, can you tidy this up and take it, please?
Thanks,
James
I think we have a fix for this and some len issues in that module that
was sent here:
http://marc.info/?l=linux-scsi&m=125978574800618&w=2
Yes, you did ... the need to change the From: field caused me to mark it
in a different way and ultimately lose it ... I'll add it this time ...
James
Did you try the patch I linked to the last time you posted about this?
I think there should be a patch which fixes this problem here:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=6c71dcb28ff9b63b814a0b76a256f5dae08d3e0d;hp=3a5b27bf6f29574d667230c7e76e4b83fe3014e0
I think it got into 2.6.34-rc1.
With that patch mode selects should get set up as writes.
Does it work? If it does then I think we just need the attached cleanup
patch which removes the cmd_flags setting. The patch that got merged
fixed the problem of initializing the request properly, but it forgot to
remove the cmd_flags setting.
> On 03/19/2010 12:31 AM, Hugh Daschbach wrote:
>> The EMC multipath device handler should not change the I/O direction
>> flags of its trespass command request.
...
> Did you try the patch I linked to the last time you posted about this?
I have not. When I read it, I believed it would fix the issue.
> I think there should be a patch which fixes this problem here:
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=6c71dcb28ff9b63b814a0b76a256f5dae08d3e0d;hp=3a5b27bf6f29574d667230c7e76e4b83fe3014e0
> I think it got into 2.6.34-rc1.
Then I'll pull it and test it.
> With that patch mode selects should get set up as writes.
>
> Does it work? If it does then I think we just need the attached cleanup
> patch which removes the cmd_flags setting. The patch that got merged
> fixed the problem of initializing the request properly, but it forgot to
> remove the cmd_flags setting.
Agree. I'll test it early next week and confirm.
Thanks,
Hugh
>> On 03/19/2010 12:31 AM, Hugh Daschbach wrote:
>>> The EMC multipath device handler should not change the I/O direction
>>> flags of its trespass command request.
...
>> Did you try the patch I linked to the last time you posted about this?
> I have not. When I read it, I believed it would fix the issue.
>> I think there should be a patch which fixes this problem here:
>> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=6c71dcb28ff9b63b814a0b76a256f5dae08d3e0d;hp=3a5b27bf6f29574d667230c7e76e4b83fe3014e0
>> I think it got into 2.6.34-rc1.
> Then I'll pull it and test it.
>> With that patch mode selects should get set up as writes.
>>
>> Does it work? If it does then I think we just need the attached cleanup
>> patch which removes the cmd_flags setting. The patch that got merged
>> fixed the problem of initializing the request properly, but it forgot to
>> remove the cmd_flags setting.
> Agree. I'll test it early next week and confirm.
I have pulled and tested this patch. It does fix my issue.
Thanks,
Hugh