Date: Fri, 24 Mar 2017 23:42:36 +0200
From: Tuomas Tynkkynen <tuomas@tuxera.com>
To: <linux-fsdevel@vger.kernel.org>,
        <v9fs-developer@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>
CC: Eric Van Hensbergen <ericvh@gmail.com>
Subject: 9p and EINTR?
Message-ID: <20170324234236.572d3576@duuni>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1448
Lines: 35

Hi fsdevel,

Some users of our distro (NixOS) ran into some 9p funkiness again...
Eventually it was traced down to many 9p filesystem calls getting
interrupted by signals (here, it was bash receiving SIGCHLDs from
background jobs exiting) and returning with -EINTR. E.g. stat() manpage
doesn't list EINTR as a valid error return and bash isn't prepared
to handle that (any stat() failure when probing for a command
in PATH is treated like ENOENT).

So a quick patch like this to 9p already seemed to help (though
also a bunch of users in trans_rdma.c and trans_virtio.c
probably need similar treatment):

diff --git a/net/9p/client.c b/net/9p/client.c
index 3ce672af1596..f1c8ad373f90 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -749,8 +749,7 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
        }
 again:
        /* Wait for the response */
-       err = wait_event_interruptible(*req->wq,
-                                      req->status >= REQ_STATUS_RCVD);
+       err = wait_event_killable(*req->wq, req->status >= REQ_STATUS_RCVD);
 
        /*
         * Make sure our req is coherent with regard to updates in other

But I am not sure if it would be the right thing to make absolutely all
9p calls non-interruptible. So if anybody has pointers on what VFS
calls are permitted to fail with -EINTR, or what other network
filesystems do in similar situations, it would be greatly appreciated!

- Tuomas