Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 11 Jun 2021 13:56:36 -0700 (PDT)
From:   Hugh Dickins <hughd@google.com>
To:     Alistair Popple <apopple@nvidia.com>
cc:     Hugh Dickins <hughd@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Yang Shi <shy828301@gmail.com>,
        Wang Yugui <wangyugui@e16-tech.com>,
        Matthew Wilcox <willy@infradead.org>,
        Naoya Horiguchi <naoya.horiguchi@nec.com>,
        Ralph Campbell <rcampbell@nvidia.com>, Zi Yan <ziy@nvidia.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        Minchan Kim <minchan@kernel.org>, Jue Wang <juew@google.com>,
        Peter Xu <peterx@redhat.com>, Jan Kara <jack@suse.cz>,
        Shakeel Butt <shakeelb@google.com>,
        Oscar Salvador <osalvador@suse.de>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/10] mm/thp: fix THP splitting unmap BUGs and
 related
In-Reply-To: <1697169.ADtCEf3Xva@nvdebian>
Message-ID: <494c929d-5253-58b0-6329-dec8395199cc@google.com>
References: <af88612-1473-2eaa-903-8d1a448b26@google.com> <2014832.e7zRqyNrDn@nvdebian> <b27e866-a06c-d32-20aa-3b16f58549@google.com> <1697169.ADtCEf3Xva@nvdebian>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 11 Jun 2021, Alistair Popple wrote:
> On Friday, 11 June 2021 10:15:51 AM AEST Hugh Dickins wrote:
> > 
> > Sorry to give you the bother, Alistair: it's worked out as a bad moment
> > to rewrite swapops.h and rmap.c, I'm afraid.
> 
> Indeed, but I don't think it's too bad. I've just tried rebasing it on this
> series and it didn't run into too many problems. Obviously I ran into the same
> issue Andrew did but I was able to fix that up. It also means try_to_migrate()
> now returns 'void' instead of 'bool'.

Yes, void try_to_migrate().

> 
> Which brings me to the only real question I had during the rebase - does
> migration also need to accept the TTU_SYNC flag? I think it does because if I
> understand correctly we can still hit the same race with zap_pte_range() when
> trying to establish migration entries which previously also returned the status
> of page_mapped().

Yes, try_to_migrate() needs to accept TTU_SYNC too.

> 
> > And the only help I've had time to give you was pointing Peter at your
> > series - many thanks to Peter, and to Shakeel.
> 
> Yes, thanks for the help there. I think the main questions I had for you were
> around checking vma flags under the ptl in try_to_munlock_one but Shakeel was
> able to clear that up for me. Thanks!
> 
> > Several times I've been on the point of asking you to keep the familiar
> > migration_entry_to_page(), along with your new pfn_swap_entry_to_page();
> > but each time I've looked, seen that it's hard to retain it sensibly at
> > the same time as overdue cleanup of the device_private_entry_to_page()s.
> 
> Yeah, it would make things a bit funny to retain it IMHO. At least any fixups
> should just be simple substitutions.
> 
> > So I guess I'm resigned to losing it; but there are at least three
> > bugs currently under discussion or fixes in flight, which border on
> > migration_entry_to_page() - Jann Horn's smaps syzbot bug, Xu Yu's
> > __migration_entry_wait() fix, my __split_huge_pmd_locked() fix
> > (and page_vma_mapped_walk() cleanup).
> > 
> > And regarding huge_memory.c's unmap_page(): I did not recognize the
> > "helps handle cases when i_size" comment you added there.  What I
> > ended up with (and thought was in mmotm-adjust.tar but seems not):
> > 
> >         /*
> >          * Anon pages need migration entries to preserve them, but file
> >          * pages can simply be left unmapped, then faulted back on demand.
> >          * If that is ever changed (perhaps for mlock), update remap_page().
> >          */
> 
> My comment was based somewhat on the commit message for the original change but
> yours is much clearer so will incorporate it into my rebase, thanks.

Oh, you did better than I, I didn't think to look there on this occasion.
But even so, the i_size business is just one detail, and the new comment
better I think (I also disliked comment on an else without { } around it).

> 
> As to sending my rebased series I suppose it would be best to wait until
> linux-mm has been updated with whatever other fixes are needed before resending
> it based on top of that. So far rebasing on this series didn't require too many
> drastic changes to my v10 series. The most significant was to incorporate your
> changes to unmap_page(). The remaining were just adding the TTU_SYNC case to
> try_to_migrate{_one} and a single s/migration_entry_to_page/pfn_swap_entry_to_page/
> in huge_memory.c

Yes, I think that's it.  But check your try_to_migrate_one(), it may
want the same range.end vma_address_end() mod I made in try_to_unmap_one().

And does try_to_migrate_one() still have a comment referring to
try_to_unmap() when it should say try_to_migrate() there?

I've now located the diffs I missed from sending akpm before,
and diffed the diffs, and those are the points I see there;
but sending them now will just be a waste of everyones time.
No substitute for me checking your end result when it comes,
though I fear to do so since there's much more in your series
than I can wrap my head around without a lot more education.

Hugh