Fixed it. The mmap () = EINVAL was being generated at the
following point in the kernel, in mm/filemap.c, generic_file_mmap:
} else {
ops = &file_private_mmap;
if (vma->vm_offset & (inode->i_sb->s_blocksize - 1))
return -EINVAL;
}
In the NFS case, s_blocksize == 16384, causing the mmap
to fail this test. In the local drive case, s_blocksize < 16384,
and it succeeded.
This obviously suggests setting bsize=4096 on the NFS mount.
Unfortunately, the current version of NFS mount doesn't
support setting bsize. Instead, it appears to set it
very large, and nfs_block_size chooses 16384 as the largest
correct value.
I patched mount-2.6h (see appended patch) to allow me to
set bsize on NFS mounts. With bsize=4096, all the mapping
bugs are fixed and I can happily run binaries and libraries
off NFS.
Perhaps the long-term solution is for ld.so to be fixed so
it maps code at blocks aligned to 16K?
I've cc'd this message to HJ and Andries Brouwer for their comments.
Rich.
Richard Jones wrote:
>
> Some more information on this bug ... I've got two identically
> configured machines here, except that one's running 2.1.61 + CVS
> patches and one's running plain 2.0.31.
-- Richard Jones rjones@imcl.com Tel: +44 171 460 6141 Fax: .. 4461 ABLE INmEDIA Ltd. 262a Fulham Rd. London SW10 9EL. "you'll write in PGP: www.four11.com telegraphic, or you won't write at all" [Céline] --------------2DC42CC5D9AF12DD60F53B64 Content-Type: text/plain; charset=us-ascii; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch"*** nfsmount.c.orig Tue Nov 11 13:26:46 1997 --- nfsmount.c Tue Nov 11 13:26:37 1997 *************** *** 187,192 **** --- 187,194 ---- data.rsize = val; else if (!strcmp(opt, "wsize")) data.wsize = val; + else if (!strcmp (opt, "bsize")) + data.bsize = val; else if (!strcmp(opt, "timeo")) data.timeo = val; else if (!strcmp(opt, "retrans"))
--------------2DC42CC5D9AF12DD60F53B64--