From: Mikael Pettersson <mikpe@csd.uu.se>
To: torvalds@transmeta.com, viro@math.psu.edu
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] ext2 FS corruption in 2.5.3-pre[3-5]
Date: Fri, 25 Jan 2002 01:35:02 +0100 (MET) [thread overview]
Message-ID: <200201250035.BAA27730@harpo.it.uu.se> (raw)
Al & Linus,
There is a file system corruption problem in 2.5.3-pre[3-5], caused
by leaking uninitialised memory to in-core and later on-disk inodes.
I can easily observe the problem by creating lots of files in an
ext2 FS, reboot to single-user, and fsck the ext2 FS partition.
fsck will then give a lot of warnings about:
"i_fsize for inode NNN (...) is XX, should be zero"
where XX is a random non-zero 8-bit number.
I traced it to the pre2->pre3 transition, which contains:
> - Al Viro: VFS inode allocation moved down to filesystem, trim inodes
When FS-specific data was stored in inode->u, that data was cleared by
the memset() in fs/inode.c:alloc_inode(). The FS didn't have to bother.
Since -pre3, ext2 (and perhaps other FSs, I haven't checked) uses an
in-core inode layout consisting of an FS-specific head followed by the
generic inode. ext2 allocates these in fs/ext2/super.c:ext2_alloc_inode(),
but doesn't clear the ext2-specific fields. fs/inode.c:alloc_inode()
neither knows about these fields nor clears them, so the ext2-specific
data remains uninitialised when the new inode is returned for use. Ouch.
The patch below fixes this by adding the missing memset() to
fs/ext2/super.c:ext2_alloc_inode(). Works fine over here.
/Mikael
--- linux-2.5.3-pre5/fs/ext2/super.c.~1~ Fri Jan 25 00:03:58 2002
+++ linux-2.5.3-pre5/fs/ext2/super.c Fri Jan 25 00:35:12 2002
@@ -155,6 +155,7 @@
ei = (struct ext2_inode_info *)kmem_cache_alloc(ext2_inode_cachep, SLAB_KERNEL);
if (!ei)
return NULL;
+ memset(ei, 0, offsetof(struct ext2_inode_info, vfs_inode));
return &ei->vfs_inode;
}
next reply other threads:[~2002-01-25 0:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-25 0:35 Mikael Pettersson [this message]
2002-01-25 2:46 ` Alexander Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200201250035.BAA27730@harpo.it.uu.se \
--to=mikpe@csd.uu.se \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome