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. - 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. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
