All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	David Hildenbrand <david@redhat.com>,
	Rik van Riel <riel@surriel.com>, Michal Hocko <mhocko@suse.com>,
	Peter Xu <peterx@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: mprotect and hugetlb mappings
Date: Thu, 6 Jul 2023 00:22:37 +0100	[thread overview]
Message-ID: <ZKX7PerFpnoMT5Pc@casper.infradead.org> (raw)
In-Reply-To: <20230705230808.GA41006@monkey>

On Wed, Jul 05, 2023 at 04:08:08PM -0700, Mike Kravetz wrote:
> I was recently asked about the behavior of mprotect on a hugetlb
> mapping where addr or addr+len is not hugetlb page size aligned.  As
> one might expect, EINVAL is returned in such cases.  However, the man
> page makes no mention of alignment requirements for hugetlb mappings.
> 
> I am happy to submit man page updates if people agree this is the correct
> behavior.  We might even want to check alignment earlier in the code
> path as we fail when trying to split the vma today.
> 
> An alternative behavior would be to operate on whole hugetlb pages within
> the range addr - addr+len.

After a careful re-reading of the mprotect() man page, I suggest the
following behaviour ...

addr must be a multiple of the hpage size.  Otherwise -EINVAL.
len should be rounded up to hpage size.

I wonder how likely this change would be to break userspace code.
Maybe some test cases.


  reply	other threads:[~2023-07-05 23:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 23:08 mprotect and hugetlb mappings Mike Kravetz
2023-07-05 23:22 ` Matthew Wilcox [this message]
2023-07-05 23:53   ` Mike Kravetz
2023-07-17 16:19     ` Vlastimil Babka
2023-07-17 18:52       ` Mike Kravetz
2023-07-17 19:00         ` David Hildenbrand

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=ZKX7PerFpnoMT5Pc@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.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.