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?
--
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
