From: FUJITA Tomonori <tomof@acm.org>
To: stern@rowland.harvard.edu
Cc: fujita.tomonori@lab.ntt.co.jp, tomof@acm.org,
bharrosh@panasas.com, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org,
James.Bottomley@HansenPartnership.com, jens.axboe@oracle.com,
dougg@torque.net, Geert.Uytterhoeven@sonycom.com,
tony.luck@intel.com, Mark_Salyzyn@adaptec.com,
ed.lin@promise.com, linuxraid@amcc.com,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 00/10] sg buffer copy helper functions
Date: Mon, 17 Mar 2008 12:23:55 +0900 [thread overview]
Message-ID: <20080317122350F.tomof@acm.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0803161304240.4171-100000@iolanthe.rowland.org>
On Sun, 16 Mar 2008 13:18:07 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sun, 16 Mar 2008, FUJITA Tomonori wrote:
>
> > On Fri, 14 Mar 2008 10:46:52 -0400 (EDT)
> > Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > > On Fri, 14 Mar 2008, FUJITA Tomonori wrote:
> > >
> > > > > If nents doesn't change then for_each_sg() won't work right. There
> > > > > could be an alternative macro:
> > > >
> > > > Oops, I thought that for_each_sg is defined like:
> > > >
> > > > #define for_each_sg(sglist, sg, nr, __i) \
> > > > for (__i = 0, sg = (sglist); __i < (nr) && sg; __i++, sg = sg_next(sg))
> > > >
> > > >
> > > > > /*
> > > > > * Loop over each sg element, stopping at the end of the chain
> > > > > */
> > > > > #define for_each_sg_all(sglist, sg, __i) \
> > > > > for (__i = 0, sg = (sglist); sg; __i++, sg = sg_next(sg))
> > > > >
> > > > > If you added this macro to include/linux/scatterlist.h and used it
> > > > > instead of for_each_sg() then you can get rid of nents entirely.
> > > > > However I'm not sure whether this would be safe. Do people sometimes
> > > > > use a subset of the entries in a scatterlist?
> > > >
> > > > IIRC, some drivers do that (though they might use sg_next).
> > >
> > > But will usb-storage ever receive a scatterlist like that? For
> > > example, if there are three 4096-byte entries in the list, but the
> > > transfer length is 8192 and nents is 2, then there could be a problem.
> >
> > If LLDs don't use the padding or drain buffer feature (USB uses
> > neither), scsi midlayer doesn't send such (that is, the block layer
> > doesn't create such).
>
> Then it should be okay to open-code that loop and test whether sg is
> NULL.
>
> > As I explained above, it should be safe with USB. But in general, LLDs
> > should not rely on a scatterlist about how much data they transfer.
>
> True. Let's add a comment explaining the situation. For example:
>
> /* If this routine is called multiple times for a single
> * scatterlist, the nents value will not be updated properly.
> * Transfers will stop when the end of the list is reached,
> * which might not be correct in cases where nents is less than
> * the actual number of entries in the list. However, if
> * drivers are careful not to use multiple calls to transfer
> * more data than was requested then this will be safe.
> */
> for (sg = *sgl; nents > 0 && sg; --nents, sg = sg_next(sg)) {
>
> When this change is made, we will be able to convert usb-storage over
> to using your library routine.
For me, it would be much better to fix USB drivers since LLDs should
not rely on a scatterlist about how much data they transfer, as I
said. If LLDs do that, they are broken. It's not good to add such a
workaround to the common API for broken LLDs.
USB drivers should do something like this if they definitely need to
call this API multiple times:
done = sg_copy_buffer(buffer, scsi_bufflen(sc) - us->done_length,
us->done_length += done;
next prev parent reply other threads:[~2008-03-17 3:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-09 4:44 [PATCH 00/10] sg buffer copy helper functions FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 01/10] block: add " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 02/10] scsi: add wrapper functions for " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 03/10] scsi_debug: use " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 04/10] ps3rom: use sg buffer copy helper funcitons FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 05/10] simscsi: " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 06/10] ips: " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 07/10] aacraid: use sg buffer copy helper functions FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 08/10] stex: " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 09/10] 3w-xxxx: " FUJITA Tomonori
2008-03-09 4:44 ` [PATCH 10/10] 3w-9xxx: " FUJITA Tomonori
2008-03-10 12:45 ` [PATCH 07/10] aacraid: " Mark Salyzyn
2008-03-10 12:46 ` [PATCH 06/10] ips: use sg buffer copy helper funcitons Mark Salyzyn
2008-03-10 10:15 ` [PATCH 04/10] ps3rom: " Geert Uytterhoeven
2008-03-10 14:37 ` [PATCH 01/10] block: add sg buffer copy helper functions Jens Axboe
2008-03-10 10:14 ` [PATCH 00/10] " Geert Uytterhoeven
2008-03-10 14:34 ` FUJITA Tomonori
[not found] ` <1205037877-12843-1-git-send-email-fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2008-03-10 14:10 ` Boaz Harrosh
2008-03-10 22:39 ` FUJITA Tomonori
2008-03-11 10:05 ` Boaz Harrosh
2008-03-11 20:09 ` Alan Stern
2008-03-12 0:14 ` FUJITA Tomonori
2008-03-12 0:28 ` FUJITA Tomonori
2008-03-12 2:24 ` FUJITA Tomonori
2008-03-12 16:04 ` Alan Stern
2008-03-13 0:03 ` FUJITA Tomonori
2008-03-13 0:18 ` FUJITA Tomonori
2008-03-13 18:34 ` Alan Stern
2008-03-12 16:01 ` Alan Stern
2008-03-12 16:26 ` Boaz Harrosh
2008-03-13 0:03 ` FUJITA Tomonori
2008-03-13 18:32 ` Alan Stern
2008-03-14 9:35 ` FUJITA Tomonori
[not found] ` <20080314183434J.tomof-HInyCGIudOg@public.gmane.org>
2008-03-14 14:46 ` Alan Stern
2008-03-16 11:55 ` FUJITA Tomonori
2008-03-16 17:18 ` Alan Stern
2008-03-17 3:23 ` FUJITA Tomonori [this message]
2008-03-17 14:06 ` Alan Stern
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=20080317122350F.tomof@acm.org \
--to=tomof@acm.org \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Mark_Salyzyn@adaptec.com \
--cc=bharrosh@panasas.com \
--cc=dougg@torque.net \
--cc=ed.lin@promise.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jens.axboe@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxraid@amcc.com \
--cc=stern@rowland.harvard.edu \
--cc=tony.luck@intel.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.