On 09/18/2014 04:51 PM, Trond Myklebust wrote: > On Thu, Sep 18, 2014 at 3:51 PM, Jason Baron <jbaron@xxxxxxxxxx> 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 -- 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
