Re: [PATCH 6/9] scsi_dh: add generic SPC-3 alua handler

[Mike Christie <michaelc@cs.wisc.edu>]

Hannes Reinecke wrote:
> Mike Christie wrote:
>> Hannes Reinecke wrote:
>>> +
>>> +static struct request *get_alua_req(struct scsi_device *sdev,
>>> +                    void *buffer, unsigned buflen, int rw)
>>> +{
>>> +    struct request *rq;
>>> +    struct request_queue *q = sdev->request_queue;
>>> +
>>> +    rq = blk_get_request(q, rw, GFP_KERNEL);
>>> +
>>> +    if (!rq) {
>>> +        sdev_printk(KERN_INFO, sdev,
>>> +                "%s: blk_get_request failed\n", __FUNCTION__);
>>> +        return NULL;
>>> +    }
>>> +
>>> +    if (buflen && blk_rq_map_kern(q, rq, buffer, buflen, GFP_KERNEL)) {
>>> +        blk_put_request(rq);
>>> +        sdev_printk(KERN_INFO, sdev,
>>> +                "%s: blk_rq_map_kern failed\n", __FUNCTION__);
>>> +        return NULL;
>>> +    }
>>> +
>>> +    rq->cmd_type = REQ_TYPE_BLOCK_PC;
>>> +    rq->cmd_flags |= REQ_FAILFAST | REQ_NOMERGE;
>>> +    rq->retries = ALUA_FAILOVER_RETRIES;
>>> +    rq->timeout = ALUA_FAILOVER_TIMEOUT;
>>> +
>>> +    return rq;
>>> +}
>>
>>
>> It looks like this can be called from alua_activate, and we cannot use 
>> GFP_KERNEL in the same IO path something could get written to.
>>
> Is something like GFP_ATOMIC more appropriate?
> 


It will work. I thought we would want to have used GFP_NOIO though since 
we are running from work queue. I do not know why we have been using 
GFP_ATOMIC in the other handlers. Chandra?


Oh yeah, I was wondering what is up with EMC? Do they need a different 
alua handler? Is that needed to handle some quirks in it or something?