J. Bruce Fields wrote:
> On Wed, Jan 24, 2007 at 02:20:20PM -0500, Chuck Lever wrote:
>> The RPC buffer size estimation logic in net/sunrpc/clnt.c always
>> significantly overestimates the requirements for the buffer size.
>> A little instrumentation demonstrated that in fact rpc_malloc was never
>> allocating the buffer from the mempool, but almost always called kmalloc.
>>
>> To compute the size of the RPC buffer more precisely, split p_bufsiz into
>> two fields; one for the argument size, and one for the result size.
>>
>> So now we will compute the sum of the exact call and reply header sizes,
>> and split the RPC buffer precisely between the two.  That should keep
>> almost all RPC buffers within the 2KiB buffer mempool limit.
> 
> One other worry: after this patch, as I understand it, a small mistake
> in any of the definitions of the *_sz macros could allow a buffer
> overflow that RPC_SLACK_SPACE previously prevented.
> 
> Those definitions are all handwritten, and I'd be suprised if there
> aren't at least a few minor errors.
> 
> I'd certainly rather have these calculations be exact than depend on
> this big RPC_SLACK_SPACE fudge factor, but is there some way we could
> verify those macros first?

I've been running Connectathon and fsx-odirect with hundreds of 
thousands of ops on a kernel that has all the slab debugging options 
enabled.  I haven't hit a problem yet.

And besides, the RPC buffers are all a fixed size (2kiB), and much 
larger than required already.  The slack is "built in" to the buffer size.