From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Divide by Zero in Linux 2.4.31 and 2.6.14 Date: Thu, 3 Nov 2005 11:08:07 -0700 Message-ID: <20051103180807.GP31368@schatzie.adilger.int> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from moraine.clusterfs.com ([66.96.26.190]:18062 "EHLO moraine.clusterfs.com") by vger.kernel.org with ESMTP id S1030406AbVKCSN6 (ORCPT ); Thu, 3 Nov 2005 13:13:58 -0500 To: Can Sar Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Nov 03, 2005 05:03 -0800, Can Sar wrote: > There is a bug in both ext2 and 3 that was fixed in 2.6.10 where if > s_blocks_per_group (in the ext2_superblock) is 0 this will cause a > division by zero. Unfortunately, this bug is still in 2.4.31. > > Furthermore, there is another bug where if s_inodes_per_group is 0 we > again get a division by 0. This bug exists in both 2.6.14 and 2.4.31. It is impossible to have an ext[23] filesystem with 0 blocks per group or 0 inodes per group. That said, it seems that ext[23]_fill_super() check for too large values and not zero, so a patch to verify these values at mount would be OK. > Finally, it seems that in the current implementation the EXT2/3 error > mode that is set in the superblock cannot be overriden by the mount > option if it is set to panic. This would mean that mounting a disk > image with s_errors = 3 (EXT2_ERRORS_PANIC) and some false values in > the superblock that are checked after s_errors is read will again > cause a kernel panic. This is definitely the case in 2.4, and seems > to be the case in 2.6 kernels as well though I haven't gotten around > to trying that particular test case yet. In ext3_fill_super() we do not call ext3_error() (only printk) so this should not invoke panic() if there is an error during mount. The ERRORS_PANIC flag is cleared in parse_options() if some other errors= behaviour is set, so I can't see the sequence of events that would lead to the situation you describe. > I hope these bug reports help. We are still in the early stages of > using our tool and hope to provide you with more bug reports in the > future. Always good to have such checking done. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.