Red Hat Bugzilla – Bug 438758
wrong kunmap call in nfs_xdr_readlinkres
Last modified: 2018-10-19 20:42:51 EDT
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. How reproducible: 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. Additional info: 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 for NFS2_MAXPATHLEN.
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 user level.
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? Server: $ ln -s $(perl -e 'print "A" x 4095;') foo Client: # ls -l ls: cannot read symbolic link foo: Input/output error total 4 lrwxrwxrwx 1 11208 11208 4095 Mar 27 09:22 foo # uname -r 2.4.21-53.ELsmp
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 release.
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. http://rhn.redhat.com/errata/RHSA-2008-0973.html