On Fri, 2007-09-28 at 01:30 -0700, Andrew Morton wrote:
First of all, thanks a bunch for the report. It really helps.
This could probably be considered a reiser4 bug, excited by the r/o bind
mount changes. See how that pointer is 0x...053? That's a weird offset
for a structure that should be mostly word-aligned.
I think that's because reiser4 stack-allocates a 'struct file', and then
only initializes parts of it, *not* including the vfsmount. The test in
file_update_time() is for f->f_vfsmnt == NULL, and I think we had
something like 0x1 in there.
I think that stack allocation is a pretty nasty trick for a structure
that's supposed to be pretty persistent and dynamically allocated, and
is certainly something that needs to get fixed up in a proper way.
This works around the problem for now, but this could potentially cause
more bugs any time we add some member to 'struct file' and depend on its
state being sane anywhere in the VFS. If there's a list anywhere of
merge-stopper reiser4 bugs around, this should probably go in there.
In general, I think reiser4 also lets the 'struct file' get way too deep
into its internals. For instance, I would expect reiser4_write_extent()
to take a plain inode, not a 'struct file'.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---
lxc-dave/fs/reiser4/plugin/file/file.c | 1 +
1 file changed, 1 insertion(+)
diff -puN fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt fs/reiser4/plugin/file/file.c
--- lxc/fs/reiser4/plugin/file/file.c~reiser4-need-to-initialize-file-f_mnt 2007-09-28 09:10:51.000000000 -0700
+++ lxc-dave/fs/reiser4/plugin/file/file.c 2007-09-28 09:11:20.000000000 -0700
@@ -581,6 +581,7 @@ static int truncate_file_body(struct ino
file.private_data = NULL;
file.f_pos = new_size;
file.private_data = NULL;
+ file.f_vfsmnt = NULL;
uf_info = unix_file_inode_data(inode);
result = find_file_state(inode, uf_info);
if (result)
_
-- Dave
-
