Re: [PATCH 2/2] rpc: Add -EPERM processing for xs_udp_send_request()

[Jason Baron <jbaron@akamai.com>]

On 09/18/2014 04:51 PM, Trond Myklebust wrote:
> On Thu, Sep 18, 2014 at 3:51 PM, Jason Baron <jbaron@akamai.com> wrote:
>> If an iptables drop rule is added for an nfs server, the client can end up in
>> a softlockup. Because of the way that xs_sendpages() is structured, the -EPERM
>> is ignored since the prior bits of the packet may have been successfully queued
>> and thus xs_sendpages() returns a non-zero value. Then, xs_udp_send_request()
>> thinks that because some bits were queued it should return -EAGAIN. We then try
>> the request and again and a softlockup occurs. The test sequence is simply:
>>
>> 1) open a file on the nfs server '/nfs/foo' (mounted using udp)
>> 2) iptables -A OUTPUT -d <nfs server ip> -j DROP
>> 3) write to /nfs/foo
>> 4) close /nfs/foo
>> 5) iptables -D OUTPUT -d <nfs server ip> -j DROP
>>
>> The softlockup occurs in step 4 above.
> For UDP, the expected and documented behaviour in the case above is as follows:
> - if the mount is soft, then return EIO on the first major timeout.

yeah - so this case is a softlockup in my testing :(

> - if the mount is hard, then retry indefinitely on timeout.
>
> Won't these 2 patches end up propagating an EPERM to the application?
> That would be a definite violation of both hard and soft semantics.

ok, yeah it does propogate the -EPERM up - I wasn't aware of the correct
semantics - thanks.

I can rework the patches such that they return -EIO instead for a soft mount,
and verify that we keep retrying for a hard one.

Thanks,

-Jason