Description of problem:

Hi,

Our home directories here are mounted over NFS4. When I log in to machine A and run

vim
:q

and then log into machine B and do:

vim
:q

I get E137: Viminfo file is not writable: /users/system/rtheys/.viminfo

Every invocation of 'vim and :q' will trigger this.

Explicitely doing a stat of the file fixes this.

Doing the vim :q thing on machine A while it has been triggered on B works: A never shows this message, while B continues to show it until the file is stat'ed.

The file server is a RHEL 6.2 machine.

I can trigger this bug on RHEL 6 clients, but NOT on RHEL 5 clients.

This seems to have been discussed here:
http://comments.gmane.org/gmane.linux.nfs/37230

According to that thread, vim tries to do a stat on the ~/.viminfo file and receives incorrect st_uid/st_gid information (-2)? If it gets the wrong information I assume this is a kernel bug. Why is the information incorrect?

The easiest way to reproduce this is with vim, but I've seen similar strange behaviour when modifying my ~/.ssh/authorized_keys file and then trying to ssh to other machines. They say they are ignoring the file because the permissions are not OK. This looks like the same bug to me, but is harder to reproduce here.

This bug has been introduced between 2.6.31 and 2.6.32 by commit 80e52aced138bb41b045a8595a87510f27d8d8c5

commit 80e52aced138bb41b045a8595a87510f27d8d8c5
Author: Trond Myklebust <Trond.Myklebust>
Date:   Sun Aug 9 15:06:19 2009 -0400

    NFSv4: Don't do idmapper upcalls for asynchronous RPC calls

    We don't want to cause rpciod to hang...

    Signed-off-by: Trond Myklebust <Trond.Myklebust>


The 3.3-rc kernels have an upstream fix that works if applied to a pristine 3.2.5 kernel:

From: Trond Myklebust <Trond.Myklebust>
Date: Sat, 7 Jan 2012 13:22:46 -0500
Subject: NFSv4: Save the owner/group name string when doing open

commit 6926afd1925a54a13684ebe05987868890665e2b upstream.

...so that we can do the uid/gid mapping outside the asynchronous RPC
context.
This fixes a bug in the current NFSv4 atomic open code where the client
isn't able to determine what the true uid/gid fields of the file are,
(because the asynchronous nature of the OPEN call denies it the ability
to do an upcall) and so fills them with default values, marking the
inode as needing revalidation.
Unfortunately, in some cases, the VFS will do some additional sanity
checks on the file, and may override the server's decision to allow
the open because it sees the wrong owner/group fields.

Signed-off-by: Trond Myklebust <Trond.Myklebust>
Signed-off-by: Jonathan Nieder <jrnieder>

Please consider backporting this fix to a RHEL 6 update.

Regards, 

Rik


Version-Release number of selected component (if applicable):

all RHEL6 kernels

How reproducible:

always

Steps to Reproduce:
1. open a terminal and ssh to machine A on which your home directory is NFS4 mounted
2. open a terminal and ssh to machine B on which that same homedir is also NFS4 mounted
3. open vim and :q on machine A
4. open vim and :q on machine B
5. Machine B will keep on giving this error message unless the file is explicitly stat'ed. After opening vim on A again, the error message will return.

Actual results:

error about not being able to write

Expected results:

no error from vim

Additional info: