Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Starting with the -157 kernel, ls on ~jmoyer/News/drafts/drafts would hang. This is how it is mounted:
homedirs.bos.redhat.com:/vol/data/home/boston /home/boston nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.16.255.101,mountvers=3,mountport=4046,mountproto=udp,local_lock=none,addr=10.16.255.101 0 0
Looking into it further, the ls process was stuck in a loop doing readdir(), iterating over the same list of entries infinitely.
I backported the following 3 commits, and the behaviour is better:
commit 8ef2ce3e16d9bec6cf015207c1c82a5b864046ac
NFS: Detect loops in a readdir due to bad cookies
commit 480c2006ebb44ae03165695db7b3e38c04e0d102
NFS: Create nfs_open_dir_context
commit e47c085afb3d16cbc6a4bfb10a3b074bb7c58998
NFS: Ensure that we update the readdir filp->f_pos correctly
The output now looks like this:
$ ls ~/News/drafts/drafts/
ls: reading directory /home/boston/jmoyer/News/drafts/drafts/: Too many levels of symbolic links
1.orig 15 19~ 24 29 33.orig 36~ 40 44
11.orig 16 20 25 30 34 37 41 7
12 17 21 25.orig 31 35 37.orig 42 8.orig
12.orig 18 22 26 31.orig 35.orig 38 43
13 19 23 27 32 36 38.orig 43.orig
14 19.orig 23.orig 28 33 36.orig 39 43~
dmesg contains:
NFS: directory drafts/drafts contains a readdir loop. Please contact your server vendor. Offending cookie: 2
On older kernels, this message was never printed, so I'm left wondering whether there really is a server problem, or if we've introduced a bug.
Version-Release number of selected component (if applicable):
kernel-2.6.32-157.el6.x86_64
How reproducible:
100%
Steps to Reproduce:
1. ls ~jmoyer/News/drafts/drafts
Actual results:
ls hangs, eating up memory until the OOM killer gets it
Expected results:
ls returns results
Additional info:
The capture shows the server sending '.' and '..' in both readdir replies. So this is probably a server bug, but it's still a regression as the client no longer deals with this as well as it used to.
(In reply to comment #3)
> The capture shows the server sending '.' and '..' in both readdir replies. So
> this is probably a server bug, but it's still a regression as the client no
> longer deals with this as well as it used to.
Disregard this. I didn't notice that these readdirs were for entirely different dir filehandles. I don't see a problem right offhand with the readdir reply. From what I can tell each entry has its own cookie.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2011-1530.html
Description of problem: Starting with the -157 kernel, ls on ~jmoyer/News/drafts/drafts would hang. This is how it is mounted: homedirs.bos.redhat.com:/vol/data/home/boston /home/boston nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.16.255.101,mountvers=3,mountport=4046,mountproto=udp,local_lock=none,addr=10.16.255.101 0 0 Looking into it further, the ls process was stuck in a loop doing readdir(), iterating over the same list of entries infinitely. I backported the following 3 commits, and the behaviour is better: commit 8ef2ce3e16d9bec6cf015207c1c82a5b864046ac NFS: Detect loops in a readdir due to bad cookies commit 480c2006ebb44ae03165695db7b3e38c04e0d102 NFS: Create nfs_open_dir_context commit e47c085afb3d16cbc6a4bfb10a3b074bb7c58998 NFS: Ensure that we update the readdir filp->f_pos correctly The output now looks like this: $ ls ~/News/drafts/drafts/ ls: reading directory /home/boston/jmoyer/News/drafts/drafts/: Too many levels of symbolic links 1.orig 15 19~ 24 29 33.orig 36~ 40 44 11.orig 16 20 25 30 34 37 41 7 12 17 21 25.orig 31 35 37.orig 42 8.orig 12.orig 18 22 26 31.orig 35.orig 38 43 13 19 23 27 32 36 38.orig 43.orig 14 19.orig 23.orig 28 33 36.orig 39 43~ dmesg contains: NFS: directory drafts/drafts contains a readdir loop. Please contact your server vendor. Offending cookie: 2 On older kernels, this message was never printed, so I'm left wondering whether there really is a server problem, or if we've introduced a bug. Version-Release number of selected component (if applicable): kernel-2.6.32-157.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. ls ~jmoyer/News/drafts/drafts Actual results: ls hangs, eating up memory until the OOM killer gets it Expected results: ls returns results Additional info: