Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1209303imm; Wed, 11 Jul 2018 20:12:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdYc6TFddHYA072qZ8uJJBtjSPj6etvOu5JrkyogyoTG+0M2hqjNfmSEmKdayEYOfEz70rS X-Received: by 2002:a62:9683:: with SMTP id s3-v6mr495287pfk.191.1531365165479; Wed, 11 Jul 2018 20:12:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531365165; cv=none; d=google.com; s=arc-20160816; b=Z3Q35jRh/9+QyywucYATynbbD8YQhoO1Yy3vGSMcwSHO0zdH8DHQc7n6h0eaUXG+DB Sp6+LIIMe0pgACXND9qJluADfEBOMP/gy+NHioXBjiuSwjDSUZdKFmB77j/fslyo9c94 D5yG2pxcJl9qqs6p3lxrVkUKBfbrlMOFEjt51OLQ8cBE+5hceewSbnoo2yJlSEJx21yZ Czx76lRbyL5pkUcP3dlMXTDazTK8LbBjKuV0a6/D1jbV8XSHLSRb+I1YtJpj4KqHJVs5 nZUPPxCaRhek6PeKKd4+Atew3lLcPRWckXENUScmYz/Kn85/c5E8pt1YewAJEo393fCh 14LQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=kRo68BOymOWiaNcezIKCiq6XmQ1qg2V5SLOm6qTD6Kw=; b=veAaPwku/nRoKy3NIUVM+e8gs2FuyXff/gsGEkVJUMBV5ukuGx+b/Af3tj7BZGm6Pd PdcmfDUm8THpAFQZwkJPKD5VSc64z8UBqjnm05A0eTGEbLibn5f9MpLzj0wp5xF7e1pf bu7LA8rclUrjJVlNsvSemMrUQouYZ9qFrsAZYSnV9sxhtztFcP8jyueziu0Tqyos/MTG YjJ0MQwXUQgQlIXnvmmCg+wXQXwshnprfTxU/7Iwti9BlRX5aqyhrIHsrxRjjGC757uL I7yyHNYpVLdExRPIV6sV0a+q2E1KuxLwnaNtE5UQxxT054O4Y6N6hh1q63dsattPi78e WG8A== 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 73-v6si21166418ple.157.2018.07.11.20.12.30; Wed, 11 Jul 2018 20:12:45 -0700 (PDT) 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 S2391200AbeGLCX1 (ORCPT + 99 others); Wed, 11 Jul 2018 22:23:27 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:45492 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2389318AbeGLCX1 (ORCPT ); Wed, 11 Jul 2018 22:23:27 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 6AB706DAF893D; Thu, 12 Jul 2018 10:16:10 +0800 (CST) Received: from [10.177.253.249] (10.177.253.249) by smtp.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.382.0; Thu, 12 Jul 2018 10:16:07 +0800 Subject: Re: [V9fs-developer] [PATCH v2 2/6] 9p: Change p9_fid_create calling convention To: Matthew Wilcox , Dominique Martinet References: <20180711210225.19730-1-willy@infradead.org> <20180711210225.19730-3-willy@infradead.org> CC: Latchesar Ionkov , Eric Van Hensbergen , , Ron Minnich , , From: piaojun Message-ID: <5B46B9BC.4010909@huawei.com> Date: Thu, 12 Jul 2018 10:15:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20180711210225.19730-3-willy@infradead.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.253.249] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org LGTM On 2018/7/12 5:02, Matthew Wilcox wrote: > Return NULL instead of ERR_PTR when we can't allocate a FID. The ENOSPC > return value was getting all the way back to userspace, and that's > confusing for a userspace program which isn't expecting read() to tell it > there's no space left on the filesystem. The best error we can return to > indicate a temporary failure caused by lack of client resources is ENOMEM. > > Maybe it would be better to sleep until a FID is available, but that's > not a change I'm comfortable making. > > Signed-off-by: Matthew Wilcox Reviewed-by: Jun Piao > --- > net/9p/client.c | 23 +++++++++-------------- > 1 file changed, 9 insertions(+), 14 deletions(-) > > diff --git a/net/9p/client.c b/net/9p/client.c > index 999eceb8af98..389a2904b7b3 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -913,13 +913,11 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt) > p9_debug(P9_DEBUG_FID, "clnt %p\n", clnt); > fid = kmalloc(sizeof(struct p9_fid), GFP_KERNEL); > if (!fid) > - return ERR_PTR(-ENOMEM); > + return NULL; > > ret = p9_idpool_get(clnt->fidpool); > - if (ret < 0) { > - ret = -ENOSPC; > + if (ret < 0) > goto error; > - } > fid->fid = ret; > > memset(&fid->qid, 0, sizeof(struct p9_qid)); > @@ -935,7 +933,7 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt) > > error: > kfree(fid); > - return ERR_PTR(ret); > + return NULL; > } > > static void p9_fid_destroy(struct p9_fid *fid) > @@ -1137,9 +1135,8 @@ struct p9_fid *p9_client_attach(struct p9_client *clnt, struct p9_fid *afid, > p9_debug(P9_DEBUG_9P, ">>> TATTACH afid %d uname %s aname %s\n", > afid ? afid->fid : -1, uname, aname); > fid = p9_fid_create(clnt); > - if (IS_ERR(fid)) { > - err = PTR_ERR(fid); > - fid = NULL; > + if (!fid) { > + err = -ENOMEM; > goto error; > } > fid->uid = n_uname; > @@ -1188,9 +1185,8 @@ struct p9_fid *p9_client_walk(struct p9_fid *oldfid, uint16_t nwname, > clnt = oldfid->clnt; > if (clone) { > fid = p9_fid_create(clnt); > - if (IS_ERR(fid)) { > - err = PTR_ERR(fid); > - fid = NULL; > + if (!fid) { > + err = -ENOMEM; > goto error; > } > > @@ -2018,9 +2014,8 @@ struct p9_fid *p9_client_xattrwalk(struct p9_fid *file_fid, > err = 0; > clnt = file_fid->clnt; > attr_fid = p9_fid_create(clnt); > - if (IS_ERR(attr_fid)) { > - err = PTR_ERR(attr_fid); > - attr_fid = NULL; > + if (!attr_fid) { > + err = -ENOMEM; > goto error; > } > p9_debug(P9_DEBUG_9P, >