Re: [PATCH] scsi: sg: fix SG_DXFER_FROM_DEV transfers

[Johannes Thumshirn <jthumshirn@suse.de>]

On Thu, Jul 06, 2017 at 02:47:22PM -0400, Douglas Gilbert wrote:
> Can you check your patch with one of the utilities from sg3_utils
> such as sg_inq which will use SG_DXFER_FROM_DEV with the newer
> interface?

Correct, this patch broke sg_inq. I'll send a corrected v2.

> BTW I'm not sure why dxferp is set to NULL for SG_DXFER_FROM_DEV
> transfers; perhaps some magic done by the block layer. Maybe a
> comment in the code (e.g. on line 654) would help.

This is due to:

commit fad7f01e61bf737fe8a3740d803f000db57ecac6
Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date:   Tue Sep 2 16:20:20 2008 +0900

    sg: set dxferp to NULL for READ with the older SG interface
    
    With the older SG interface, we don't know a user-space address to
    trasfer data when executing a SCSI command. So we can't pass a
    user-space address to blk_rq_map_user.
    
    This patch fixes sg to pass a NULL user-space address to
    blk_rq_map_user so that it just sets up a request and bios with page
    frames propely without data transfer.
    
    Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
    Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

> 
> Also sg_is_valid_dxfer() is only called once and is more complex
> than it looks; so perhaps it could be inlined back in
> sg_common_write().

The compiler will inline it anyways (at least the one I checked with) and
inlining it into sg_common_write() won't make the code more readable IMHO. But
ultimately it's your driver so if you insist I'll do.

-- 
Johannes Thumshirn                                          Storage
jthumshirn@suse.de                                +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850