linux-kernel - Re: Memory hotplug softlock issue

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: <20181119170105.GT22247@dhcp22.suse.cz>
Date:   Mon, 19 Nov 2018 18:01:05 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Baoquan He <bhe@...hat.com>, David Hildenbrand <david@...hat.com>,
        linux-mm@...ck.org, pifang@...hat.com,
        linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
        aarcange@...hat.com, Mel Gorman <mgorman@...e.de>,
        Hugh Dickins <hughd@...gle.com>
Subject: Re: Memory hotplug softlock issue

On Mon 19-11-18 17:48:35, Vlastimil Babka wrote:
> On 11/19/18 5:46 PM, Vlastimil Babka wrote:
> > On 11/19/18 5:46 PM, Michal Hocko wrote:
> >> On Mon 19-11-18 17:36:21, Vlastimil Babka wrote:
> >>>
> >>> So what protects us from locking a page whose refcount dropped to zero?
> >>> and is being freed? The checks in freeing path won't be happy about a
> >>> stray lock.
> >>
> >> Nothing really prevents that. But does it matter. The worst that might
> >> happen is that we lock a freed or reused page. Who would complain?
> > 
> > free_pages_check() for example
> > 
> > PAGE_FLAGS_CHECK_AT_FREE includes PG_locked

Right you are.

> And besides... what about the last page being offlined and then the
> whole struct page's part of vmemmap destroyed as the node goes away?

Yeah, that is quite unlikely though because the there is quite a large
time window between the two events. I am not entirely sure we are safe
right now TBH. Any access to the struct page after the put_page is
unsafe theoretically.

Then we have to come up with something more clever I am afraid.

-- 
Michal Hocko
SUSE Labs