Received-SPF: pass (google.com: domain of linux-kernel+bounces-178414-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240513074712.7608-1-ioworker0@gmail.com> <20240513074712.7608-4-ioworker0@gmail.com>
 <f22c9fc8-2356-46c6-ac8e-dc97328d7fcc@linux.alibaba.com>
In-Reply-To: <f22c9fc8-2356-46c6-ac8e-dc97328d7fcc@linux.alibaba.com>
From: Lance Yang <ioworker0@gmail.com>
Date: Tue, 14 May 2024 15:46:44 +0800
Message-ID: <CAK1f24n=fT6MDCkN_2ycCmxV3fTkdqRdg7iiq_aXX+AvQ7hXmQ@mail.gmail.com>
Subject: Re: [PATCH RESEND v5 3/4] mm/mlock: check for THP missing the mlock
 in try_to_unmap_one()
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: akpm@linux-foundation.org, willy@infradead.org, sj@kernel.org, 
	maskray@google.com, ziy@nvidia.com, ryan.roberts@arm.com, david@redhat.com, 
	21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com, 
	shy828301@gmail.com, xiehuan09@gmail.com, libang.li@antgroup.com, 
	wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, 
	minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2024 at 2:41=E2=80=AFPM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
>
>
>
> On 2024/5/13 15:47, Lance Yang wrote:
> > The TTU_SPLIT_HUGE_PMD will no longer perform immediately, so we might
> > encounter a PMD-mapped THP missing the mlock in the VM_LOCKED range
> > during the pagewalk. It's likely necessary to mlock this THP to prevent
> > it from being picked up during page reclaim.
> >
> > Suggested-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> > Signed-off-by: Lance Yang <ioworker0@gmail.com>
>
> IMO, this patch should be merged into patch 2, otherwise patch 2 is
> buggy. Quote the description in the 'submission patches.rst' document:
>
> "When dividing your change into a series of patches, take special care
> to ensure that the kernel builds and runs properly after each patch in
> the series.  Developers using ``git bisect`` to track down a problem can
> end up splitting your patch series at any point; they will not thank you
> if you introduce bugs in the middle."

Thanks for bringing this up!

I completely agree that this patch should be merged into patch2.

Thanks,
Lance

>
> > ---
> >   mm/rmap.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index 4c4d14325f2e..08a93347f283 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -1671,7 +1671,8 @@ static bool try_to_unmap_one(struct folio *folio,=
 struct vm_area_struct *vma,
> >               if (!(flags & TTU_IGNORE_MLOCK) &&
> >                   (vma->vm_flags & VM_LOCKED)) {
> >                       /* Restore the mlock which got missed */
> > -                     if (!folio_test_large(folio))
> > +                     if (!folio_test_large(folio) ||
> > +                         (!pvmw.pte && (flags & TTU_SPLIT_HUGE_PMD)))
> >                               mlock_vma_folio(folio, vma);
> >                       goto walk_done_err;
> >               }