Re: [PATCH] Possible EXT2 File System Corruption in Kernel 2.4

[Andreas Dilger]

On May 20, 2002  11:38 +0200, Juan Quintela wrote:
> >>>>> "andreas" == Andreas Dilger <[e-mail]> writes:
> andreas> diff -ru linux-2.4.18.orig/fs/ext2/balloc.c linux-2.4.18-aed/fs/ext2/balloc.c
> andreas> --- linux-2.4.18.orig/fs/ext2/balloc.c	Wed Feb 27 10:31:58 2002
> andreas> +++ linux-2.4.18-aed/fs/ext2/balloc.c	Mon Mar 18 17:07:55 2002
> andreas> @@ -269,7 +269,8 @@
> andreas> }
> andreas> lock_super (sb);
> andreas> es = sb->u.ext2_sb.s_es;
> andreas> -	if (block < le32_to_cpu(es->s_first_data_block) || 
> andreas> +	if (block < le32_to_cpu(es->s_first_data_block) ||
> andreas> +	    block + count < block ||
> 
> It is just me, or this will allways be false?  A fast grep shows that
> count is always bigger than 1. Same for the ext3 part.

Well, under normal operation this test will never be true (same as the
other tests there), but it appears that in some cases there _are_ values
of "block + count" which pass this test but fail later on.  I don't know
the exact source of the problem, but it appears to happen when "block"
is -1, and "block + count" is then 0, which does not trigger the
existing tests (s_first_data_block is 0 for 4kB filesystems).

It is likely that block is being set as -EPERM or something like that,
but I'm not sure.  In any case, you can check l-k archives for the
original emails on this thread where the users report trying to access
group 131071, which is 2^32 / 32768 (i.e. -1 / number of blocks per
group for a 4kB block ext2 filesystem).

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/