From patchwork Fri Mar 24 21:42:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tuomas Tynkkynen X-Patchwork-Id: 9644049 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0F19560327 for ; Fri, 24 Mar 2017 21:42:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F269925404 for ; Fri, 24 Mar 2017 21:42:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E41F62787C; Fri, 24 Mar 2017 21:42:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id DE15025404 for ; Fri, 24 Mar 2017 21:42:50 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1crWyt-0002nL-AG; Fri, 24 Mar 2017 21:42:47 +0000 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1crWyt-0002nG-11 for v9fs-developer@lists.sourceforge.net; Fri, 24 Mar 2017 21:42:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of tuxera.com designates 82.197.21.84 as permitted sender) client-ip=82.197.21.84; envelope-from=tuomas@tuxera.com; helo=mx1.mpynet.fi; Received: from mx1.mpynet.fi ([82.197.21.84]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1crWyr-0001gW-Db for v9fs-developer@lists.sourceforge.net; Fri, 24 Mar 2017 21:42:47 +0000 Date: Fri, 24 Mar 2017 23:42:36 +0200 From: Tuomas Tynkkynen To: , , Message-ID: <20170324234236.572d3576@duuni> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu) MIME-Version: 1.0 X-ClientProxiedBy: tuxera-exch.ad.tuxera.com (10.20.48.11) To tuxera-exch.ad.tuxera.com (10.20.48.11) Received-SPF: none X-Headers-End: 1crWyr-0001gW-Db Cc: Eric Van Hensbergen Subject: [V9fs-developer] 9p and EINTR? X-BeenThere: v9fs-developer@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: v9fs-developer-bounces@lists.sourceforge.net X-Virus-Scanned: ClamAV using ClamSMTP 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): 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot 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