From: Daniel Black <daniel@linux.ibm.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, khlebnikov@openvz.org
Subject: Re: [PATCH] mm: madvise(MADV_DODUMP) allow hugetlbfs pages
Date: Wed, 03 Oct 2018 15:47:35 +1000 [thread overview]
Message-ID: <20181003074520.460bbf17@volution> (raw)
In-Reply-To: <ecbe3fad-4ab7-6549-bafb-5f24ccc36e74@oracle.com>
On Mon, 1 Oct 2018 15:11:32 -0700
Mike Kravetz <mike.kravetz@oracle.com> wrote:
> On 9/29/18 10:46 PM, Daniel Black wrote:
> <snip>
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 972a9eaa898b..71d21df2a3f3 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -96,7 +96,7 @@ static long madvise_behavior(struct
> > vm_area_struct *vma, new_flags |= VM_DONTDUMP;
> > break;
> > case MADV_DODUMP:
> > - if (new_flags & VM_SPECIAL) {
> > + if (!is_vm_hugetlb_page(vma) && new_flags &
> > VM_SPECIAL) {
>
> Thanks Daniel,
>
> This is certainly a regression. My only question is whether this
> condition should be more specific and test the default hugetlb vma
> flags (VM_DONTEXPAND | VM_HUGETLB).
> Or, whether simply checking
> VM_HUGETLB as you have done above is sufficient.
The is_vm_hugetlb_page() function seems widely used elsewhere for that
single purpose.
> Only reason for
> concern is that I am not 100% certain other VM_SPECIAL flags could
> not be set in VM_HUGETLB vma.
They might be, but being a VM_HUGETLB flag is the main criteria for
being able to madvise(DODUMP) on the memory. It highlight its user
memory for the user to do as they wish.
When 314e51b9851b was added, it seemed the direction was to kill of the
VM_RESERVED, now a few years later VM_SPECIAL seems to be replacing
this. I think it would be better to preserve the original goal and
keep flags having a single meaning.
The purpose in 0103bd16fb90 as I surmise it, is that VM_IO | VM_PFNMAP
| VM_MIXEDMAP are the true things that want to be prevented from having
madvise(DO_DUMP) on them, based on frequent use of DONT_DUMP with those
memory pages. Was VM_DONTEXPAND an intentional inclusion there it did it
just get included with VM_SPECIAL?
Either way, I've tried to keep to the principles of the
is_vm_hugetlb_page function being the authoritative source of a HUGETLB
page.
> Perhaps Konstantin has an opinion as he did a bunch of the vm_flag
> reorg.
>
Thanks for the review.
next prev parent reply other threads:[~2018-10-03 5:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-30 5:46 [PATCH] mm: madvise(MADV_DODUMP) allow hugetlbfs pages Daniel Black
2018-10-01 22:11 ` Mike Kravetz
2018-10-03 5:47 ` Daniel Black [this message]
2018-10-04 21:47 ` Mike Kravetz
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=20181003074520.460bbf17@volution \
--to=daniel@linux.ibm.com \
--cc=khlebnikov@openvz.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.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 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).