linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Miaohe Lin <linmiaohe@huawei.com>, akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: Remove obsolete comment in vma_has_reserves()
Date: Thu, 4 Feb 2021 13:32:54 -0800	[thread overview]
Message-ID: <8f2f3bac-5b33-a560-9b84-b50972739636@oracle.com> (raw)
In-Reply-To: <20210204111500.24111-1-linmiaohe@huawei.com>

On 2/4/21 3:15 AM, Miaohe Lin wrote:
> Shared mappings are allowed to be created without reservations since
> commit c37f9fb11c97 ("hugetlb: allow huge page mappings to be created
> without reservations"). Remove this obsolete comment which may cause
> confusing.
> 
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
>  mm/hugetlb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 9501ec6ad517..cf82629319ed 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -998,7 +998,6 @@ static bool vma_has_reserves(struct vm_area_struct *vma, long chg)
>  			return false;
>  	}
>  
> -	/* Shared mappings always use reserves */

I would not say the comment is entirely obsolete or does not apply here.

As mentioned in the commit message, commit c37f9fb11c97 allowed hugetlb
mappings to be created without reserves.  It does this by supporting the
MAP_NORESERVE flag which corresponds to the VM_NORESERVE vma flag.

Right before this comment, a check is made for VM_NORESERVE and the
routine will return.  Therefore, by the time we get to this comment
we know MAP_NORESERVE does not apply and there are reserves associated
the shared mapping.  In this case the comment is making a distinction
between shared mappings which will always have reserves, and private
mappings which may or may not have reserves depending on ownership.

I would suggest either leaving the comment as is, or modifying to include
the information above.  To me, the three distinct blocks of code handling
the NORESERVE, shared and private cases makes things fairly clear and
the comment does apply in that context.
-- 
Mike Kravetz

>  	if (vma->vm_flags & VM_MAYSHARE) {
>  		/*
>  		 * We know VM_NORESERVE is not set.  Therefore, there SHOULD
> 

  reply	other threads:[~2021-02-04 21:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 11:15 [PATCH] mm/hugetlb: Remove obsolete comment in vma_has_reserves() Miaohe Lin
2021-02-04 21:32 ` Mike Kravetz [this message]
2021-02-05  3:08   ` Miaohe Lin

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=8f2f3bac-5b33-a560-9b84-b50972739636@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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).