linux-kernel - Re: [syzbot] WARNING in follow_hugetlb

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: <6daa971b-03f1-0f69-4c85-ae4796d339e0@oracle.com>
Date:   Sat, 21 May 2022 16:50:50 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Minchan Kim <minchan@...nel.org>,
        David Hildenbrand <david@...hat.com>
Cc:     John Hubbard <jhubbard@...dia.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        syzbot <syzbot+acf65ca584991f3cc447@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        llvm@...ts.linux.dev, nathan@...nel.org, ndesaulniers@...gle.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com,
        Matthew Wilcox <willy@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [syzbot] WARNING in follow_hugetlb_page

On 5/21/22 11:25, Minchan Kim wrote:
> On Sat, May 21, 2022 at 06:46:27PM +0200, David Hildenbrand wrote:
> 
> < snip >
> 
>>>> The general rules are:
>>>>
>>>> ZONE_MOVABLE: nobody is allowed to place unmovable allocations there; it
>>>> could prevent memory offlining/unplug.
>>>>
>>>> CMA: nobody *but the designated owner* is allowed to place unmovable
>>>> memory there; it could prevent the actual owner to allocate contiguous
>>>> memory.
>>>
>>> I am confused what's the meaning of designated owner and actuall owner
>>> in your context.
>>
>> designated==actual here. I just wanted to distinguish from someone
>> current temporary owner of the page ("allocated it via a movable
>> allocation") but the actual designated owner (e.g., hugetlb CMA)
>>
>> The page/memory owner terminology is just confusing. Let's rephrase to:
>> only the CMA area owner is allowed to place unmovable allocations there.
> 
> Yeah, the CMA area owner is much better.
> 
>>
>>>
>>> What I thought about the issue based on you explanation:
>>>
>>> HugeTLB allocates its page by two types of allocation
>>>
>>> 1. alloc_pages(GFP_MOVABLE)
>>>  
>>> It could allocate the hugetlb page from CMA area but longterm pin
>>> should migrate them out of cma before the pinning so allowing
>>> the pinning on the page is no problem and current code works like
>>> that.
>>>
>>>     check_and_migrate_movable_pages
>>>
>>
>> Yes.
>>
>>> 2. cma_alloc
>>>
>>> The cma_alloc is used only for *gigantic page* and the hugetlbfs
>>> is the very owner of the page. IOW, if the hugetlbfs was succeeded
>>> to allocate the gigantic page by cma_alloc, there is no other
>>> owner to be able to claim the page any longer so it's fine to
>>> allow longterm pinning againt the gingantic page but current.
>>> However, current code doesn't work like that due to
>>> is_pinnable_page. IOW, hugetlbfs need a way to distinguish 
>>> whether the page owner is hugetlbfs or not.
>>>
>>> Are we on same page?
>>
>> Yes, exactly. What I wanted to express is: for huge pages we have to
>> make a smarter decision because there are cases where we want to
>> migrate, and cases where we don't want to migrate.
> 
> Sure, maybe hugetlbfs could squeeze a bit in one of subpage of the
> CMA compound page. "I am CMA allocated but allow to pinned for longterm"
> 

Thanks for all the ideas here.  Yes, we already have a whole word for hugetlb
specific page flags (see hugetlb_page_flags in linux/hugetlb.h).  I'm pretty
sure I even proposed a 'allocated from CMA' flag, but there was another way to
get that information.  We can add such a flag to for the purpose if making a
decision about long term pinning.

BTW - It is possible that a gigantic page allocated in CMA could be demoted
(split) into smaller hugetlb pages.  I 'think' we would also want to allow
long term pinning in this case.
-- 
Mike Kravetz