Bug 684048 - ext4 panic if wrong mount options are used
Summary: ext4 panic if wrong mount options are used
Keywords:
Status: CLOSED DUPLICATE of bug 614957
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.8
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukáš Czerner
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-10 23:33 UTC by Oleg Drokin
Modified: 2011-03-21 15:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-21 15:01:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Oleg Drokin 2011-03-10 23:33:12 UTC
Attempt to mount ext4 causes kernel BUG if incorrect mount option is used:

[root@rhel5 ~]# mount /tmp/ext4-image /mnt -t ext4 -o loop,blahblah
Segmentation fault
[root@rhel5 ~]#
Message from syslogd@ at Thu Mar 10 17:17:00 2011 ...
centos5 kernel: invalid opcode: 0000 [1] SMP 

I know ext4 code is in preview state, still would be nice to fix this.

The problem lies in fact that when s_blockgroup_lock separation code was merged in from .32 kernel, the separation was all thrown out, yet the freeing was left in place - patch linux-2.6-fs-ext4-~32-codebase.patch

So now if mount fails, this code in ext4_fill_super is executed:

 out_fail:                                                                      
        sb->s_fs_info = NULL;
+       kfree(&sbi->s_blockgroup_lock);   <==== Wrong!
        kfree(sbi);
        lock_kernel();
        return ret;

Since s_blockgroup_lock is defined as:
+       struct blockgroup_lock s_blockgroup_lock;                               


you can see that attempting to free it separately is a bad idea.

Comment 1 Oleg Drokin 2011-03-10 23:35:13 UTC
wanted to mentioned that I checked the last kernel for rhel5 which is kernel-2.6.18-194.32.1 and the problem is still there.

Comment 2 Lukáš Czerner 2011-03-11 13:40:38 UTC
This has been already fixed with 2.6.18-215.el5-31-gfd684d6 which is backport of the upstream commit 705895b61133ef43d106fe6a6bbdb2eec923867e

Thanks!
-Lukas

Comment 3 Lukáš Czerner 2011-03-21 15:01:03 UTC

*** This bug has been marked as a duplicate of bug 614957 ***


Note You need to log in before you can comment on or make changes to this bug.