On Sat, Feb 16 2008 at 2:41 +0200, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008 14:50:57 -0800
> Tim Pepper <[EMAIL PROTECTED]> wrote:
>
>> On Sat 16 Feb at 01:09:43 +0900 [EMAIL PROTECTED] said:
>>> The first one is just reverting the data buffer accessors
>>> conversion. It would be nice if we could just revert it but we
>>> can't. These changes are necessary to compile the driver against post
>>> 2.6.24.
>> Fujita-san,
>>
>> Unfortunately (and not too surprisingly given what we've tried so far) with
>> only the first of your series reverted the driver is working fine for me
>> again.
>
> Do you mean that you applied only the following two patches against
> 2.6.24, and then it doesn't work?
>
> 0001-ips-revert-the-changes-for-the-data-buffer-accessor.patch
> 0002-ips-kill-the-map_single-path-in-ips_scmd_buf_write.patch
>
> If so, the second patch is broken. Did you saw BUG_ON message (I added
> some BUG_ON to the patch)?
>
>
>> I saw (eg: replies to http://lkml.org/lkml/2007/5/11/132) some possibly
>> similar sounding issues with other drivers. Could there be some memory
>> uninitialised? I did try changing all the ips.c kmalloc's to kzalloc's,
>> but that didn't help. Also that thread ties into pci gart. The machines
>> we've been using are liable to getting pci calgary although given my
>> .config has:
>> CONFIG_GART_IOMMU=y
>> CONFIG_CALGARY_IOMMU=y
>> # CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT is not set
>> and that when booting this mainline I don't see any Calgary related
>> messages like I get from eg: Ubuntu's 2.6.22-14-server...I'm probably not
>> actually running the calgary iommu code in these repros.
>
> Yes, probabaly, your machine doesn't use any IOMMU hardware
> (nommu_map_sg function was in your crash log).
>
>
>> Anyway, I greatly appreciate your efforts so far in trying to find what
>> could be wrong here!
>
> Really sorry about the troubles and thanks for testing.
> -
Tomo hi
It looks like the same bug we had with USB's isd200 and protocol.c. An overflow
of a data buffer bigger then then the sglist. There 2 it was in the INQUIRY
command.
You just need to also check for sg != NULL in the for() loop.
Tim Please test below patch. It's ontop of 2.6.24 but should also apply to
2.6.25-rcx
Boaz
--
>From ec20bea25c9fe2400378b19c128b15fef3c7cbb6 Mon Sep 17 00:00:00 2001
From: Boaz Harrosh <[EMAIL PROTECTED]>
Date: Sun, 17 Feb 2008 14:50:25 +0200
Subject: [PATCH] ips: Avoid overflow in writing scsi command data
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 5c5a9b2..1d12253 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -3517,7 +3517,7 @@ 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++) {
+ (i < scsi_sg_count(scmd)) && (xfer_cnt < count) && sg; i++) {
min_cnt = min(count - xfer_cnt, sg[i].length);
/* kmap_atomic() ensures addressability of the data buffer.*/
--
1.5.3.3
-
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
