From: Oscar Salvador <osalvador@suse.de>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
muchun.song@linux.dev, vivek.kasireddy@intel.com, jgg@nvidia.com,
nicolinc@nvidia.com, nathanc@nvidia.com, mochs@nvidia.com
Subject: Re: [PATCH] mm/hugetlb: Fix incorrect error return from hugetlb_reserve_pages()
Date: Tue, 25 Nov 2025 10:33:35 +0100 [thread overview]
Message-ID: <aSV371RAc5mrR84c@localhost.localdomain> (raw)
In-Reply-To: <20251022102956.245736-1-skolothumtho@nvidia.com>
On Wed, Oct 22, 2025 at 11:29:56AM +0100, Shameer Kolothum wrote:
> The function hugetlb_reserve_pages() returns the number of pages added
> to the reservation map on success and a negative error code on failure
> (e.g. -EINVAL, -ENOMEM). However, in some error paths, it may return -1
> directly.
>
> For example, a failure at:
>
> if (hugetlb_acct_memory(h, gbl_reserve) < 0)
> goto out_put_pages;
>
> results in returning -1 (since add = -1), which may be misinterpreted
> in userspace as -EPERM.
>
> Fix this by explicitly capturing and propagating the return values from
> helper functions, and using -EINVAL for all other failure cases.
>
> Fixes: 986f5f2b4be3 ("mm/hugetlb: make hugetlb_reserve_pages() return nr of entries updated")
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
> mm/hugetlb.c | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 795ee393eac0..1767f7599f91 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -7269,6 +7269,7 @@ long hugetlb_reserve_pages(struct inode *inode,
> struct resv_map *resv_map;
> struct hugetlb_cgroup *h_cg = NULL;
> long gbl_reserve, regions_needed = 0;
> + int ret;
>
> /* This should never happen */
> if (from > to) {
> @@ -7308,8 +7309,10 @@ long hugetlb_reserve_pages(struct inode *inode,
> } else {
> /* Private mapping. */
> resv_map = resv_map_alloc();
> - if (!resv_map)
> + if (!resv_map) {
> + ret = -EINVAL;
Why is this one EINVAL? Should not this be ENOMEM?
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2025-11-25 9:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 10:29 [PATCH] mm/hugetlb: Fix incorrect error return from hugetlb_reserve_pages() Shameer Kolothum
2025-10-22 14:39 ` Joshua Hahn
2025-10-24 9:02 ` Shameer Kolothum
2025-11-25 9:33 ` Oscar Salvador [this message]
2025-11-25 10:24 ` Shameer Kolothum
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=aSV371RAc5mrR84c@localhost.localdomain \
--to=osalvador@suse.de \
--cc=jgg@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mochs@nvidia.com \
--cc=muchun.song@linux.dev \
--cc=nathanc@nvidia.com \
--cc=nicolinc@nvidia.com \
--cc=skolothumtho@nvidia.com \
--cc=vivek.kasireddy@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.