Bug 230311 - [NFSv3] reply size of readdir/readdirplus procedure alaways larger than request [NEEDINFO]
[NFSv3] reply size of readdir/readdirplus procedure alaways larger than request
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-28 01:10 EST by yjwei
Modified: 2015-11-17 05:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-17 05:02:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
steved: needinfo? (yjwei)


Attachments (Terms of Use)
patch of this bug (1.86 KB, patch)
2007-02-28 01:10 EST, yjwei
no flags Details | Diff

  None (edit)
Description yjwei 2007-02-28 01:10:05 EST
Description of problem:
  NFSv3 reply size of readdir/readdirplus procedure alaways larger than request.
  RFC1813 3.3.16 Procedure 16: READDIR - Read From Directory has following 
define:
      count
         The maximum size of the READDIR3resok structure, in
         bytes.  The size must include all XDR overhead. The
         server is free to return less than count bytes of
         data.
  but the kernel to used this count argument as the size of dirlist3, exclude 
the size of post_attr_attr and cookieverf. So the reply size alaways larger 
than request.
Comment 1 yjwei 2007-02-28 01:10:05 EST
Created attachment 148897 [details]
patch of this bug
Comment 2 Steve Dickson 2007-03-22 08:35:03 EDT
How does this help the server (or client) process 
readdirplus-es? 
Comment 3 yjwei 2007-03-27 01:58:24 EDT
If server send a READDIR or READDIRPLUS reply to client which is larger than 
client's request, client may treat it with RPC_GARBAGE and still retry. The 
kernel's implement does not accord with the RFC's define. I have a test case 
about this, reply a large reddirplus to RHEL3U8 nfs client, which let following 
umount kernel painic, I'm not sure whether this is the real reason.
Comment 4 yjwei 2007-04-24 22:29:56 EDT
The implement of kernel does not in correspondence with the RFC, does anyone 
think this problem need to be fixed?
Comment 7 Steve Dickson 2007-04-25 13:23:27 EDT
How reproducible is your test case? Unfortunately Oops at 
umount time can be caused by a number of things... 

Also are you seeing any interoperability problems? I 
would suspect we would see this type of problem if 
not adhering to the spec is a problem?
Comment 8 RHEL Product and Program Management 2007-04-25 17:01:25 EDT
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 9 RHEL Product and Program Management 2007-09-07 15:54:55 EDT
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.
Comment 10 Steve Whitehouse 2015-11-17 05:02:52 EST
This was put into needinfo years ago and has had no updates. Comment #6 says it is very low priority. At this stage I don't think we should be fixing this unless it is high priority at least, so going to close it. Please reopen if this is not correct.

Note You need to log in before you can comment on or make changes to this bug.