Hi, please could you review the following fix for 6920999?
webrev: http://cr.opensolaris.org/~jkryl/nfs-utf8/ thanks Jan Background information (copy-pasted from bugster): ---------------------- When fixing this I have encountered a couple of independent bugs, which all disabled proper function of utf-8 to other character set and vice versa conversion. This CR fixes all of these defects. 1) definition of in_access_list() in mountd.c was modified (parameter count changed) but this change was not propagated to nfs_cmd.c, which also used this function. This led to core dump of mountd daemon upon receiving NFS_CMD request. This is regression of 6882460 integrated in snv 130. 2) rfs4_lookup() in nfsv4 server code, didn't attempt to translate between character sets. This could be easily reproduced by copying file containing utf-8 characters from zfs share to local disk. This has been there probably since this code was written. 3) nfscmd_send() which is responsible for communication with mountd daemon, returned misleading return value when door fs call was successfull, but the request to mountd daemon itself failed. The function should return 0 (NFSCMD_ERR_SUCCESS) only if both conditions are met: door fs call was successfull and mountd request was successfull. 4) nfscmd_charmap() was never called for NFSv4 compound requests. Thus the charset cache didn't get initialized for a client and the need for charset conversion could not be detected. For NFS v3, v2 we called nfscmd_charmap() before the request was processed. This approach is not possible in case of NFS v4, because compound calls can cross filesystem boundaries and we wouldn't know, which exportinfo to associate client with. Thus I have modified all NFS versions to defer call to nfscmd_charmap() to a point where it is actually needed (when we do a translation). At that time we know exactly which exportinfo should be used. Note that all of this is in case of NFS v4 just a workaround for misbehaved NFS clients, which send character sequences which aren't valid utf-8 sequences, which is prohibited by standard. See 6862326 for more details.
