On Tuesday September 25, firstname.lastname@example.org wrote:
> Under 2.4.10, I can mount an exported directory to another machine (or
> loopback to the localhost), and while creating symlinks some will end
> up with corrupt destinations. It looks like random binary garbage is
> being appended to the end of the file name.
Oh dear, dear, dear. That was careless wasn't it....
change "xdr_decode_string_inplace" to "xdr_decode_string".
This won't affect NFSv2, only v3.
I would like to use the "_inplace" version, but "vfs_symlink" doesn't
take a length argument for the symlink, and _inplace cannot nul
> Normal files seem to be copied and created just fine, but symlinks end
> up with massive corruption in the name of the file they point to (I
> haven't tried checksumming files after copying, though).
> This happens while using 2.4.10 as the nfs server. Tested with both
> 2.4.2-12 (RH 7.1 stock) and 2.4.10 as client. The problem doesn't
> show with the stock RH kernel on the server.
> It seems to help if you pick a long file name to link to (ln -s
> /usr/IBMdb2/V7.1/instance foo is much more likely to trip the bug than
> ln -s /dev/null foo) and sometimes it seems that repeating links to
> the same file can get more of the links to create successfully.
> I'll attach an example of triggering the bug (I suspect all the binary
> involved will trip up MTA's without some encoding).
> Both the nfs server and client in this case are dual proc Xeon 700's
> w/ 4gig of RAM. The actual directory being nfs exported is mounted on
> an internal scsi drive.
> I'll be happy to try out any patches or provide access to test boxes
> if it'll help track things down.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 30 2001 - 21:00:53 EST