linux-kernel - Re: [PATCH] mm/page_alloc: Avoid page allocator recursion with pagesets.lock held

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] [day] [month] [year] [list]

Message-ID: <YOcwWBJw4uZH8X3f@casper.infradead.org>
Date:   Thu, 8 Jul 2021 18:05:28 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Rafael Aquini <aquini@...hat.com>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        Desmond Cheong Zhi Xi <desmondcheongzx@...il.com>,
        linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
        Zqiang <qiang.zhang@...driver.com>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        syzbot+127fd7828d6eeb611703@...kaller.appspotmail.com
Subject: Re: [PATCH] mm/page_alloc: Avoid page allocator recursion with
 pagesets.lock held

On Thu, Jul 08, 2021 at 09:10:18AM -0400, Rafael Aquini wrote:
> > There are a number of ways it could be fixed. The page owner code could
> > be audited to strip GFP flags that allow sleeping but it'll impair the
> > functionality of PAGE_OWNER if allocations fail. The bulk allocator
> > could add a special case to release/reacquire the lock for prep_new_page
> > and lookup PCP after the lock is reacquired at the cost of performance.
> > The patches requiring prep could be tracked using the least significant

If we're nitpicking changelogs, then s/patches/pages/

> > bit and looping through the array although it is more complicated for
> > the list interface. The options are relatively complex and the second
> > one still incurs a performance penalty when PAGE_OWNER is active so this
> > patch takes the simple approach -- disable bulk allocation of PAGE_OWNER is
>                                                             ^^^^
> Minor nit: s/of/if
> 
> > active. The caller will be forced to allocate one page at a time incurring
> > a performance penalty but PAGE_OWNER is already a performance penalty.

The thought occurs that all pages allocated this way will have the same
stack.  Someone suitably motivated could:

 - Refcount the stacks managed by page_owner
 - Generate the stack in the caller of alloc_bulk
 - Pass the stack in to a new __set_page_owner()

That's a lot of work; I'm not going to do it, and I don't think Mel
should either.  But if someone's looking for something to do ...