+++ This bug was initially created as a clone of Bug #222798 +++ Description of problem: Hi: I hope this is the right list for this. My group is engaged in the NFSV3 protocol comformance test.it means ,we want to prove whether the realization of the NFSV3 protocol in all versions of the REDHAT is according to the RFC(here ,we use RFC 1813). When we test the WRITE procedure in the realization of the REDHAT with the newest kernel ,we find some inconsistent definitions between the newest kernel and RFC1813.P49 struct WRITE3args { nfs_fh3 file; offset3 offset; count3 count; stable_how stable; opaque data<>; }; struct WRITE3resok { wcc_data file_wcc; count3 count; stable_how committed; writeverf3 verf; }; struct WRITE3resfail { wcc_data file_wcc; }; count The number of bytes of data to be written. If count is 0, the WRITE will succeed and return a count of 0, barring errors due to permissions checking. The size of data must be less than or equal to the value of the wtmax field in the FSINFO reply structure for the file system that contains file. If greater, the server may write only wtmax bytes, resulting in a short write. It told us that when the argument count is zero ,the write procedure still should be succeed.But in the test ,when we send the packet with the count equal to zero,the server will return fail with the rpc_garbage error.Obviously it is inconsistent with RFC definition.So we make the patch as follows: Signed-off-by: xurui <xur> --- linux-2.6.19.1/fs/nfsd/nfs3xdr.c 2006-12-12 03:32:53.000000000 +0800 +++ linux-2.6.19.1/fs/nfsd/nfs3xdr.new.c 2007-01-03 18:23:09.000000000 +0800 @@ -389,7 +389,7 @@ nfs3svc_decode_writeargs(struct svc_rqst rqstp->rq_vec[v].iov_len = len; args->vlen = v+1; - return args->count == args->len && rqstp->rq_vec[0].iov_len > 0; + return args->count == args->len; } int Thanks Xu Rui -- Additional comment from staubach on 2007-02-05 16:55 EST -- It seems that the NFS server does not handle zero length WRITE requests correctly. It also does not do much in the way of checking the RPC request to see whether the data, which is supposed to be included in the request, is actually included in the request. -- Additional comment from staubach on 2007-02-05 16:58 EST -- Created an attachment (id=147410) Proposed patch -- Additional comment from xur on 2007-02-08 03:26 EST -- We have applied your patch,then our tests succeed.thank you for your help. We want to know Whether this patch will apply to the latest kernel or not ? If it will be applied ,our team needn't patch the kernel every time. Thanks Xu Rui -- Additional comment from staubach on 2007-02-08 09:46 EST -- Thanx for testing the proposed RHEL-4 patch. No, the current patch will not apply either RHEL-5 or to upstream. I have a patch constructed and tested for RHEL-5 and I am working on testing a patch for upstream. When I get the upstream patch completed, I will post it upstream for NeilB. Then, I will file a bugzilla for the RHEL-5 problem and then send both the RHEL-4 and RHEL-5 patches to rhkernel-list for inclusion into the respective releases. -- Additional comment from xur on 2007-02-13 22:11 EST -- Hi.it is me .I still have some question . According to the RFC 1813 "The size of data must be less than or equal to the value of the wtmax field in the FSINFO reply structure for the file system that contains file. If greater, the server may write only wtmax bytes, resulting in a short write." It shows that when the size of data is greater than the value of the wtmax,server may write only wtmax bytes.however if we use your patch,server will write unsuccessfully in this case.Maybe something wrong? please confirm .thank you! -- Additional comment from staubach on 2007-02-15 09:26 EST -- Hmmm. I don't know what "write unsuccessfully" means. However, I do agree, that there is _another_ bug there. An already existing bug, but one that we might as well fix. If the size is limited by NFSSVC_MAXBLKSIZE, then args->count and args->len do not get adjusted correctly. I will add this support and attach another patch when it is ready. -- Additional comment from staubach on 2007-02-15 11:08 EST -- Created an attachment (id=148117) Proposed patch
Created attachment 148120 [details] Proposed patch
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 223755 has been marked as a duplicate of this bug. ***
in 2.6.18-24.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0959.html