[lkml]   [2002]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OOPS caused by ext2 changes
    Dave Hansen wrote:
    > Andrew Morton and I discused this earlier. I have some more information
    > now. The problem: "dbench 64" run on a small (~120meg) partition with
    > 1k block sizes produces Oopses.
    > This changeset:
    > is the culprit. Without it applied, none of this happens.

    It's vaguely surprising that that chunk is associated with the

    However it seems that there's potential for a buffer reference
    leak in ext2_get_branch:

    while (--depth) {
    bh = sb_bread(sb, le32_to_cpu(p->key));
    if (!bh)
    goto failure;
    /* Reader: pointers */
    if (!verify_chain(chain, p))
    goto changed;
    add_chain(++p, bh, (u32*)bh->b_data + *++offsets);
    /* Reader: end */
    if (!p->key)
    goto no_block;
    return NULL;

    *err = -EAGAIN;
    goto no_block;
    *err = -EIO;
    return p;

    See, sb_bread() bumps b_count, but on the `goto changed;'
    branch we lose track of that buffer.

    b_count is only 16 bits, so it's conceivable that the
    count wraps to zero, and that is fatal.

    It would be interesting to replace that `goto changed;'
    with { __brelse(bh); goto changed; }. Plus maybe a
    debug printk to see if we are indeed hitting that path.

    I don't think this is the bug actually - if we were
    leaking bh refs that easily we'd get `busy buffer'
    whines at unmount. But it merits investigation.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:25    [W:0.030 / U:10.516 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site