linux-kernel - Re: [PATCH -v2 0/9] migrate

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: <87ilhcrzkr.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date:   Thu, 12 Jan 2023 15:17:56 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Zi Yan <ziy@...dia.com>,
        Yang Shi <shy828301@...il.com>,
        Baolin Wang <baolin.wang@...ux.alibaba.com>,
        Oscar Salvador <osalvador@...e.de>,
        Matthew Wilcox <willy@...radead.org>,
        Bharata B Rao <bharata@....com>,
        Alistair Popple <apopple@...dia.com>,
        haoxin <xhao@...ux.alibaba.com>
Subject: Re: [PATCH -v2 0/9] migrate_pages(): batch TLB flushing

Mike Kravetz <mike.kravetz@...cle.com> writes:

> On 01/12/23 08:09, Huang, Ying wrote:
>> Hi, Mike,
>> 
>> Mike Kravetz <mike.kravetz@...cle.com> writes:
>> 
>> > On 01/10/23 17:53, Mike Kravetz wrote:
>> >> Just saw the following easily reproducible issue on next-20230110.  Have not
>> >> verified it is related to/caused by this series, but it looks suspicious.
>> >
>> > Verified this is caused by the series,
>> >
>> > 734cbddcfe72 migrate_pages: organize stats with struct migrate_pages_stats
>> > to
>> > 323b933ba062 migrate_pages: batch flushing TLB
>> >
>> > in linux-next.
>> 
>> Thanks for reporting.
>> 
>> I tried this yesterday (next-20230111), but failed to reproduce it.  Can
>> you share your kernel config?  Is there any other setup needed?
>
> Config file is attached.

Thanks!

> Are you writing a REALLY big value to nr_hugepages?  By REALLY big I
> mean a value that is impossible to fulfill.  This will result in
> successful hugetlb allocations until __alloc_pages starts to fail.  At
> this point we will be stressing compaction/migration trying to find more
> contiguous pages.
>
> Not sure if it matters, but I am running on a 2 node VM.  The 2 nodes
> may be important as the hugetlb allocation code will try a little harder
> alternating between nodes that may perhaps stress compaction/migration
> more.

Tried again on a 2-node machine.  Still cannot reproduce it.

>> BTW: can you bisect to one specific commit which causes the bug in the
>> series?
>
> I should have some time to isolate in the next day or so.

Thanks!

Best Regards,
Huang, Ying