Re: sgpool-8 double free

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

James Bottomley wrote:
> On Sun, 2006-02-19 at 15:29 -0500, Dave Jones wrote:
> 
>>Feb 18 22:30:18 fgrbhw01 kernel: ieee1394: sbp2: Logged into SBP-2 device
>>Feb 18 22:30:18 fgrbhw01 kernel:   Vendor: Initio    Model: 0KLAT80          Rev: 2.05
>>Feb 18 22:30:18 fgrbhw01 kernel:   Type:   Direct-Access                     ANSI SCSI revision: 00
>>Feb 18 22:30:18 fgrbhw01 kernel: SCSI device sdb: 781422768 512-byte hdwr sectors (400088 MB)
>>Feb 18 22:30:18 fgrbhw01 kernel: slab error in cache_free_debugcheck(): cache `sgpool-8': double free, or memory outside object was overwritten
>>Feb 18 22:30:18 fgrbhw01 kernel:  [<c014d8bf>] cache_free_debugcheck+0xce/0x1b9
>>    [<c01486cb>] mempool_free+0x5f/0x63
>>Feb 18 22:30:18 fgrbhw01 kernel:  [<c014e230>] kmem_cache_free+0x2a/0x5c    
>>[<c01486cb>] mempool_free+0x5f/0x63
>>Feb 18 22:30:18 fgrbhw01 kernel:  [<f8864f65>] scsi_io_completion+0x65/0x3ce
>>[scsi_mod]     [<f8860bb3>] scsi_finish_command+0xb8/0xbd [scsi_mod]
>>Feb 18 22:30:18 fgrbhw01 kernel:  [<f8860ab6>] scsi_softirq+0x109/0x128
> 
> 
> This is a characteristic trace for double done() on the same SCSI
> command.

Perhaps. OTOH, maybe there was indeed memory overwritten. SBP-2 targets 
write data into the PC's memory anywhere they see fit, without driver 
intervention. So IMO it is possible that a buggy target writes outside 
of the response data buffer.

I have an Initio based bridge which also claims to implement type 
"Direct-Access". After this device receives a mode_sense command, my 
system reboots straight away (kernel panic while in interrupt; I 
reported it in the thread "TYPE_RBC cache fixes (sbp2.c affected)").

I did not have the time to debug it yet. But at least the very latest 
1394 drivers flag the affected device for BLIST_MS_SKIP_PAGE_08 which 
avoids mode_sense to be sent by sd_mod, thus avoids the panic. Patch: 
"sbp2: update 36byte inquiry workaround (fix compatibility regression)"
http://www.kernel.org/git/?p=linux/kernel/git/scjody/ieee1394.git;a=commit;h=99496037c6744fd938ffb8ccfc8fc91762322ff8
(The skip-page-08 part was actually added for a different bridge with a 
different problem.)

As I can see from the log in the bug report, sbp2's blacklist will also 
spring into action for the reporter's device.

The mentioned patch applies to 2.6.16-rc1 or later. Users of 2.6.14 and 
2.6.15 may apply it by means of rediffs which I provide: 
http://me.in-berlin.de/~s5r6/linux1394/updates/
However instead of patching sbp2, the BLIST_MS_SKIP_PAGE_08 workaround 
can certainly also be enabled by feeding it into scsi_mod's dev_flags 
parameter or default_dev_flags parameter. I guess the syntax would be 
something like
# modprobe scsi_mod dev_flags=Initio:0KLAT80:8192
or
# modprobe scsi_mod default_dev_flags=8192
before sbp2 and scsi_mod are loaded or
# echo 8192 > /sys/module/scsi_mod/parameters/default_dev_flags
when scsi_mod is loaded but before the disk is connected. (Note, I never 
tried setting these parameters myself. Correct me if I got it wrong.)

I will add a pointer to this posting to bugzilla.redhat.com.
-- 
Stefan Richter
-=====-=-==- --=- =--==
http://arcgraph.de/sr/