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.
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.
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.
Thank you. Do you still want the oops data? (I assume not...)
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.