Bug 438723 - 32bit NFS server returns -EIO for readdirplus request when backing file system has 32bit inodes
Summary: 32bit NFS server returns -EIO for readdirplus request when backing file syste...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.6
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Peter Staubach
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-24 18:48 UTC by Jeff Moyer
Modified: 2008-07-24 19:27 UTC (History)
6 users (show)

Fixed In Version: RHSA-2008-0665
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-24 19:27:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed patch (6.48 KB, patch)
2008-03-26 20:10 UTC, Peter Staubach
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0665 0 normal SHIPPED_LIVE Moderate: Updated kernel packages for Red Hat Enterprise Linux 4.7 2008-07-24 16:41:06 UTC

Description Jeff Moyer 2008-03-24 18:48:49 UTC
Description of problem:
Running a client with 2.6.9-68.15.EL and a server with 2.6.9-67.EL does not
exhibit the problem.  Running both client and server on 2.6.9-68.15.EL or later
(tested up to 68.19) exibits the problem.

I eliminated the automounter, doing just a mount from the server.
Then, strace shows the following:

stat64("/mnt/1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)                                = 0
...
open("/mnt/1", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getdents64(3, 0x897cdcc, 32768)         = -1 EIO (Input/output error)
close(3)                                = 0

The systems are both i686, but I've seen the problem running a 64bit client and
a 32bit server as well.  The wireshark trace shows EIO being returned from the
readdirplus call.

Version-Release number of selected component (if applicable):
kernel: 2.6.9-68.15.EL

How reproducible:
100%

Steps to Reproduce:
1. Create an NFS export on a 32bit machine running the aflicted kernel
2. Mount the exported file system from the client
3. Perform an ls of the mounted file system
  
Actual results:
-EIO

Expected results:
directory listing

Additional info:
You can also reproduce this by running the autofs regression tests:

./autofs_workflow -a x86_64 -d RHEL4-U6 -A
http://porkchop.devel.redhat.com/~jburke/dist-cvs-repos/kernel-2.6.9-68.15.EL -i
kernel-smp-2.6.9-68.15 -S rhts.redhat.com -u <username>@redhat.com -s bz130467 -n 1

Comment 1 Peter Staubach 2008-03-26 20:10:25 UTC
The problem is that the NFS server was just invoking vfs_readdir64()
and expecting it to correctly handle file systems which don't support
the 64 bit readdir entry point.  It wasn't and was just returning
ENOSYS to the NFS server.

The NFS server needs to be handle backing off to just using vfs_readdir().
This means that it must be capable of handling having its filldir entry
points called with a 32 bit ino and not just a 64 bit ino.  This makes
the changes a bit more voluminous, but still relatively straightforward.

Comment 2 Peter Staubach 2008-03-26 20:10:47 UTC
Created attachment 299222 [details]
Proposed patch

Comment 3 RHEL Program Management 2008-04-04 15:20:15 UTC
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 4 Vivek Goyal 2008-04-07 13:05:05 UTC
Committed in 68.30.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/

Comment 8 errata-xmlrpc 2008-07-24 19:27:50 UTC
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-0665.html


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