On Thu, Jun 27, 2002 at 10:50:32AM +0200, Steffen Neumann wrote:
> Thanks to Frank Loemker we now have the right combination
> of ksymoops, System.map, kernel and whoknowswhatelse. See below.

It looks very good. It points at this line in mm/filemap.c

        struct address_space *mapping = filp->f_dentry->d_inode->i_mapping;

And one of these is a NULL pointer. In 2.4.18, filp is a local 'fake'
file, so that one and the f_dentry fields should be ok, so I'm
suspecting eith the d_inode or i_mapping pointers being incorrect.

It looks like we don't really lock down the container file's inode
during coda_readdir, and we may get scheduled out when reading the
entries. The reference should be kept by the fact that the coda inode
is still there, but obviously that reference must be lost somewhere.

So we can try to hold a reference on the container file's dentry during
the readdir call to avoid losing it. I've attached a patch against
2.4.18 that does this. Alternatively you could try 2.4.19-rc1, which has
many changes for Coda and should have this fixed in a different way.

Jan

--- linux-2.4.18.orig/fs/coda/dir.c	Thu Jun 27 08:40:35 2002
+++ linux-2.4.18/fs/coda/dir.c	Thu Jun 27 08:42:20 2002
@@ -506,13 +506,14 @@
 	cinode = cii->c_container->f_dentry->d_inode;
 	if ( S_ISREG(cinode->i_mode) ) {
 		/* Venus: we must read Venus dirents from the file */
-		cdentry = cii->c_container->f_dentry;
+		cdentry = dget(cii->c_container->f_dentry);
 		coda_prepare_fakefile(file, cdentry, &fakefile);
 
 		result = coda_venus_readdir(&fakefile, dirent, filldir);
 
 		file->f_pos = fakefile.f_pos;
 		file->f_version = fakefile.f_version;
+		dput(cdentry);
         } else {
 		/* potemkin case: we are handed a directory inode */
 		result = vfs_readdir(file, filldir, dirent);