linux-kernel - Re: [PATCH] mm: fix sleeping copy_huge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHbLzkqFpADQmrPq572M-y53ChJzFJ+uDOHUzzeRFUTv0acq9A@mail.gmail.com>
Date:   Fri, 22 Oct 2021 10:38:41 -0700
From:   Yang Shi <shy828301@...il.com>
To:     Matthew Wilcox <willy@...radead.org>,
        Hugh Dickins <hughd@...gle.com>
Cc:     Andrea Righi <andrea.righi@...onical.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Minchan Kim <minchan@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: fix sleeping copy_huge_page called from atomic context

On Fri, Oct 22, 2021 at 4:16 AM Matthew Wilcox <willy@...radead.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.

>