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