All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Matthew Wilcox <willy@infradead.org>
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: Wed, 5 Jul 2023 16:53:22 -0700	[thread overview]
Message-ID: <20230705235322.GD41006@monkey> (raw)
In-Reply-To: <ZKX7PerFpnoMT5Pc@casper.infradead.org>

On 07/06/23 00:22, Matthew Wilcox wrote:
> 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.

My concern is that this is the approach I took with huegtlb MADV_DONTNEED,
and this caused problems discussed and eventually modified here:
https://lore.kernel.org/linux-mm/20221021154546.57df96db@imladris.surriel.com/

In the MADV_DONTNEED case we were throwing away data.  With mprotect we are
only modifying access to data.
-- 
Mike Kravetz


  reply	other threads:[~2023-07-05 23:54 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
2023-07-05 23:53   ` Mike Kravetz [this message]
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=20230705235322.GD41006@monkey \
    --to=mike.kravetz@oracle.com \
    --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=peterx@redhat.com \
    --cc=riel@surriel.com \
    --cc=willy@infradead.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 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.