Bug 438758 - wrong kunmap call in nfs_xdr_readlinkres
wrong kunmap call in nfs_xdr_readlinkres
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fabio Olive Leite
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-24 17:43 EDT by Fabio Olive Leite
Modified: 2010-10-22 19:24 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-16 22:19:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to use kunmap_atomic instead of kunmap (887 bytes, patch)
2008-03-24 17:43 EDT, Fabio Olive Leite
no flags Details | Diff

  None (edit)
Description Fabio Olive Leite 2008-03-24 17:43:42 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.
Comment 1 Fabio Olive Leite 2008-03-24 17:43:42 EDT
Created attachment 298955 [details]
Patch to use kunmap_atomic instead of kunmap
Comment 2 Fabio Olive Leite 2008-03-24 17:47:03 EDT
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.
Comment 3 Peter Staubach 2008-03-25 11:33:50 EDT
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.
Comment 4 Fabio Olive Leite 2008-03-25 17:59:52 EDT
OK, the current NFSv3 test of "what fits on the allocated page" is probably as
good as it gets, then. Thanks for the information.
Comment 5 Fabio Olive Leite 2008-03-25 21:44:58 EDT
This bug originated from a broken fix to bug 169230.
Comment 6 Fabio Olive Leite 2008-03-26 10:33:10 EDT
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.
Comment 7 Fabio Olive Leite 2008-03-26 10:54:16 EDT
Patch posted to rhkernel-list.
Comment 8 Fabio Olive Leite 2008-03-27 09:30:42 EDT
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
Comment 13 RHEL Product and Program Management 2008-05-27 20:07:43 EDT
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.
Comment 14 Don Howard 2008-11-04 15:01:13 EST
A patch addressing this issue has been included in build 2.4.21-58.EL.
Comment 18 errata-xmlrpc 2008-12-16 22:19:27 EST
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

Note You need to log in before you can comment on or make changes to this bug.