The function check_utf8() is in RHEL 4, but it has been removed since ~ 2.6.11 from kernel.org kernels. Furthermore, RHEL 5 does not contain this function. Fujitsu would like RHEL 4 NFS servers to be consistent with the RHEL 5 NFS servers by removing the UTF-8 check. * Reference to the original patch by Bruce Fields: http://www.linux-nfs.org/pipermail/nfsv4/2005-February/001175.html Details from Fujitsu: ------------------------------------------------------------ RHN System ID: Customer Contact Name: Ishikawa Yoshitaka Description of Problem: Almost all the file systems do not check the filename be operated is valid UTF-8 or not, for example ext2/ext3/NFSv2/NFSv3, etc. If an ext3 file (directory) whose name is invalid UTF-8 and be exported through NFSv4, Client can not operate this file(directory). So we'd better not to do this check. About this problem, the maintainer of NFSv4 'J. Bruce Fields' said: ------------------------- RFC3530 says NFSv4 filenames are in UTF-8, and that servers "should" reject filenames that aren't valid UTF-8. Currently we do some incomplete UTF-8 checking, but this turns out to be more of a hindrance than a help--if we export a file system with non-UTF8 names, things break. We might be able to help things if we had some idea of the exported file system's charset and could do some translation. For now, though, the simplest solution by far seems to be just to remove the UTF-8 checks, making NFSv4's behavior just like NFSv2/v3's. Version-Release number of selected component: Red Hat Enterprise Linux Version Number: RHEL4 Release Number: 4.8 snapshot5 Architecture: x86_64 Kernel Version: kernel-2.6.9-88.EL Related Package Version: None Related Middleware / Application: None Drivers or hardware or architecture dependency: None How reproducible: Every time Step to Reproduce: Server Settings: # cat /etc/exports /tmp *(rw,insecure,fsid=0,no_root_squash) Client: Execute following commands to reproduce: Step1:mount the nfsv4 fs and enter the mount dir # mount -t nfs4 [server]:/ /mnt # cd /mnt Step2:compile the reproduction program: # cp $somedir/check_utf8.c . # gcc -o check_utf8 check_utf8.c Step3:execute the reproduction program # ./check_utf8 Actual Results: Operations are rejected by NFS Server. # ./check_utf8 Error: mkdir '??' failed. (Invalid argument) Error: opendir '??' failed. (Invalid argument) Error: rmdir '??' failes. (Invalid argument) Error: open '??' failed. (Invalid argument) Error: rename '??' to '??' failed. (Invalid argument) Error: unlink '??' failed. (Invalid argument) Expected Results: Operations can be dealt by NFS Server. # ./check_utf8 mkdir '??' ok. opendir '??' ok. rmdir '??' ok. open '??' ok. rename '??' to '??' ok. unlink file '??' ok. Summary of actions taken to resolve issue: None Location of diagnostic data: None Hardware configuration: Model: PRIMERGY TX150 S5 CPU Info: Intel(R) Xeon(R) CPU 3040 @ 1.86GHz Memory Info: 6GB Business Impact: None. Target Release: 4.9 Errata Request: No Hotfix Request: No ------------------------------------------------------------
Created attachment 348844 [details] testcase from Fujitsu
Created attachment 348845 [details] patch from Fujitsu
I was able to reproduce this problem and the patch resolves the problem.
Hopefully, if we are going to remove this support, then no customers were depending upon it for reasons of their own...
I haven't tested it yet, but the patch looks fairly straightforward. I don't forsee any technical issues with it. The only real questions are: 1) is this a critical enough problem to warrant a fix in RHEL4 now that it's in maintenance mode? 2) is anyone actually depending on this behavior? It seems doubtful, but we have to consider the possibility that some apps that may be expecting EINVAL here will suddenly fail when they don't get an error. For now, I'll plan to add this to my test kernels so that it gets some soak time there. Before I propose this for inclusion however, I'll need some justification for this change. The fact that the bug description says "Business Impact: none" would seem to argue against its inclusion.
From the customer: -------------------------------------------------------- Yes, there is no customer who is perplexed with this problem. So I will leave whether to the fix. --------------------------------------------------------
In that case, I move that we close this as WONTFIX. Even though it sounds fairly harmless, it is a behavior change. There isn't a compelling reason to risk breaking applications that may be dependent on the current behavior. If that situation changes then reopen this bug and we can reevaluate it.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.