Bug 438758
| Summary: | wrong kunmap call in nfs_xdr_readlinkres | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Fabio Olive Leite <fleite> | ||||
| Component: | kernel | Assignee: | Fabio Olive Leite <fleite> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.9 | CC: | jlayton, staubach, steved, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-12-17 03:19:27 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Fabio Olive Leite
2008-03-24 21:43:42 UTC
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 |