Bug 684048
| Summary: | ext4 panic if wrong mount options are used | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Oleg Drokin <green> |
| Component: | kernel | Assignee: | Lukáš Czerner <lczerner> |
| Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.8 | CC: | esandeen, rwheeler |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-21 15:01:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. This has been already fixed with 2.6.18-215.el5-31-gfd684d6 which is backport of the upstream commit 705895b61133ef43d106fe6a6bbdb2eec923867e Thanks! -Lukas *** This bug has been marked as a duplicate of bug 614957 *** |
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.