Received: by 10.223.185.116 with SMTP id b49csp1116950wrg; Tue, 20 Feb 2018 13:41:11 -0800 (PST) X-Google-Smtp-Source: AH8x227Eq3XFbWb3optuLM4XmxfRfJ/9AV22YPCixE6aamyQYOltmmF3h0Lij9W0q2q8k85YXCbD X-Received: by 10.98.11.194 with SMTP id 63mr986364pfl.172.1519162871688; Tue, 20 Feb 2018 13:41:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519162871; cv=none; d=google.com; s=arc-20160816; b=TrGFmNUj3MuCN5FSk9TBBNs7xIveZp4emx7HZQcD1/sR1gN2Omnk71XCKW4IZWeiA0 /ToMsq9dMkiclpH0MkglA6xAYptQsh8+RFIT8jftKVLG7gCV/z3ZJKf2SCGIhuneQods L2tXwvREbU0J9eoC1ILZwAeCyk0NMOOHbxrLS3mf83cmyRdnHmPW1q8qCutqF59zOu4j rS34C1xZ60bTO+jrIkJhQ+kiSJOIXwny/f6aVtbmws8j3pg8AcroSjKKix5SzkXOH9EY plUAV6fbrxdCrVFUD7IsACkZoEDL2fsogcTVrkKqRNkdF9lX1yOCYpNyy7DCQkHKCRlu lswg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=xgFUAHzloVgyhn4XFm6AJxyjQcV4ZRKVM1OUNWy4AiE=; b=usVlcrV4ci+eJKCgWHyqwffzACzs+1+eniKjIZf+1HLRgGXqbHzxDzX42GerAT6k3m 5/bMc+VW7tK+PCsepVOLLKUeD1LBISVl+4UyfV8eXBlGwYLaxkF2cY3iHdnLsvGApl+3 LO+3E1tUuyS5tqH8ioxBcDmRQyFRhBPALFpzROqHe6KAVQ3GZU2u8a44B8hY40/ozkG9 ZCIjg6PJPgIa2M7v6vkvI2xYNcsde3yyKRdjv+uJ+NEM6T6HbItyiXt2jSu8vxsysgh4 Ith3Cs0g4I8qJTnraca7u0e1P2xMhiGKt6HRM1Bjkera4fg56WnmqI1qOnBm3SKvLmrS FY6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w10si137769pge.65.2018.02.20.13.40.56; Tue, 20 Feb 2018 13:41:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751135AbeBTVkR (ORCPT + 99 others); Tue, 20 Feb 2018 16:40:17 -0500 Received: from 15.mo5.mail-out.ovh.net ([178.33.107.29]:48658 "EHLO 15.mo5.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbeBTVkQ (ORCPT ); Tue, 20 Feb 2018 16:40:16 -0500 X-Greylist: delayed 14996 seconds by postgrey-1.27 at vger.kernel.org; Tue, 20 Feb 2018 16:40:16 EST Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 51CF318DD5A for ; Tue, 20 Feb 2018 17:52:34 +0100 (CET) Received: from bahia.lan (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player786.ha.ovh.net (Postfix) with ESMTPSA id 252768009F; Tue, 20 Feb 2018 17:52:26 +0100 (CET) Date: Tue, 20 Feb 2018 17:48:16 +0100 From: Greg Kurz To: Al Viro Cc: linux-kernel@vger.kernel.org, Latchesar Ionkov , Eric Van Hensbergen , netdev@vger.kernel.org, v9fs-developer@lists.sourceforge.net, Ron Minnich , "David S. Miller" Subject: Re: [V9fs-developer] [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace Message-ID: <20180220174816.0ef05769@bahia.lan> In-Reply-To: <151811152925.12219.16418114797025615002.stgit@bahia.lab.toulouse-stg.fr.ibm.com> References: <151811152925.12219.16418114797025615002.stgit@bahia.lab.toulouse-stg.fr.ibm.com> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 5931803662776834327 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrgeejgdeludcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Al, It's been two years without any sign of life from 9p maintainers... :-\ Would you apply (or nack) this patch ? Thanks, -- Greg PS: in the case you apply it, probable Cc stable@vger.kernel.org as well On Thu, 08 Feb 2018 18:38:49 +0100 Greg Kurz wrote: > If it was interrupted by a signal, the 9p client may need to send some > more requests to the server for cleanup before returning to userspace. > > To avoid such a last minute request to be interrupted right away, the > client memorizes if a signal is pending, clear TIF_SIGPENDING, handle > the request and call recalc_sigpending() before returning. > > Unfortunately, if the transmission of this cleanup request fails for any > reason, the transport returns an error and the client propagates it right > away, without calling recalc_sigpending(). > > This ends up with -ERESTARTSYS from the initially interrupted request > crawling up to syscall exit, with TIF_SIGPENDING cleared by the cleanup > request. The specific signal handling code, which is responsible for > converting -ERESTARTSYS to -EINTR is not called, and userspace receives > the confusing errno value: > > open: Unknown error 512 (512) > > This is really hard to hit in real life. I discovered the issue while > working on hot-unplug of a virtio-9p-pci device with an instrumented > QEMU allowing to control request completion. > > Both p9_client_zc_rpc() and p9_client_rpc() functions have this buggy > error path actually. Their code flow is a bit obscure and the best > thing to do would probably be a full rewrite: to really ensure this > situation of clearing TIF_SIGPENDING and returning -ERESTARTSYS can > never happen. > > But given the general lack of interest for the 9p code, I won't risk > breaking more things. So this patch simply fix the buggy paths in both > functions with a trivial label+goto. > > Thanks to Laurent Dufour for his help and suggestions on how to find > the root cause and how to fix it. > > Signed-off-by: Greg Kurz > --- > net/9p/client.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/net/9p/client.c b/net/9p/client.c > index 4c8cf9c1631a..5154eaf19fff 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -769,7 +769,7 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...) > if (err < 0) { > if (err != -ERESTARTSYS && err != -EFAULT) > c->status = Disconnected; > - goto reterr; > + goto recalc_sigpending; > } > again: > /* Wait for the response */ > @@ -804,6 +804,7 @@ p9_client_rpc(struct p9_client *c, int8_t type, const char *fmt, ...) > if (req->status == REQ_STATUS_RCVD) > err = 0; > } > +recalc_sigpending: > if (sigpending) { > spin_lock_irqsave(¤t->sighand->siglock, flags); > recalc_sigpending(); > @@ -867,7 +868,7 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type, > if (err == -EIO) > c->status = Disconnected; > if (err != -ERESTARTSYS) > - goto reterr; > + goto recalc_sigpending; > } > if (req->status == REQ_STATUS_ERROR) { > p9_debug(P9_DEBUG_ERROR, "req_status error %d\n", req->t_err); > @@ -885,6 +886,7 @@ static struct p9_req_t *p9_client_zc_rpc(struct p9_client *c, int8_t type, > if (req->status == REQ_STATUS_RCVD) > err = 0; > } > +recalc_sigpending: > if (sigpending) { > spin_lock_irqsave(¤t->sighand->siglock, flags); > recalc_sigpending(); > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > V9fs-developer mailing list > V9fs-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/v9fs-developer