lkml.org 
[lkml]   [2007]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [bug] block subsystem related crash with latest -git
    Il Wed, Oct 17, 2007 at 07:29:32PM +0200, Jens Axboe ha scritto: 
    > OK, it is fine, as long as the sglist is cleared initially. And I don't
    > think there's anyway around that, clearly I didn't think long enough
    > before including the memset() removal from Tomo.
    >
    > Ingo, please try this rolled up version.
    >
    > Linus, this should work. It would probably be best if you first did a
    > git revert on f5c0dde4c66421a3a2d7d6fa604a712c9b0744e5 and then applied
    > the ll_rw_blk.c bit alone. Do you want me to stuff that (revert + patch)
    > into a branch for you to pull?
    >
    > diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
    > index 9e3f3cc..3935469 100644
    > --- a/block/ll_rw_blk.c
    > +++ b/block/ll_rw_blk.c
    > @@ -1322,8 +1322,8 @@ int blk_rq_map_sg(struct request_queue *q, struct request *rq,
    > struct scatterlist *sglist)
    > {
    > struct bio_vec *bvec, *bvprv;
    > - struct scatterlist *next_sg, *sg;
    > struct req_iterator iter;
    > + struct scatterlist *sg;
    > int nsegs, cluster;
    >
    > nsegs = 0;
    > @@ -1333,7 +1333,7 @@ int blk_rq_map_sg(struct request_queue *q, struct request *rq,
    > * for each bio in rq
    > */
    > bvprv = NULL;
    > - sg = next_sg = &sglist[0];
    > + sg = NULL;
    > rq_for_each_segment(bvec, rq, iter) {
    > int nbytes = bvec->bv_len;
    >
    > @@ -1349,8 +1349,10 @@ int blk_rq_map_sg(struct request_queue *q, struct request *rq,
    > sg->length += nbytes;
    > } else {
    > new_segment:
    > - sg = next_sg;
    > - next_sg = sg_next(sg);
    > + if (!sg)
    > + sg = sglist;
    > + else
    > + sg = sg_next(sg);
    >
    > memset(sg, 0, sizeof(*sg));
    > sg->page = bvec->bv_page;
    > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
    > index 0c86be7..aac8a02 100644
    > --- a/drivers/scsi/scsi_lib.c
    > +++ b/drivers/scsi/scsi_lib.c
    > @@ -764,6 +764,8 @@ struct scatterlist *scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
    > if (unlikely(!sgl))
    > goto enomem;
    >
    > + memset(sgl, 0, sizeof(*sgl) * sgp->size);
    > +
    > /*
    > * first loop through, set initial index and return value
    > */
    >

    Hi Jens,
    I just hit what I believe is the same bug, though with a slightly
    different OOPS (I see a NULL pointer dereference, see below). The
    patches fixes the bug, and - as Linus suggested - the piece touching
    scsi_lib.c is enough.

    The OOPS:

    scsi4 : ata_piix
    scsi5 : ata_piix
    ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
    ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
    sda1 sda2 sda3 < sda5 sda6 >
    sd 0:0:0:0: [sda] Attached SCSI disk
    ata5.00: ATAPI: MATSHITADVD-RAM UJ-850S, 1.22, max UDMA/33
    Unable to handle kernel NULL pointer dereference at 0000000000000020 RIP:
    [<ffffffff802d275e>] blk_rq_map_sg+0xf6/0x16a
    PGD 4711067 PUD 508c067 PMD 0
    Oops: 0000 [1] PREEMPT SMP
    CPU 0
    Modules linked in: sd_mod ohci1394 ehci_hcd ata_piix ieee1394 ahci uhci_hcd libata scsi_mod usbcore thermal processor fan
    Pid: 0, comm: swapper Not tainted 2.6.23-ge6d5a11d #3
    RIP: 0010:[<ffffffff802d275e>] [<ffffffff802d275e>] blk_rq_map_sg+0xf6/0x16a
    RSP: 0018:ffffffff804eccd8 EFLAGS: 00010087
    RAX: 0000000005331000 RBX: ffff810004740220 RCX: ffff810001000000
    RDX: 0000000000000000 RSI: ffff8100052d4f50 RDI: 0000000005142c00
    RBP: 0000000000001400 R08: 0000000000000000 R09: ffff8100052a3980
    R10: 0000000005143000 R11: 0000000000000400 R12: ffff8100047a4000
    R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffffffff8049a000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 0000000000000020 CR3: 0000000005118000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper (pid: 0, threadinfo ffffffff804ac000, task ffffffff8046c340)
    Stack: ffffffff88041834 000000010314ba00 ffff81000477fa80 ffff81000503dd80
    ffff81000503dd80 ffff81000517fc00 000000000000001e 0000000000001d4c
    ffffffff8804193c 0000000015925849 ffff81000473f800 ffff81000503dd80
    Call Trace:
    <IRQ> [<ffffffff88041834>] :scsi_mod:scsi_alloc_sgtable+0xad/0x13c
    [<ffffffff8804193c>] :scsi_mod:scsi_init_io+0x79/0xd9
    [<ffffffff880d1328>] :sd_mod:sd_prep_fn+0x59/0x367
    [<ffffffff802d07ff>] elv_next_request+0xc0/0x14a
    [<ffffffff88042367>] :scsi_mod:scsi_request_fn+0x88/0x356
    [<ffffffff802d46f7>] blk_run_queue+0x41/0x72
    [<ffffffff88041135>] :scsi_mod:scsi_next_command+0x2d/0x39
    [<ffffffff880412ae>] :scsi_mod:scsi_end_request+0xbb/0xc9
    [<ffffffff880415ac>] :scsi_mod:scsi_io_completion+0xf8/0x2d3
    [<ffffffff802d4a83>] blk_done_softirq+0x62/0x6f
    [<ffffffff80238f28>] __do_softirq+0x59/0xc3
    [<ffffffff8020d13c>] call_softirq+0x1c/0x28
    [<ffffffff8020ec26>] do_softirq+0x2c/0x7d
    [<ffffffff80238e30>] irq_exit+0x36/0x81
    [<ffffffff8020edb4>] do_IRQ+0x13d/0x161
    [<ffffffff8020c491>] ret_from_intr+0x0/0xa
    <EOI> [<ffffffff88005249>] :processor:acpi_processor_idle+0x2cb/0x496
    [<ffffffff88005245>] :processor:acpi_processor_idle+0x2c7/0x496
    [<ffffffff88004f7e>] :processor:acpi_processor_idle+0x0/0x496
    [<ffffffff8020ad00>] default_idle+0x0/0x3d
    [<ffffffff8020adcd>] cpu_idle+0x90/0xcc
    [<ffffffff804b4a60>] start_kernel+0x2ab/0x2b7
    [<ffffffff804b411b>] _sinittext+0x11b/0x122


    Code: 49 8b 40 20 4d 8d 50 20 4c 89 c7 fc b9 08 00 00 00 4c 89 c3
    RIP [<ffffffff802d275e>] blk_rq_map_sg+0xf6/0x16a
    RSP <ffffffff804eccd8>
    CR2: 0000000000000020
    Kernel panic - not syncing: Aiee, killing interrupt handler!

    Luca
    --
    The trouble with computers is that they do what you tell them,
    not what you want.
    D. Cohen
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-17 22:19    [W:4.274 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site