Hi, Trond Myklebust wrote: > [Subject: NFSv4: Save the owner/group name string when doing open] > > ...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. Thanks! This patch (commit 6926afd1925a, 2012-01-07) fixes the following client-side bug[1]: | 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. Rik Theys bisected and found the bug reproducible after and not before v2.6.32-rc1~412^2~48^2~15 (NFSv4: Don't do idmapper upcalls for asynchronous RPC calls, 2009-08-09). [...] > 6 files changed, 162 insertions(+), 64 deletions(-) Now I am wondering what, if anything, can be done to fix this in the 2.6.32.y, 3.0.y, and 3.2.y stable kernels. The patch looks too big for inclusion under the usual stable_kernel_rules: - It cannot be bigger than 100 lines, with context. Ideas? Jonathan [1] http://bugs.debian.org/659111 http://thread.gmane.org/gmane.linux.nfs/37230 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
