Bug 440057

+++ This bug was initially created as a clone of Bug #404831 +++

Description of problem:
"nfsstat -s" shows negative value.

How reproducible:
When nfsd has taken enough calls to overflow a signed int.

Steps to Reproduce:
Run nfsd service for a long time with many clients doing operations, and 
run "nfsstat -s".

# nfsstat -s
   2007年 10月 24日 水曜日 05:29:02 JST
   Server rpc stats:
   calls      badcalls   badauth    badclnt    xdrcall
>> -2147459460   0          0          0          0         
   Server nfs v3:
   null       getattr    setattr    lookup     access     readlink   
   3       0% 961806770 44% 34884113  1% 356848932 16% 311303203 14% 0  0% 
   read       write      create     mkdir      symlink    mknod      
   58992809  2% 63067804  2% 69266297  3% 12816   0% 0       0% 0       0% 
   remove     rmdir      rename     link       readdir    readdirplus
   103983458  4% 2808    0% 5945055  0% 36564688  1% 34420909  1% 73349994  3% 
   fsstat     fsinfo     pathconf   commit     
   31820   0% 177     0% 0       0% 36532676  1% 

Actual results:
"nfsstat -s" shows negative value.

Expected results:
"nfsstat -s" shows correct value.

Additional info:
/proc/net/rpc/nfsd formats its value as an unsigned int, but nfsstat parses 
this unsigned int with atoi(). It should use atoll().

-- Additional comment from fleite on 2007-11-29 13:51 EST --
Created an attachment (id=273161)
Patch to parse and print values correctly.


-- Additional comment from fleite on 2007-11-29 13:52 EST --
Very simple fix, hope it still makes 4.7.

-- Additional comment from pm-rhel on 2007-11-29 13:54 EST --
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.

-- Additional comment from jlayton on 2008-01-04 10:18 EST --
Looks simple enough...


-- Additional comment from jlayton on 2008-04-01 10:46 EST --
This patch is not upstream and needs to go there first. I'm going to reset this
for 4.8 and we can consider it there. We'll also need to clone this for 5.2.


-- Additional comment from jlayton on 2008-04-01 10:59 EST --
...err make that 5.3...


-- Additional comment from jlayton on 2008-04-01 11:15 EST --
As far as testing this...

The easiest thing might be to custom roll a kernel that initializes the /proc
fields to values that would cause this. I'll plan to do that to verify the fix
and will post the kernel patch here so that QA can use it too...