On Mon, Dec 03, 2001 at 08:14:13PM +0100, Florian Schaefer wrote:
> I know that everything worked fine with my "old" 2.4.14 kernel.

Nothing got changed in the Coda kernel code since 2.4.4. However there
are currently many reports of sometimes severe filesystem corruption
with 2.4.16/17pre kernels and occasional symlink follow/create problems
that seem to be VM related with just about any kernel since 2.4.10.

Oh, and this is on ext2/ext3/reiserfs filesystems, so there is a good
chance that this isn't Coda related.

However, looking at your messages,

Dec  3 19:53:03 dexter kernel: coda_pioctl: Venus returns: -13 for (0x7f000001,0x1,0x1)
Dec  3 19:53:08 dexter kernel: coda_pioctl: Venus returns: -107 for (0x7f000000,0x1,0x1)
Dec  3 19:53:17 dexter kernel: coda_venus_readdir: cannot read directory -22.


Coda ioctls with -13 (EACCES), and -107 (ENOTCONN) return codes.

It looks like a failed authentication, perhaps the wrong password in
'clog'? first ioctl would get the permission denied error, and then the
a validation step (or ctokens?) would get the 'ENOTCONN' error when
there are no valid tokens. So the first two lines seem pretty harmless.

The third one is interesting. When the kernel tried to read the
directory data out of the container file, the kernel_read function
(which is also used to load executables into memory), returned the
EINVAL error which caused Coda not to be able to return the directory
contents to the readdir call from userspace.

Tracing the code in 2.4.14 this could only get returned when the amount
to read is negative, which it never is because we're always reading a
fixed size.

But in 2.4.15, DirectIO was added into the mix, and it adds an
additional test in generic_file_read, if (filp->f_flags & O_DIRECT), now
until this change nothing checked filp->f_flags in this path, so the
fake file structure that Coda uses to read the directory doesn't
set/clear this field.

I guess once in a blue moon, the O_DIRECT bit will be set and the
readdir will fail in the DirectIO path, while otherwise it will run
fine. Could you try the following patch to linux/fs/coda/dir.c


--- linux/fs/coda/dir.c.orig	Mon Dec  3 16:12:16 2001
+++ linux/fs/coda/dir.c	Mon Dec  3 16:14:37 2001
@@ -549,6 +549,7 @@
 	fake_file->f_pos = coda_file->f_pos;
 	fake_file->f_version = coda_file->f_version;
 	fake_file->f_op = cont_dentry->d_inode->i_fop;
+	fake_file->f_flags = O_RDONLY;
 	return ;
 }