ACK

Other RAID drivers (eg: aacraid) makes the assumption that commands in these 
paths (INQUIRY, READ CAPACITY, MODE SENSE etc spoofing) are single scatter 
gather elements and have yet to be bitten. I agree with Fujita-san about the 
practical unlikelihood. The fix does not incur any change in code overhead, so 
it is worth hardening!

Can one create a request via /dev/sg for a buffer smaller than 256 and manage 
to create a multi-element scatter gather?

Sincerely -- Mark Salyzyn

> -----Original Message-----
> From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 19, 2008 4:42 AM
> To: [EMAIL PROTECTED]
> Cc: linux-scsi@vger.kernel.org; Salyzyn, Mark;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH] ips: sg chaining support to the path to non
> I/O commands
>
> Here is another ips patch, but not a bug fix.
>
> =
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [PATCH] ips: sg chaining support to the path to non
> I/O commands
>
> I overlooked ips_scmd_buf_write and ips_scmd_buf_read when I converted
> ips to use the data buffer accessors.
>
> ips is unlikely to use sg chaining (especially in this path) since a)
> this path is used only for non I/O commands (with little data
> transfer), b) ips's sg_tablesize is set to just 17.
>
> Thanks to Tim Pepper for testing this patch.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> Cc: Salyzyn, Mark <[EMAIL PROTECTED]>
> Cc: James Bottomley <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/ips.c |   18 ++++++++++--------
>  1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
> index 7ed568f..e5467a4 100644
> --- a/drivers/scsi/ips.c
> +++ b/drivers/scsi/ips.c
> @@ -3510,15 +3510,16 @@ ips_scmd_buf_write(struct scsi_cmnd
> *scmd, void *data, unsigned int count)
>          struct scatterlist *sg = scsi_sglist(scmd);
>
>          for (i = 0, xfer_cnt = 0;
> -             (i < scsi_sg_count(scmd)) && (xfer_cnt < count); i++) {
> -                min_cnt = min(count - xfer_cnt, sg[i].length);
> +       (i < scsi_sg_count(scmd)) && (xfer_cnt < count);
> +             i++, sg = sg_next(sg)) {
> +                min_cnt = min(count - xfer_cnt, sg->length);
>
>                  /* kmap_atomic() ensures addressability of
> the data buffer.*/
>                  /* local_irq_save() protects the KM_IRQ0
> address slot.     */
>                  local_irq_save(flags);
> -                buffer = kmap_atomic(sg_page(&sg[i]),
> KM_IRQ0) + sg[i].offset;
> +               buffer = kmap_atomic(sg_page(sg), KM_IRQ0) +
> sg->offset;
>                  memcpy(buffer, &cdata[xfer_cnt], min_cnt);
> -                kunmap_atomic(buffer - sg[i].offset, KM_IRQ0);
> +               kunmap_atomic(buffer - sg->offset, KM_IRQ0);
>                  local_irq_restore(flags);
>
>                  xfer_cnt += min_cnt;
> @@ -3543,15 +3544,16 @@ ips_scmd_buf_read(struct scsi_cmnd
> *scmd, void *data, unsigned int count)
>          struct scatterlist *sg = scsi_sglist(scmd);
>
>          for (i = 0, xfer_cnt = 0;
> -             (i < scsi_sg_count(scmd)) && (xfer_cnt < count); i++) {
> -                min_cnt = min(count - xfer_cnt, sg[i].length);
> +             (i < scsi_sg_count(scmd)) && (xfer_cnt < count);
> +             i++, sg = sg_next(sg)) {
> +               min_cnt = min(count - xfer_cnt, sg->length);
>
>                  /* kmap_atomic() ensures addressability of
> the data buffer.*/
>                  /* local_irq_save() protects the KM_IRQ0
> address slot.     */
>                  local_irq_save(flags);
> -                buffer = kmap_atomic(sg_page(&sg[i]),
> KM_IRQ0) + sg[i].offset;
> +               buffer = kmap_atomic(sg_page(sg), KM_IRQ0) +
> sg->offset;
>                  memcpy(&cdata[xfer_cnt], buffer, min_cnt);
> -                kunmap_atomic(buffer - sg[i].offset, KM_IRQ0);
> +               kunmap_atomic(buffer - sg->offset, KM_IRQ0);
>                  local_irq_restore(flags);
>
>                  xfer_cnt += min_cnt;
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to