Bug 20129

Summary:	kernel panic after bad mount
Product:	[Retired] Red Hat High Availability Server	Reporter:	Hunter Matthews <thm>
Component:	ext3	Assignee:	Stephen Tweedie <sct>
Status:	CLOSED RAWHIDE	QA Contact:	Wil Harris <wil>
Severity:	low	Docs Contact:
Priority:	low
Version:	beta
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-11-01 09:53:14 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:

Description Hunter Matthews 2000-11-01 01:02:01 UTC

Following the manual instructions for converting from ext2 to ext3:

Create a journal file that is too small (IE, I mistyped the dd and got 20K,
not 20M as in the instructions)

Attempt the mount as given in the instructions. It'll fail, cuz the journal
files too small.

Remount the filesystem as ext2 to see what went wrong. Duh, 20k vs 20M.

Attempt to re-run the dd command to make the journal bigger. Recall, at
this point, it should be just another file on a plain ext2 filesystem.

Kernel panic. I can apparently reproduce, and will mail panic details if
requested.

Comment 1 Stephen Tweedie 2000-11-01 09:53:11 UTC

Yes, please post oops information.  I think I see the problem, but without the
oops trace I can't be sure that the problem I've traced is exactly the same one
that you saw.

This is a low priority problem --- the journal creation code is all going to be
moved to user space in the end anyway. However, it should be easy to fix.

Comment 2 Stephen Tweedie 2000-11-01 11:36:28 UTC

Got it --- will be fixed in a future release.  It's a trivial one-liner.

The problem was in the VFS, not in ext3: after the failed ext3 mount, ext3
correctly released all of the inodes it had established in the process of trying
to create the journal.  However, the VFS left them in cache.  On the subsequent
ext2 mount, the inode cache still contained a copy of the journal.dat inode
which had ext3 data attached, and so the second attempt to dd to journal.dat
actually ended up using the ext3 filesystem routines on an ext2 filesystem!

The fix is to call invalidate_inodes() after a failed ext3 mount to clear up the
inode cache.

Comment 3 Hunter Matthews 2000-11-01 15:56:13 UTC

Thank you. Do you still want the oops data? (I assume not...)

Comment 4 Stephen Tweedie 2000-11-01 16:15:23 UTC

If you have it to hand, it will let me confirm for sure that it's the same
problem.  If not, I'll just assume that it is and leave it closed.  So sure,
send it if you have it but don't go out of your way to reproduce it if you
don't.