On Fri, Feb 09, 2018 at 03:04:42PM +0000, Trond Myklebust wrote: > For NFSv4, you would have the option of returning NFS4ERR_RESOURCE or > possibly NFS4ERR_INVAL (personally, I'd prefer the latter, since > NFS4ERR_RESOURCE is too wooly). > > For NFSv4.1 or above, you probably have a choice of NFS4ERR_REQ_TOO_BIG > (if the size is greater than ca_maxrequestsize) or NFS4ERR_INVAL. I think this sort of problem is typically found early in the rpc code (probably the check against sv_max_mesg in net/sunrpc/svcsock.c:svc_tcp_recv_record()). It drops the connection. I'm not sure why. Returning an NFS-level error does sound friendlier. I guess I'd do that by throwing away the rest of the request data and setting a flag on the svc_rqst saying "this request was too long, don't trust the data" and then making NFS check for that flag somewhere early on. The only case I can recall seeing this in practice is when the limits change across reboots. Which is something to avoid. But the choice of failure mode might make this more or less easy to diagnose or recover from.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
