Bug 228854

Summary: nfs protocol V3 :write procedure patch
Product: Red Hat Enterprise Linux 5 Reporter: Peter Staubach <staubach>
Component: kernelAssignee: Peter Staubach <staubach>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: steved, xur
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2007-0959 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-07 19:40:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch
none
Proposed patch none

Description Peter Staubach 2007-02-15 16:15:00 UTC
+++ 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

Comment 1 Peter Staubach 2007-02-15 16:16:29 UTC
Created attachment 148120 [details]
Proposed patch

Comment 2 RHEL Program Management 2007-04-24 14:26:30 UTC
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.

Comment 3 Peter Staubach 2007-05-02 15:41:45 UTC
*** Bug 223755 has been marked as a duplicate of this bug. ***

Comment 7 Don Zickus 2007-06-12 19:00:43 UTC
in 2.6.18-24.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 10 errata-xmlrpc 2007-11-07 19:40:34 UTC
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