Re: [PATCH 2/2] block,scsi: convert and handle ERR_PTR from blk_get_request

[Jeff Moyer]

Joe Lawrence <joe.lawrence@xxxxxxxxxxx> writes:

> diff --git a/block/bsg.c b/block/bsg.c
> index 420a5a9..2b1c322 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -271,8 +271,8 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr, fmode_t has_write_perm,
>  	 * map scatter-gather elements separately and string them to request
>  	 */
>  	rq = blk_get_request(q, rw, GFP_KERNEL);
> -	if (!rq)
> -		return ERR_PTR(-ENOMEM);
> +	if (IS_ERR(rq))
> +		return rq;
>  	ret = blk_fill_sgv4_hdr_rq(q, rq, hdr, bd, has_write_perm);
>  	if (ret)
>  		goto out;
> @@ -284,8 +284,8 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr, fmode_t has_write_perm,
>  		}
>  
>  		next_rq = blk_get_request(q, READ, GFP_KERNEL);
> -		if (!next_rq) {
> -			ret = -ENOMEM;
> +		if (IS_ERR(next_rq)) {
> +			ret = PTR_ERR(rq);

ITYM ret = PTR_ERR(next_rq), right?

> diff --git a/drivers/scsi/device_handler/scsi_dh_hp_sw.c b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
> index 084062b..1cf4019 100644
> --- a/drivers/scsi/device_handler/scsi_dh_hp_sw.c
> +++ b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
> @@ -117,7 +117,7 @@ static int hp_sw_tur(struct scsi_device *sdev, struct hp_sw_dh_data *h)
>  
>  retry:
>  	req = blk_get_request(sdev->request_queue, WRITE, GFP_NOIO);
> -	if (!req)
> +	if (IS_ERR(req))
>  		return SCSI_DH_RES_TEMP_UNAVAIL;
>  

Don't we have an opportunity here to differentiate between enomem and
eio?  I have no idea what the right SCSI_DH error would be, I'm just
asking the question.

>  	req->cmd_type = REQ_TYPE_BLOCK_PC;
> @@ -247,7 +247,7 @@ static int hp_sw_start_stop(struct hp_sw_dh_data *h)
>  	struct request *req;
>  
>  	req = blk_get_request(h->sdev->request_queue, WRITE, GFP_ATOMIC);
> -	if (!req)
> +	if (IS_ERR(req))
>  		return SCSI_DH_RES_TEMP_UNAVAIL;

Same goes here.

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/