Bug 523285

+++ This bug was initially created as a clone of Bug #519184 +++

This is a RHEL 5 report for bz 225507. The report is based on the upstream thread
http://linux-nfs.org/pipermail/nfsv4/2007-December/007321.html

To recreate:

1) On the server, set anonuid/anongid as 4294967294
# cat /etc/exports 
/export *(rw,insecure,fsid=0) 
/export/data *(rw,anonuid=4294967294,anongid=4294967294)
Restart nfs to export the filesystem
2) On the server create a file with uid set to 4294967294
mkdir /export/data/test
touch /export/data/test/a
chown 4294967294 /export/data/test/a
3) Mount the nfs4 export on a client
mount -r nfs4 server:/data /mnt
4) cd /mnt/test/
5) ls -l 

The system will hang.

The upcall by the nfs module uses a signed number. Thus the uid 4294967294 gets translated to -2 which confuses rpc.idmapd.

--- Additional comment from sprabhu on 2009-08-25 11:05:50 EDT ---

Patch available at
http://linux-nfs.org/pipermail/nfsv4/2007-December/007321.html

--- Additional comment from sprabhu on 2009-08-25 11:09:39 EDT ---

A test kernel with the patch from c#1 was tested successfully by the user.

--- Additional comment from jlayton on 2009-09-10 13:46:37 EDT ---

Patch looks straightforward and obviously correct. I've added it to my test kernels here to get some soak time:

http://people.redhat.com/jlayton/

...I also think I see the problem with idmapd that causes it to stop responding. For most error conditions, the nfsdcb() function does not requeue the event (i.e. call event_add() again). That means that once we hit an error condition idmapd stops watching that file descriptor.

I've got a patch that should help fix that, but it needs to be tested a little more and I want to get some upstream feedback on it.

--- Additional comment from jlayton on 2009-09-10 15:46:44 EDT ---

Patch for idmapd sent upstream. If it gets accepted I'll plan to clone this bug and we'll get this patch into RHEL too:

http://marc.info/?l=linux-nfs&m=125261173214324&w=2