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

[Chandra Seetharaman <sekharan@us.ibm.com>]

On Fri, 2008-06-27 at 10:51 -0500, Mike Christie wrote:
> 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?

Mike,

I do not recall discussing about this. But, my memory is not that good
anyways :)...

As it stands now, the current code is all GFP_ATOMIC. I agree with you
that the workqueue allocs could be made GFP_NOIO. I can roll up a patch
(on top of Hannes's) to fix those.

Thanks,

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?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html