[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170912211250.GB16850@gmail.com>
Date: Tue, 12 Sep 2017 23:12:50 +0200
From: Alexandru Moise <00moses.alexander00@...il.com>
To: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
khandual@...ux.vnet.ibm.com, mhocko@...e.com, aarcange@...hat.com,
minchan@...nel.org, hillf.zj@...baba-inc.com, shli@...com,
rppt@...ux.vnet.ibm.com, kirill.shutemov@...ux.intel.com,
mgorman@...hsingularity.net, rientjes@...gle.com, riel@...hat.com,
linux-mm@...ck.org
Subject: Re: [PATCH] mm, hugetlb, soft_offline: save compound page order
before page migration
On Tue, Sep 12, 2017 at 01:58:35PM -0700, Andrew Morton wrote:
> On Tue, 12 Sep 2017 13:54:48 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > On Tue, 12 Sep 2017 22:43:06 +0200 Alexandru Moise <00moses.alexander00@...il.com> wrote:
> >
> > > This fixes a bug in madvise() where if you'd try to soft offline a
> > > hugepage via madvise(), while walking the address range you'd end up,
> > > using the wrong page offset due to attempting to get the compound
> > > order of a former but presently not compound page, due to dissolving
> > > the huge page (since c3114a8).
> >
> > What are the user visible effects of the bug? The wrong page is
> > offlined? No offlining occurs?
>
> This also affects MADV_HWPOISON?
No, MADV_HWPOISON is ok because it doesn't dissolve the hugepage, so the page
remains a compound page the 2nd loop around.
../Alex
Powered by blists - more mailing lists