Bug 439431 - include patch to add FATTR4_RDATTR_ERROR to readdir calls
include patch to add FATTR4_RDATTR_ERROR to readdir calls
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.7
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jeff Layton
Martin Jenner
:
Depends On: 227610
Blocks: RHEL4u8_relnotes 461304
  Show dependency treegraph
 
Reported: 2008-03-28 13:44 EDT by Jeff Layton
Modified: 2009-05-18 15:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specific directory entry that was causing the issue.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 15:31:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch -- add support for rdattr_error in NFSv4 readdir (2.45 KB, patch)
2008-03-28 13:50 EDT, Jeff Layton
no flags Details | Diff

  None (edit)
Description Jeff Layton 2008-03-28 13:44:44 EDT
+++ This bug was initially created as a clone of Bug #227610 +++

When a NFSv4 client requests a READDIR and the server hits an error while
getting attributes for a directory entry, the server will return the error for
the entire READDIR call. This isn't optimal, so we can and should set the
"fattr4_rdattr_error" flag in the request to specify that the server should
continue on and only report the error on the problem directory entries.

-- Additional comment from jlayton@redhat.com on 2007-02-06 20:58 EST --
Created an attachment (id=147529)
patch 1 -- preliminary patch to make needed one apply cleanly

This patch makes the next one apply cleanly (and looks like it also fixes
another potential bug).

-- Additional comment from jlayton@redhat.com on 2007-02-06 21:00 EST --
Created an attachment (id=147530)
patch 2 - set and handle fattr_rdattr_error attribute 

This patch fixes the problem, and allowing the server to return a more granular
mix of valid results and errors.


-- Additional comment from steved@redhat.com on 2007-02-21 09:45 EST --
Was there a reproducer for this problem?

-- Additional comment from jlayton@redhat.com on 2007-02-21 10:09 EST --
Now that I think we have a resolution on bz228893, I think I might be able to
get one.

The way I reproduced it at connectathon was mounting a nfs4 directory that
contained a referral export within it (hopefully I have the terminology correct
here). When trying to do a readdirplus on the directory that contained the
referral, the client would get an error back on the entire directory because
this wasn't set.

I was hoping I might be able to set up a similar situation by having a v4 root
dir that exports a mix of directories to krb5 and krb5i exclusively, but haven't
had time to reproduce it as of yet.


-- Additional comment from jlayton@redhat.com on 2007-04-20 16:40 EST --
To reproduce, you'll need a Fedora 7 server (the server-side referral bits
aren't yet in RHEL5):

# mkdir /export
# mkdir /export/fsloc
# mount --bind /export/fsloc /export/fsloc
# cat /etc/exports
/export         *(rw,nohide,insecure,fsid=0)
/export/fsloc   *(ro,nohide,insecure,refer=/foo@10.10.10.10)
# service nfs start

(server path and address don't really matter here since RHEL4 can't chase the
referral anyway)...

On the client:

# mkdir -p /mnt/referral
# mount -t nfs4 server:/ /mnt/referral
# ls -l /mnt/referral
# ls -l /mnt/referral
ls: reading directory /mnt/referral: Input/output error
total 0

...you'll also get this in the ring buffer:

nfs4_map_errors could not handle NFSv4 error 10019

...the expectation is that you'll be able to list the contents of the directory,
though the READDIRPLUS entry for the referral will come back with an error.


-- Additional comment from jlayton@redhat.com on 2007-04-23 15:12 EST --
Actually, given my reproducer, only the first patch here is needed to fix this.
I'll go ahead and propose that and hold off on the other one since I don't seem
to have a situation that actually requires rdattr_error.


-- Additional comment from jlayton@redhat.com on 2007-04-23 15:34 EST --
Expected results (with an empty file 

# ls -al /mnt/referral
total 16
drwxr-xr-x   3 root root 4096 Apr 23 15:32 .
drwxr-xr-x  12 root root 4096 Apr 20 11:58 ..
?---------   ? ?    ?       ?            ? fsloc

...the directory entries are listable, but attempting to stat fsloc gives back a
-EIO. I think this is the best we can do for RHEL4. Backporting the
referral-chasing code is probably too much.


-- Additional comment from jlayton@redhat.com on 2007-04-23 15:42 EST --
Patch 1 posted to RHKL:

Subject: [RHEL4.6 PATCH] allow RHEL4 to do READDIR on directory containing a
referral (BZ 227610)

-- Additional comment from pm-rhel@redhat.com on 2007-04-23 15:45 EST --
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.

-- Additional comment from pm-rhel@redhat.com on 2007-04-23 16:02 EST --
This request was evaluated by Red Hat Kernel Team for inclusion in a Red
Hat Enterprise Linux maintenance release, and has moved to bugzilla 
status POST.

-- Additional comment from jlayton@redhat.com on 2007-09-05 17:41 EST --
Moving to 4.7. This patch was less critical, and we already had a lot of NFS
patches for 4.6.


-- Additional comment from pm-rhel@redhat.com on 2007-09-05 17:43 EST --
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.

-- Additional comment from vgoyal@redhat.com on 2008-03-27 19:21 EST --
Committed in 68.27.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 1 Jeff Layton 2008-03-28 13:48:46 EDT
When I proposed the patch for bug 227610, Peter mentioned that we should
consider the patch to add the rdattr_error attribute to NFS4 READDIR calls. I
wasn't able to get it done and proposed in time for 4.7, so I've opened this to
track whether we want to include it for 4.8.

In general, it makes sense to me that we should request more granular errors in
readdir calls. We don't in general want to have the entire READDIR error out
just because one entry was bad.

The only issue is that I don't have a clear situation/reproducer where this is
needed. We'll probably need to concoct one for the QA group, so that may be the
challenge here.
Comment 2 Jeff Layton 2008-03-28 13:50:25 EDT
Created attachment 299505 [details]
patch -- add support for rdattr_error in NFSv4 readdir

Patch that adds support for this option. I've verified that it works by
inspection, but if we want to include it, we probably need to come up with a
clear situation that this fixes...
Comment 4 RHEL Product and Program Management 2008-04-21 10:40:42 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 5 RHEL Product and Program Management 2008-09-03 09:14:13 EDT
Updating PM score.
Comment 6 Vivek Goyal 2009-01-14 09:22:28 EST
Committed in 78.28.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 9 Jeff Layton 2009-01-28 07:17:06 EST
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
When a NFSv4 server is issued a READDIR call and has a problem getting info on one or more entries in a directory, it can either return an error for the entire readdir call or it can return what info it did find and flag the problem entries with an error.

This behavior is governed by a flag in the READDIR call, which indicates how errors should be reported. This patch makes the RHEL4 NFSv4 client request and handle more granular error reporting.
Comment 11 Ryan Lerch 2009-02-23 17:38:09 EST
Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1,3 +1 @@
-When a NFSv4 server is issued a READDIR call and has a problem getting info on one or more entries in a directory, it can either return an error for the entire readdir call or it can return what info it did find and flag the problem entries with an error.
+previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory that was causing the issue.-
-This behavior is governed by a flag in the READDIR call, which indicates how errors should be reported. This patch makes the RHEL4 NFSv4 client request and handle more granular error reporting.
Comment 12 Jeff Layton 2009-02-23 17:48:03 EST
Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory that was causing the issue.+previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory entry that was causing the issue.
Comment 14 Ryan Lerch 2009-02-23 17:53:35 EST
Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1 @@
-previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specfic directory entry that was causing the issue.+previously, when a NFSv4 (Network File System Version 4) client encountered issues while processing a directory using readdir(), an error for the entire readdir() call was returned. With this update, the "fattr4_rdattr_error" flag is now set when readdir() is called, instructing the server to continue on and only report an error on the specific directory entry that was causing the issue.
Comment 17 errata-xmlrpc 2009-05-18 15:31:25 EDT
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-2009-1024.html

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