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: <21a0b20c-5b62-490e-ad8e-26b4b78ac095@suse.cz>
Date:   Wed, 19 Jun 2019 10:22:57 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Michal Hocko <mhocko@...nel.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>
Cc:     akpm@...ux-foundation.org, mgorman@...hsingularity.net,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped
 correctly in mbind

On 6/19/19 7:21 AM, Michal Hocko wrote:
> On Tue 18-06-19 14:13:16, Yang Shi wrote:
> [...]
>>
>> I used to have !__PageMovable(page), but it was removed since the
>> aforementioned reason. I could add it back.
>>
>> For the temporary off LRU page, I did a quick search, it looks the most
>> paths have to acquire mmap_sem, so it can't race with us here. Page
>> reclaim/compaction looks like the only race. But, since the mapping should
>> be preserved even though the page is off LRU temporarily unless the page is
>> reclaimed, so we should be able to exclude temporary off LRU pages by
>> calling page_mapping() and page_anon_vma().
>>
>> So, the fix may look like:
>>
>> if (!PageLRU(head) && !__PageMovable(page)) {
>>     if (!(page_mapping(page) || page_anon_vma(page)))
>>         return -EIO;
> 
> This is getting even more muddy TBH. Is there any reason that we have to
> handle this problem during the isolation phase rather the migration?

I think it was already said that if pages can't be isolated, then
migration phase won't process them, so they're just ignored.
However I think the patch is wrong to abort immediately when
encountering such page that cannot be isolated (AFAICS). IMHO it should
still try to migrate everything it can, and only then return -EIO.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ