[lkml]   [1998]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Corrupt file-system(s) leads to crash
       Date: 	Mon, 6 Apr 1998 21:34:35 -0400 (EDT)
    From: "Albert D. Cahalan" <>

    Some people are reporting related troubles with corrupted partition
    tables getting even more corrupted:

    1. fdisk puts extended partition info _in_ the previous partition
    2. mke2fs does not sanity check
    3. the kernel partition code does not sanity check
    4. somebody fills up the filesystem
    5. goodbye partitions!

    It's not as serious as your disk destruction, but the solution is
    the same. Partition size and location must be sanity checked when
    the partition table is read. Partition access must be bounds checked.

    Partition access are bounds checked. The problem was that the partition
    bounds were incorrect. We could say that the kernel partition code
    should have done that sanity check, but there are even potentially times
    when overlapping partitions is the right thing.

    The real problem is that some versions of fdisk, when creating
    non-contiguous extended partitions, can create overlapping partitions
    when the user didn't request it. This is a real bug, and given that
    there's known bad versions of fdisk out there, it might make sense to
    try to detect that, especially in the kernel code which reads partition

    Having mke2fs do the sanity check would be a nasty abstraction
    violation, and there isn't even a good way to do it, short of having
    mke2fs read the partition label itself. Currently mke2fs and the rest
    of e2fsprogs tools suite are partition label independent. If you want
    to use a BSD disk label instead of the standard partition table, you can
    do so, and the ext2 tools will work just fine. On an Sparcstation, if
    you want to use a Solaris compatible disk label, that will work fine
    too. So having mke2fs do the sanity check would force it to be
    partition label specific, and it's not at all clear this would be a good
    thing to do....

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.020 / U:6.532 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site