On Sat, 2012-01-07 at 18:13 -0500, Chuck Lever wrote: > On Jan 7, 2012, at 1:27 PM, Trond Myklebust wrote: > > > ...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. > > I expect this change would also address the known problem with empty application core dumps on NFSv4 mounts...? Yes. I believe that the above mentioned VFS-level checks were the problem there. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
