Description of problem:
Quite a while ago an nfs_xdr_readlinkres bug when receiving really large
symlinks from the server was fixed, but the fix uses the wrong kind of kunmap.
Version-Release number of selected component (if applicable):
kernel-2.4.21-54.EL contains it.
Apparently 100% if we access a symlink of size PATH_MAX in the NFS server.
Steps to Reproduce:
Set up an NFS (v2 or v3) server exporting a volume containing a symlink of
PATH_MAX characters in size. Access the link, and an oops should occur. The
current oops is not because of the overflow caused by the symlink, but because
kunmap_atomic should have been used in the fix for giant symlinks.
Patch provided. It's different upstream, but our fix that included this bug is
already different from upstream anyway.
Created attachment 298955 [details]
Patch to use kunmap_atomic instead of kunmap
Also, I wonder if we should include a test for NFS3_MAXPATHLEN to
nfs3_xdr_readlinkres, since the corresponding v2 nfs_xdr_readlinkres has a test
Regarding Comment #2 -- This is iffey. The NFSv2 protocol actually
defined limits on thelength of pathnames and the contents of symbolic
links and such. The NFSv3 protocol does not place any limits on
these lengths, but instead, allows the server or client to use their
own limits. The error, NFS3ERR_NAMETOOLONG, was added so that a
server can inform the client that a name that was passed was too
long for it to handle. The client, when it sees something which is
too long for it to handle, should return the appropriate error to the
OK, the current NFSv3 test of "what fits on the allocated page" is probably as
good as it gets, then. Thanks for the information.
This bug originated from a broken fix to bug 169230.
Now that I look harder at the old bug, I noticed that the code patched in bug
169230 did use kmap_atomic (looking at 2.4.21-37.8.EL), while the upstream patch
quoted there doesn't. So it's likely that the RHEL code was changed to use
kmap_atomic for some other reason, and the upstream patch applied with some
fuzzyness but inserted a plain kunmap call, instead of a kunmap_atomic.
I'm going to post the patch now, as I'm convinced it's the right thing to do.
Patch posted to rhkernel-list.
Just tested kernel-2.4.21-53.EL, and it seems to handle a 4095-char symlink just
fine. Perhaps we need memory pressure as well to trigger the kunmap issue?
$ ln -s $(perl -e 'print "A" x 4095;') foo
# ls -l
ls: cannot read symbolic link foo: Input/output error
lrwxrwxrwx 1 11208 11208 4095 Mar 27 09:22 foo
# uname -r
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
A patch addressing this issue has been included in build 2.4.21-58.EL.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.