[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120827123917.3313dfda@thinkpad>
Date: Mon, 27 Aug 2012 12:39:17 +0200
From: Gerald Schaefer <gerald.schaefer@...ibm.com>
To: Hillf Danton <dhillf@...il.com>
Cc: akpm@...ux-foundation.org, aarcange@...hat.com, linux-mm@...ck.org,
ak@...ux.intel.com, hughd@...gle.com, linux-kernel@...r.kernel.org,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com
Subject: Re: [RFC patch 3/7] thp: make MADV_HUGEPAGE check for mm->def_flags
On Sat, 25 Aug 2012 20:47:37 +0800
Hillf Danton <dhillf@...il.com> wrote:
> On Fri, Aug 24, 2012 at 1:17 AM, Gerald Schaefer
> <gerald.schaefer@...ibm.com> wrote:
> > This adds a check to hugepage_madvise(), to refuse MADV_HUGEPAGE
> > if VM_NOHUGEPAGE is set in mm->def_flags. On System z, the VM_NOHUGEPAGE
> > flag will be set in mm->def_flags for kvm processes, to prevent any
> > future thp mappings. In order to also prevent MADV_HUGEPAGE on such an
> > mm, hugepage_madvise() should check mm->def_flags.
> >
> > Signed-off-by: Gerald Schaefer <gerald.schaefer@...ibm.com>
> > ---
> > mm/huge_memory.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -1464,6 +1464,8 @@ out:
> > int hugepage_madvise(struct vm_area_struct *vma,
> > unsigned long *vm_flags, int advice)
> > {
> > + struct mm_struct *mm = vma->vm_mm;
> > +
> > switch (advice) {
> > case MADV_HUGEPAGE:
> > /*
> > @@ -1471,6 +1473,8 @@ int hugepage_madvise(struct vm_area_stru
> > */
> > if (*vm_flags & (VM_HUGEPAGE | VM_NO_THP))
> > return -EINVAL;
> > + if (mm->def_flags & VM_NOHUGEPAGE)
> > + return -EINVAL;
>
> Looks ifdefinery needed for s390 to wrap the added check, and
> a brief comment?
Hmm, architecture #ifdefs in common code are ugly. I'd rather keep
the check even if it is redundant right now for other architectures
than s390. It is not a performance critical path, and there may be
other users of that in the future.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists