[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <bug-48431-13602@https.bugzilla.kernel.org/>
Date: Fri, 5 Oct 2012 12:19:07 +0000 (UTC)
From: bugzilla-daemon@...zilla.kernel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 48431] New: ext4_fill_super() reports success even if
ext4_mb_init() fails
https://bugzilla.kernel.org/show_bug.cgi?id=48431
Summary: ext4_fill_super() reports success even if
ext4_mb_init() fails
Product: File System
Version: 2.5
Kernel Version: 3.6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: fs_ext4@...nel-bugs.osdl.org
ReportedBy: eugene.shatokhin@...alab.ru
Regression: No
Created an attachment (id=82361)
--> (https://bugzilla.kernel.org/attachment.cgi?id=82361)
The patch to fix the problem
If ext4_mb_init() called from ext4_fill_super() (fs/ext4/super.c:3980 in the
current ext4 git tree) fails and returns error code, ext4_fill_super() still
returns 0.
This happens because the return value of ext4_mb_init() is not assigned to
'ret' in the error path. So the previous value of 'ret' (0) is returned from
ext4_fill_super().
This problem leads to a kernel oops in mount_fs() when the latter tries to
access the struct dentry that the mount() callback returns ("sb = root->d_sb;"
in fs/super.c:1180).
The problem has been revealed with the help of the fault simulation facilities
provided by KEDR Framework.
Attached is a trivial patch that fixes the problem.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists