Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp237251imm; Thu, 12 Jul 2018 18:19:35 -0700 (PDT) X-Google-Smtp-Source: AAOMgpew7NHeUq8SrokpxsxIlq/YuEN3cH4bdJkzKOx2mL2Wbk/Zh6KFMIS+fm4b/9WokWrbdMPl X-Received: by 2002:a17:902:8309:: with SMTP id bd9-v6mr4247356plb.321.1531444775690; Thu, 12 Jul 2018 18:19:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531444775; cv=none; d=google.com; s=arc-20160816; b=m3VHIobSaNZN2YItdvnd9ChnVGYkMh++V+97Heerybj2FlAORsjk2F4h/grrb98s9h 6eJRwQyop+R2hOmJCasTWHgNORx6wUOBcwXlopwlESzpbCXlmv3dVqYNuSVfXH2Hruhx 6eIhfkE5lZmueuq1vPudoogG71a0ag71oahe7MMIBuERBaZJUu2OJaTkba4CSzLAmNUV Apsp7gqDAp0rZaCdOi2Kysrg9vHyJwNcHD3+xRSOCPdmEi7uJNQI9LrREhW4a+Wohkcc 5wRR/tSopiz6h/QU1VBTuU9lgtpuN43qnVwnQcEV5YqmpzEtCmF3MYabpv+VSMgz5qyD MDag== 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=7oWCknjM93PKpfW4+6h05UUE14zalPnBuBWY7WeqVc0=; b=b46tSD8a4kn/vU6IqROnZgpTUBcTnHQp/BLL+NCdhQEPbvoWuxBrMdOhxIHAtRonJj hEqM6LYl6PQ4jZu318kH3hvRIOvqmsH5KfhyntAl+QWLXNleKn5RhcPvTvZx874xy3/o m4/jiCQ+iTIus66367dJZGRB8q+jt33TBz4ixP6ycPXMchRvwoeYRQr9NC8HGQIdD4Iz lVjiQi8AF1aotmq8lchfIg5KaoanhniPmvCMK+xWsLdgSTPJg8I1ZVuz1VUwy2cRxUIe bGptUT2jZIENgS69GkgEb+kWuVl/I20RfrNB7Ly52CzFhnis3cKXrSGM0EZJ7o+qo9np lbHQ== 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 k14-v6si8728982pga.149.2018.07.12.18.19.20; Thu, 12 Jul 2018 18:19:35 -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 S2387936AbeGMBa4 (ORCPT + 99 others); Thu, 12 Jul 2018 21:30:56 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:9228 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387916AbeGMBa4 (ORCPT ); Thu, 12 Jul 2018 21:30:56 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id DDB278E1F77F; Fri, 13 Jul 2018 09:18:31 +0800 (CST) Received: from [127.0.0.1] (10.177.16.168) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.382.0; Fri, 13 Jul 2018 09:18:31 +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: jiangyiwen Message-ID: <5B47FDE6.60307@huawei.com> Date: Fri, 13 Jul 2018 09:18:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 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.16.168] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: Yiwen Jiang > --- > 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, >