Description:

With the latest Arch Linux kernel (and perhaps older ones), I can repeatably cause every byte of the 8G of RAM in my system to get filled
by 'ls' by simply trying to list a particular directory on an NFSv3 mount. It's not just ls; find will hang, as will anything else that tries to list the directory (from Java on to Python's os.path.walk()).

I strongly suspect this is coming from some horrid interplay between glibc and NFS. There's a bug somewhere, and it chews up all the RAM. I've played around with wsize, rsize, and a few other NFS options to no avail.

Interestingly, creating a directory with, say, four characters in it ('zzzz', 'test', etc.) causes ls/find/etc. to work again. Moving a couple of directories /out/ makes them work again too. It's something specific about the size of the packets it's getting.

I've tested doing an ls on an Ubuntu 10.10 machine against the exact same mount and it worked fine.

Additional info:

This is a 64-bit install.

Relevant package installs:
kernel26 2.6.37.2-1
glibc 2.13-4
nfs-utils 1.2.2-6

Steps to reproduce:

* Mount the NFS filesystem
* Attempt to do anything that pokes at the directory (ls, find, etc.)
* Be prepared to kill -9 the process before it hoses your system

I'm attaching the first 200 lines or so of an strace of 'ls' against the directory. It's pretty boring. You'll see near the bottom that it just starts allocating more and more and more memory as it tries to ... do whatever the heck it is it's doing.

I'm happy to do whatever kernel testing/package version testing/etc. you folks guide me to try. Just let me know.