From: Douglas Gilbert <dgilbert@interlog.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: jens.axboe@oracle.com, linux-scsi@vger.kernel.org, sxzzsf@gmail.com
Subject: Re: [PATCH] block: fix sg SG_DXFER_TO_FROM_DEV regression
Date: Thu, 09 Jul 2009 02:19:22 +0200 [thread overview]
Message-ID: <4A55378A.7060808@interlog.com> (raw)
In-Reply-To: <20090706161004D.fujita.tomonori@lab.ntt.co.jp>
FUJITA Tomonori wrote:
> I overlooked SG_DXFER_TO_FROM_DEV support when I converted sg to use
> the block layer mapping API (2.6.28).
>
> Douglas Gilbert explained SG_DXFER_TO_FROM_DEV:
>
> http://www.spinics.net/lists/linux-scsi/msg37135.html
>
> =
> The semantics of SG_DXFER_TO_FROM_DEV were:
> - copy user space buffer to kernel (LLD) buffer
> - do SCSI command which is assumed to be of the DATA_IN
> (data from device) variety. This would overwrite
> some or all of the kernel buffer
> - copy kernel (LLD) buffer back to the user space.
>
> The idea was to detect short reads by filling the original
> user space buffer with some marker bytes ("0xec" it would
> seem in this report). The "resid" value is a better way
> of detecting short reads but that was only added this century
> and requires co-operation from the LLD.
> =
>
> This patch changes the block layer mapping API to support this
> semantics. This simply adds another field to struct rq_map_data and
> enables __bio_copy_iov() to copy data from user space even with READ
> requests.
>
> It's better to add the flags field and kills null_mapped and the new
> from_user fields in struct rq_map_data but that approach makes it
> difficult to send this patch to stable trees because st and osst
> drivers use struct rq_map_data (they were converted to use the block
> layer in 2.6.29 and 2.6.30). Well, I should clean up the block layer
> mapping API.
>
> zhou sf reported this regiression and tested this patch:
>
> http://www.spinics.net/lists/linux-scsi/msg37128.html
> http://www.spinics.net/lists/linux-scsi/msg37168.html
Wrote my own little test program and it gave the wrong
result (as reported by zhou sf) in lk 2.6.30 . When
this patch was applied, the expected result (i.e. a
response with user supplied fill characters) was observed.
Here is an INQUIRY response set up for a length of
128 bytes with an 0xec fill character:
$ ./sg_dxfer_to_from
resid indicates that 96 bytes returned in response
00 00 00 05 02 5b 00 10 0a 4c 69 6e 75 78 20 20 20
10 73 63 73 69 5f 64 65 62 75 67 20 20 20 20 20 20
20 30 30 30 34 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 00 00 00 00 00 00 00 77 03 14 03 3d
40 0c 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec
70 ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
next prev parent reply other threads:[~2009-07-09 0:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-06 7:10 [PATCH] block: fix sg SG_DXFER_TO_FROM_DEV regression FUJITA Tomonori
2009-07-09 0:19 ` Douglas Gilbert [this message]
2009-07-09 0:22 ` FUJITA Tomonori
2009-07-09 12:47 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A55378A.7060808@interlog.com \
--to=dgilbert@interlog.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=sxzzsf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.