From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7222FC433E0 for ; Tue, 23 Feb 2021 22:32:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E086664E7A for ; Tue, 23 Feb 2021 22:32:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E086664E7A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3F43A6B0005; Tue, 23 Feb 2021 17:32:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CABC6B0006; Tue, 23 Feb 2021 17:32:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E0466B006E; Tue, 23 Feb 2021 17:32:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 17BC46B0005 for ; Tue, 23 Feb 2021 17:32:08 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DCD4E180ACF76 for ; Tue, 23 Feb 2021 22:32:07 +0000 (UTC) X-FDA: 77850981894.04.3F08B52 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP id 71655EF for ; Tue, 23 Feb 2021 22:32:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 569EBACE5; Tue, 23 Feb 2021 22:32:04 +0000 (UTC) Date: Tue, 23 Feb 2021 23:31:57 +0100 From: Oscar Salvador To: Muchun Song Cc: Mike Kravetz , Jonathan Corbet , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Michal Hocko , "Song Bao Hua (Barry Song)" , David Hildenbrand , HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Joao Martins , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Subject: Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page Message-ID: <20210223223157.GA2740@localhost.localdomain> References: <20210219104954.67390-1-songmuchun@bytedance.com> <20210219104954.67390-5-songmuchun@bytedance.com> <13a5363c-6af4-1e1f-9a18-972ca18278b5@oracle.com> <20210223092740.GA1998@linux> <20210223104957.GA3844@linux> <20210223154128.GA21082@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210223154128.GA21082@localhost.localdomain> X-Stat-Signature: 65o9muzdcu3t9w5wszwu791366bdq9ye X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 71655EF Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1614119521-185638 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 23, 2021 at 04:41:28PM +0100, Oscar Salvador wrote: > On Tue, Feb 23, 2021 at 11:50:05AM +0100, Oscar Salvador wrote: > > > CPU0: CPU1: > > > set_compound_page_dtor(HUGETLB_PAGE_DTOR); > > > memory_failure_hugetlb > > > get_hwpoison_page > > > __get_hwpoison_page > > > get_page_unless_zero > > > put_page_testzero() > > > > > > Maybe this can happen. But it is a very corner case. If we want to > > > deal with this. We can put_page_testzero() first and then > > > set_compound_page_dtor(HUGETLB_PAGE_DTOR). > > > > I have to check further, but it looks like this could actually happen. > > Handling this with VM_BUG_ON is wrong, because memory_failure/soft_offline are > > entitled to increase the refcount of the page. > > > > AFAICS, > > > > CPU0: CPU1: > > set_compound_page_dtor(HUGETLB_PAGE_DTOR); > > memory_failure_hugetlb > > get_hwpoison_page > > __get_hwpoison_page > > get_page_unless_zero > > put_page_testzero() > > identify_page_state > > me_huge_page > > > > I think we can reach me_huge_page with either refcount = 1 or refcount =2, > > depending whether put_page_testzero has been issued. > > > > For now, I would not re-enqueue the page if put_page_testzero == false. > > I have to see how this can be handled gracefully. > > I took a brief look. > It is not really your patch fault. Hugetlb <-> memory-failure synchronization is > a bit odd, it definitely needs improvment. > > The thing is, we can have different scenarios here. > E.g: by the time we return from put_page_testzero, we might have refcount == > 0 and PageHWPoison, or refcount == 1 PageHWPoison. > > The former will let a user get a page from the pool and get a sigbus > when it faults in the page, and the latter will be even more odd as we > will have a self-refcounted page in the free pool (and hwpoisoned). > > As I said, it is not this patchset fault. I just made me realize this > problem. > > I have to think some more about this. I have been thinking more about this. memory failure events can occur at any time, and we might not be in a position where we can handle gracefully the error, meaning that the page might end up in non desirable state. E.g: we could flag the page right before enqueing it. I still think that VM_BUG_ON should go, as the refcount can be perfectly increased by memory-failure/soft_offline handlers, so BUGing there does not make much sense. One think we could do is to check the state of the page we want to retrieve from the free hugepage pool. We should discard any HWpoisoned ones, and dissolve them. The thing is, memory-failure/soft_offline should allocate a new hugepage for the free pool, so keep the pool stable. Something like [1]. Anyway, this is orthogonal to this patch, and something I will work on soon. [1] https://lore.kernel.org/linux-mm/20210222135137.25717-2-osalvador@suse.de/T/#u -- Oscar Salvador SUSE L3