Re: [PATCH 2.6.23-rc6-mm1] - Panic in blk_rq_map_sg() from CCISS driver
On Thu, Sep 20 2007, Lee Schermerhorn wrote: > PATCH 2.6.23-rc6-mm1 - Panic in blk_rq_map_sg() from CCISS driver > > New scatter/gather list chaining [sg_next()] treats 'page' member of > struct scatterlist with low bit set [0x01] as a chain pointer to > another struct scatterlist [array]. The CCISS driver request function > passes an uninitialized, temporary, on-stack scatterlist array to > blk_rq_map_sq(). sg_next() interprets random data on the stack as a > chain pointer and eventually tries to de-reference an invalid pointer, > resulting in: > > [] blk_rq_map_sg+0x70/0x170 > PGD 6090c3067 PUD 0 > Oops: [1] SMP > last sysfs file: /block/cciss!c0d0/cciss!c0d0p1/dev > CPU 6 > Modules linked in: ehci_hcd ohci_hcd uhci_hcd > Pid: 1, comm: init Not tainted 2.6.23-rc6-mm1 #3 > RIP: 0010:[] [] blk_rq_map_sg+0x70/0x170 > RSP: 0018:81060901f768 EFLAGS: 00010206 > RAX: 00040b161000 RBX: 81060901f7d8 RCX: 00040b162c00 > RDX: RSI: 81060b13a260 RDI: 81060b139600 > RBP: 1400 R08: fffe R09: 0400 > R10: R11: 00040b163000 R12: 810102fe > R13: 0001 R14: 0001 R15: 1e00 > FS: 026108f0(0063) GS:810409000b80() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 0001001e CR3: 0006090c6000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process init (pid: 1, threadinfo 81060901e000, task 810409020800) > last branch before last exception/interrupt > from [] blk_rq_map_sg+0x10a/0x170 > to [] blk_rq_map_sg+0x70/0x170 > Stack: 00018068ea00 810102fe 81001140 > 0002 81040b172000 803acd3d > 3ec1 8106090d5000 8106090d5000 810102fe > Call Trace: > [] do_cciss_request+0x15d/0x4c0 > [] new_slab+0x1c8/0x270 > [] __slab_alloc+0x22d/0x470 > [] mempool_alloc+0x4b/0x130 > [] cfq_set_request+0xee/0x380 > [] mempool_alloc+0x4b/0x130 > [] get_request+0x168/0x360 > [] rb_insert_color+0x8d/0x110 > [] elv_rb_add+0x58/0x60 > [] cfq_add_rq_rb+0x69/0xa0 > [] elv_merged_request+0x5b/0x60 > [] __make_request+0x23d/0x650 > [] __slab_alloc+0x22d/0x470 > [] generic_write_checks+0x140/0x190 > [] generic_make_request+0x1c2/0x3a0 > > Kernel panic - not syncing: Attempted to kill init! > > This patch initializes the tmp_sg array to zeroes. Perhaps not the ultimate > fix, but an effective work-around. I can now boot 23-rc6-mm1 on an HP > Proliant x86_64 with CCISS boot disk. > > Signed-off-by: Lee Schermerhorn <[EMAIL PROTECTED]> > > drivers/block/cciss.c |1 + > 1 file changed, 1 insertion(+) > > Index: Linux/drivers/block/cciss.c > === > --- Linux.orig/drivers/block/cciss.c 2007-09-20 14:59:29.0 -0400 > +++ Linux/drivers/block/cciss.c 2007-09-20 15:06:39.0 -0400 > @@ -2611,6 +2611,7 @@ static void do_cciss_request(struct requ > (int)creq->nr_sectors); > #endif /* CCISS_DEBUG */ > > + memset(tmp_sg, 0, sizeof(tmp_sg)); > seg = blk_rq_map_sg(q, creq, tmp_sg); > > /* get the DMA records for the setup */ > Thanks Lee, applied. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc6-mm1] - Panic in blk_rq_map_sg() from CCISS driver
On Thu, Sep 20 2007, Lee Schermerhorn wrote: PATCH 2.6.23-rc6-mm1 - Panic in blk_rq_map_sg() from CCISS driver New scatter/gather list chaining [sg_next()] treats 'page' member of struct scatterlist with low bit set [0x01] as a chain pointer to another struct scatterlist [array]. The CCISS driver request function passes an uninitialized, temporary, on-stack scatterlist array to blk_rq_map_sq(). sg_next() interprets random data on the stack as a chain pointer and eventually tries to de-reference an invalid pointer, resulting in: [8031dd70] blk_rq_map_sg+0x70/0x170 PGD 6090c3067 PUD 0 Oops: [1] SMP last sysfs file: /block/cciss!c0d0/cciss!c0d0p1/dev CPU 6 Modules linked in: ehci_hcd ohci_hcd uhci_hcd Pid: 1, comm: init Not tainted 2.6.23-rc6-mm1 #3 RIP: 0010:[8031dd70] [8031dd70] blk_rq_map_sg+0x70/0x170 RSP: 0018:81060901f768 EFLAGS: 00010206 RAX: 00040b161000 RBX: 81060901f7d8 RCX: 00040b162c00 RDX: RSI: 81060b13a260 RDI: 81060b139600 RBP: 1400 R08: fffe R09: 0400 R10: R11: 00040b163000 R12: 810102fe R13: 0001 R14: 0001 R15: 1e00 FS: 026108f0(0063) GS:810409000b80() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0001001e CR3: 0006090c6000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process init (pid: 1, threadinfo 81060901e000, task 810409020800) last branch before last exception/interrupt from [8031de0a] blk_rq_map_sg+0x10a/0x170 to [8031dd70] blk_rq_map_sg+0x70/0x170 Stack: 00018068ea00 810102fe 81001140 0002 81040b172000 803acd3d 3ec1 8106090d5000 8106090d5000 810102fe Call Trace: [803acd3d] do_cciss_request+0x15d/0x4c0 [80298968] new_slab+0x1c8/0x270 [80298ffd] __slab_alloc+0x22d/0x470 [8027327b] mempool_alloc+0x4b/0x130 [8032b21e] cfq_set_request+0xee/0x380 [8027327b] mempool_alloc+0x4b/0x130 [8031ff98] get_request+0x168/0x360 [80331b0d] rb_insert_color+0x8d/0x110 [8031cfd8] elv_rb_add+0x58/0x60 [8032a329] cfq_add_rq_rb+0x69/0xa0 [8031c1ab] elv_merged_request+0x5b/0x60 [803224fd] __make_request+0x23d/0x650 [80298ffd] __slab_alloc+0x22d/0x470 [8027] generic_write_checks+0x140/0x190 [8031f012] generic_make_request+0x1c2/0x3a0 etc Kernel panic - not syncing: Attempted to kill init! This patch initializes the tmp_sg array to zeroes. Perhaps not the ultimate fix, but an effective work-around. I can now boot 23-rc6-mm1 on an HP Proliant x86_64 with CCISS boot disk. Signed-off-by: Lee Schermerhorn [EMAIL PROTECTED] drivers/block/cciss.c |1 + 1 file changed, 1 insertion(+) Index: Linux/drivers/block/cciss.c === --- Linux.orig/drivers/block/cciss.c 2007-09-20 14:59:29.0 -0400 +++ Linux/drivers/block/cciss.c 2007-09-20 15:06:39.0 -0400 @@ -2611,6 +2611,7 @@ static void do_cciss_request(struct requ (int)creq-nr_sectors); #endif /* CCISS_DEBUG */ + memset(tmp_sg, 0, sizeof(tmp_sg)); seg = blk_rq_map_sg(q, creq, tmp_sg); /* get the DMA records for the setup */ Thanks Lee, applied. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
