lkml.org 
[lkml]   [2006]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Slab corruption in 2.6.16-rc5-mm2
    On 3/6/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
    > On Monday 06 March 2006 21:06, Linus Torvalds wrote:
    > >
    <...snip...>
    > > and the scary thing is that "len=64".
    > >
    > > The thing is, SCSI uses "SCSI_SENSE_BUFFERSIZE" to determine the maximum
    > > sense size to copy, and what do we have, if not
    > >
    > > include/scsi/scsi_cmnd.h:#define SCSI_SENSE_BUFFERSIZE 96
    > >
    > > ie a 64-byte buffer is simply TOO DAMN SMALL!
    > >
    > > Now, the thing is, the 64 comes from "sizeof(struct request_sense)", which
    > > is what "struct packet_command *" uses. We can change that sizeof() to
    > > just use SCSI_SENSE_BUFFERSIZE, but that still makes me worry about
    >
    > Building a kernel with that change on top of the other ones atm.
    >
    Changing the sizeof() to SCSI_SENSE_BUFFERSIZE doesn't fix it :

    Slab corruption: start=f79da5a8, len=64
    Redzone: 0x5a2cf071/0x5a2cf071.
    Last user: [<c02934db>](sr_do_ioctl+0x11b/0x270)
    000: 70 00 02 00 00 00 00 0a 00 00 00 00 3a 01 00 00
    010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Prev obj: start=f79da55c, len=64
    Redzone: 0x170fc2a5/0x170fc2a5.
    Last user: [<c0158918>](__vmalloc_node+0x68/0x80)
    000: d0 1e 1e c3 18 1f 1e c3 60 1f 1e c3 a8 1f 1e c3
    010: f0 1f 1e c3 38 20 1e c3 80 20 1e c3 c8 20 1e c3
    Next obj: start=f79da5f4, len=64
    Redzone: 0x170fc2a5/0x170fc2a5.
    Last user: [<c0173923>](real_lookup+0x93/0xe0)
    000: 6c 69 62 62 6f 6f 73 74 5f 70 72 67 5f 65 78 65
    010: 63 5f 6d 6f 6e 69 74 6f 72 2d 67 63 63 2d 6d 74
    Slab corruption: start=f79da5a8, len=64
    Redzone: 0x5a2cf071/0x5a2cf071.
    Last user: [<c02934db>](sr_do_ioctl+0x11b/0x270)
    000: 70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00
    010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Prev obj: start=f79da55c, len=64
    Redzone: 0x170fc2a5/0x170fc2a5.
    Last user: [<c0158918>](__vmalloc_node+0x68/0x80)
    000: d0 1e 1e c3 18 1f 1e c3 60 1f 1e c3 a8 1f 1e c3
    010: f0 1f 1e c3 38 20 1e c3 80 20 1e c3 c8 20 1e c3
    Next obj: start=f79da5f4, len=64
    Redzone: 0x170fc2a5/0x170fc2a5.
    Last user: [<c0173923>](real_lookup+0x93/0xe0)
    000: 6c 69 62 62 6f 6f 73 74 5f 70 72 67 5f 65 78 65
    010: 63 5f 6d 6f 6e 69 74 6f 72 2d 67 63 63 2d 6d 74

    I'll now go test the things Jens suggested. Expect more feedback shortly.

    --
    Jesper Juhl <jesper.juhl@gmail.com>
    Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
    Plain text mails only, please http://www.expita.com/nomime.html
    -
    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: 2006-03-06 22:40    [W:4.224 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site