Hi,
On NFSv4 mounts, many core dumps are empty, although ulimit -c is
unlimited. An ls command shortly after the core dump often shows
4294967294 (2^32-2) as UID and GID for the "core" file.
This only happens when there was no "core" file before the dump. If a
"core" file owned by the current user is already present, it is
correctly filled.
After having done a git bisect, it seems that the problem was
introduced by commit 80e52aced138bb41b045a8595a87510f27d8d8c5
(NFSv4: Don't do idmapper upcalls for asynchronous RPC calls).
If I understand correctly what happens, do_coredump() [fs/exec.c] fails
because (inode->i_uid != current_fsuid()). In fact inode->i_uid equals
-2, because decode_attr_owner() [fs/nfs/nfs4xdr.c], which is called from
nfs4_xdr_dec_open() via decode_getfattr(), returns without calling
nfs_map_to_uid(), since its may_sleep parameter is false.
I however do not clearly understand what the aforementioned commit is
supposed to fix. I read the linux-nfs mailing list archive, and tried
some google search, but I didn't find anything.
Regards,
Arnaud Giersch
--
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
