Re: [PATCH] mm: fix sleeping copy_huge_page called from atomic context

[Yang Shi <shy828301@gmail.com>]

On Fri, Oct 22, 2021 at 4:16 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Oct 22, 2021 at 09:46:19AM +0200, Andrea Righi wrote:
> > copy_huge_page() can be called with mapping->private_lock held from
> > __buffer_migrate_page() -> migrate_page_copy(), so it is not safe to
> > do a cond_resched() in this context.
> >
> > Introduce migrate_page_copy_nowait() and copy_huge_page_nowait()
> > variants that can be used from an atomic context.
>
> I think this is a consequence of THPs being created when they should not
> be.  This is the wrong way to fix this problem; and I suspect it may
> already be fixed at least in -mm.  We should have taken this path:
>
>         if (!page_has_buffers(page))
>                 return migrate_page(mapping, newpage, page, mode);
>
> but since we didn't, we can infer that there's a THP which has buffers
> (this should never occur).  It's the same root cause as the invalidatepage
> problem, just with a very different signature.

Yeah, exactly. And I replied to that syzbot report a few days ago
(https://lore.kernel.org/linux-mm/CAHbLzkoFaowaG8AU6tg_WMPdjcAdyE+Wafs7TJz1Z23TRg_d8A@mail.gmail.com/)
with the same conclusion.

I'm not sure why Hugh didn't submit his patch, maybe he was waiting
for the test result from the bug reporter of that invalidatepage
issue? It should be fine, the fix is quite straightforward IMHO.

>