From patchwork Wed Aug 18 08:27:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yasunori Gotou (Fujitsu)" X-Patchwork-Id: 12443621 X-Patchwork-Delegate: jgg@ziepe.ca Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAE8EC4338F for ; Wed, 18 Aug 2021 08:34:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A4BE160C3E for ; Wed, 18 Aug 2021 08:34:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238345AbhHRIfD (ORCPT ); Wed, 18 Aug 2021 04:35:03 -0400 Received: from esa2.hc1455-7.c3s2.iphmx.com ([207.54.90.48]:57945 "EHLO esa2.hc1455-7.c3s2.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238324AbhHRIfB (ORCPT ); Wed, 18 Aug 2021 04:35:01 -0400 X-Greylist: delayed 429 seconds by postgrey-1.27 at vger.kernel.org; Wed, 18 Aug 2021 04:35:01 EDT IronPort-SDR: eZOYNhwR0QcwmckGAcHN1S7jtL4dKW61EFLfHs6Cz/Adw12ea2cO9bp8tuhDzyx03zjLDPnI0Y 5r7vFsdHR/Kig7nkqWgj3lAipTkqobTGBUv5WMDF3a2D/ErklBaWFFu5nBU5LL4b/uAKzqKKOZ TPTnHWjeZYZQiZYJt/aPqoJXWY0it9wWIK3y9XsV6tQ0SRGNeEgxfYJxmv/kpesX4f6EQDSl7e B2rRmk+VqJYWSe6qoxzDFurE5OXIkPEYq62ihctuqxl3xQ7n0PT3a8kZsqoqX5fZVx2NyVzz55 pTp763m4mGriyN39giynBY+u X-IronPort-AV: E=McAfee;i="6200,9189,10079"; a="40636994" X-IronPort-AV: E=Sophos;i="5.84,330,1620658800"; d="scan'208";a="40636994" Received: from unknown (HELO yto-r4.gw.nic.fujitsu.com) ([218.44.52.220]) by esa2.hc1455-7.c3s2.iphmx.com with ESMTP; 18 Aug 2021 17:27:15 +0900 Received: from yto-m1.gw.nic.fujitsu.com (yto-nat-yto-m1.gw.nic.fujitsu.com [192.168.83.64]) by yto-r4.gw.nic.fujitsu.com (Postfix) with ESMTP id 42FFC6CCA0 for ; Wed, 18 Aug 2021 17:27:14 +0900 (JST) Received: from m3050.s.css.fujitsu.com (msm.b.css.fujitsu.com [10.134.21.208]) by yto-m1.gw.nic.fujitsu.com (Postfix) with ESMTP id 98EB83918B for ; Wed, 18 Aug 2021 17:27:13 +0900 (JST) Received: from jegan.fujitsu.com (unknown [10.124.72.187]) by m3050.s.css.fujitsu.com (Postfix) with ESMTP id 74CA3A7; Wed, 18 Aug 2021 17:27:13 +0900 (JST) From: Yasunori Goto To: linux-rdma@vger.kernel.org, Doug Ledford , Jason Gunthorpe Cc: y-goto@fujitsu.com Subject: [PATCH] RDMA/core: EPERM should be returned when # of pined pages is over ulimit Date: Wed, 18 Aug 2021 17:27:02 +0900 Message-Id: <20210818082702.692117-1-y-goto@fujitsu.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Hello, When I started to use SoftRoCE, I'm very confused by ENOMEM error output even if I gave enough memory. I think EPERM is more suitable for uses to solve error rather than ENOMEM at here of ib_umem_get() when # of pinned pages is over ulimit. This is not "memory is not enough" problem, because driver can succeed to pin enough amount of pages, but it is larger than ulimit value. The hard limit of "max locked memory" can be changed by limit.conf. In addition, this checks also CAP_IPC_LOCK, it is indeed permmission check. So, I think the following patch. If there is a intention why ENOMEM is used here, please let me know. Otherwise, I'm glad if this is merged. Thanks. --- When # of pinned pages are larger than ulimit of "max locked memory" without CAP_IPC_LOCK, current ib_umem_get() returns ENOMEM. But it does not mean "not enough memory", because driver could succeed to pinned enough pages. This is just capability error. Even if a normal user is limited his/her # of pinned pages, system administrator can give permission by change hard limit of this ulimit value. To notify correct information to user, ib_umem_get() should return EPERM instead of ENOMEM at here. Signed-off-by: Yasunori Goto --- drivers/infiniband/core/umem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c index 0eb40025075f..9771134649e9 100644 --- a/drivers/infiniband/core/umem.c +++ b/drivers/infiniband/core/umem.c @@ -205,7 +205,7 @@ struct ib_umem *ib_umem_get(struct ib_device *device, unsigned long addr, new_pinned = atomic64_add_return(npages, &mm->pinned_vm); if (new_pinned > lock_limit && !capable(CAP_IPC_LOCK)) { atomic64_sub(npages, &mm->pinned_vm); - ret = -ENOMEM; + ret = -EPERM; goto out; }