linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yasunori Goto <y-goto@fujitsu.com>
To: linux-rdma@vger.kernel.org, Doug Ledford <dledford@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>
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	[thread overview]
Message-ID: <20210818082702.692117-1-y-goto@fujitsu.com> (raw)

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 <y-goto@fujitsu.com>
---
 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;
 	}
 
-- 
2.31.1


             reply	other threads:[~2021-08-18  8:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  8:27 Yasunori Goto [this message]
2021-08-19 23:10 ` [PATCH] RDMA/core: EPERM should be returned when # of pined pages is over ulimit Jason Gunthorpe
2021-08-20  0:36   ` Yasunori Goto
2021-08-20  8:45     ` Yasunori Goto
2021-08-26 13:32       ` Jason Gunthorpe
2021-08-27  0:08         ` Gotou, Yasunori/五島 康文

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210818082702.692117-1-y-goto@fujitsu.com \
    --to=y-goto@fujitsu.com \
    --cc=dledford@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).