linux-kernel - Re: [PATCH v5 5/5] mm,page_alloc: Drop unnecessary checks from pfn_range_valid

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: <YFMVbUVwm+x2H88z@dhcp22.suse.cz>
Date:   Thu, 18 Mar 2021 09:55:09 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Muchun Song <songmuchun@...edance.com>,
        Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/5] mm,page_alloc: Drop unnecessary checks from
 pfn_range_valid_contig

On Thu 18-03-21 09:44:19, Oscar Salvador wrote:
> On Wed, Mar 17, 2021 at 04:03:06PM +0100, Michal Hocko wrote:
> > > alloc_contig_pages() vs. alloc_contig_range(). The patches are active for
> > > virtio-mem and CMA AFAIKS.
> > 
> > yeah, I meant to say "are not actually fully active".
> 
> We could place this patch earlier in this patchset.
> The only thing is that we would lose the prevalidation (at leat for
> HugeTLB page) which is done upfront to find later on that we do not
> support hugetlb handling in isolate_migratepates_block.
> So the bad thing about placing it earlier, is that wrt. hugetlb pages,
> alloc_gigantic_page will take longer to fail (when we already know that
> will fail).

>From a bisactability POV this shouldn't be a major concern. If you are
too worried then just drop the HugePage check in the patch allowing to
migrate free hugetlb pages. It is unlikely that somebody will run with
that patch alone but if the said patch introduces some sort of bug it
would be good to bisect down to it.

> Then we have the page_count check, which is also racy and
> isolate_migratepages_block will take care of it.
> So I guess can think of this patch as a preparatory patch that removes racy
> checks that will be re-checked later on in the end function which does
> the actual handling.

TBH, I do not care much about the page count check. It is comletely
orthogonal to the migration changes in this series. So both preparatory
and follow up are ok.

-- 
Michal Hocko
SUSE Labs