On Thu, Sep 18, 2014 at 5:02 PM, Jason Baron <jbaron@xxxxxxxxxx> wrote: > 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. > Doesn't the soft timeout currently trigger after the major timeout? If not, do we understand why it isn't doing so? I'm just trying to figure out what the motivation is for this patch. -- 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
