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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1365C433EF for ; Tue, 24 May 2022 10:48:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 907C38D0005; Tue, 24 May 2022 06:48:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B6548D0002; Tue, 24 May 2022 06:48:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A7A08D0005; Tue, 24 May 2022 06:48:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6C0768D0002 for ; Tue, 24 May 2022 06:48:26 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 382B76076A for ; Tue, 24 May 2022 10:48:26 +0000 (UTC) X-FDA: 79500312612.02.A677FE0 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf11.hostedemail.com (Postfix) with ESMTP id 66F8740038 for ; Tue, 24 May 2022 10:48:18 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 564041F8B8; Tue, 24 May 2022 10:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1653389304; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+x0BsMH20pzr4sqqMhiWBt6tlMGyncVeqDaTZYPzxIk=; b=bU18FkfFzSnrOU95lcIrBUqO7OWlmV7k8b5GFBU2OYxarFiqvdNRYHD+pAruybbpC08ueJ LuKQxH/LR7dSwIzvN1oBkInWTyZXS1zqGHgvW0v4TI/sIViayIlYHbhEUJn7p7HRQnEqbR v1BMTyPT2E2AQkJ+2aQvgSdJbW90YEM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1653389304; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+x0BsMH20pzr4sqqMhiWBt6tlMGyncVeqDaTZYPzxIk=; b=fYf+vCY2CjjX5bycSymnE1X4+wp0I5OsWUeA7UOmpMjfPzQR2VBOJFMQG8AyxK3JlKPIU8 Z9bOZTKwTK355uCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B14C213AE3; Tue, 24 May 2022 10:48:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 0WVKKPe3jGLKKgAAMHmgww (envelope-from ); Tue, 24 May 2022 10:48:23 +0000 Date: Tue, 24 May 2022 12:48:22 +0200 From: Oscar Salvador To: Jiaqi Yan Cc: shy828301@gmail.com, tongtiangen@huawei.com, tony.luck@intel.com, naoya.horiguchi@nec.com, kirill.shutemov@linux.intel.com, linmiaohe@huawei.com, juew@google.com, linux-mm@kvack.org Subject: Re: [PATCH v3 1/2] mm: khugepaged: recover from poisoned anonymous memory Message-ID: References: <20220524025352.1381911-1-jiaqiyan@google.com> <20220524025352.1381911-2-jiaqiyan@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220524025352.1381911-2-jiaqiyan@google.com> X-Rspamd-Queue-Id: 66F8740038 X-Stat-Signature: gn1mnba33ibymi1xej18nij5oxs79bys Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=bU18FkfF; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=fYf+vCY2; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf11.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1653389298-416899 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 Mon, May 23, 2022 at 07:53:51PM -0700, Jiaqi Yan wrote: > Make __collapse_huge_page_copy return whether > collapsing/copying anonymous pages succeeded, > and make collapse_huge_page handle the return status. > > Break existing PTE scan loop into two for-loops. > The first loop copies source pages into target huge page, > and can fail gracefully when running into memory errors in > source pages. Roll back the page table and page states > when copying failed: > 1) re-establish the PTEs-to-PMD connection. > 2) release pages back to their LRU list. If you spell out what the first loop does, just tell what the second loop does as wel, it just gets easier. > +static bool __collapse_huge_page_copy(pte_t *pte, > + struct page *page, > + pmd_t *pmd, > + pmd_t rollback, > + struct vm_area_struct *vma, > + unsigned long address, > + spinlock_t *pte_ptl, > + struct list_head *compound_pagelist) > { > struct page *src_page, *tmp; > pte_t *_pte; > - for (_pte = pte; _pte < pte + HPAGE_PMD_NR; > - _pte++, page++, address += PAGE_SIZE) { > - pte_t pteval = *_pte; > + pte_t pteval; > + unsigned long _address; > + spinlock_t *pmd_ptl; > + bool copy_succeeded = true; > > - if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) { > + /* > + * Copying pages' contents is subject to memory poison at any iteration. > + */ > + for (_pte = pte, _address = address; > + _pte < pte + HPAGE_PMD_NR; > + _pte++, page++, _address += PAGE_SIZE) { > + pteval = *_pte; > + > + if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) > clear_user_highpage(page, address); > - add_mm_counter(vma->vm_mm, MM_ANONPAGES, 1); > - if (is_zero_pfn(pte_pfn(pteval))) { > - /* > - * ptl mostly unnecessary. > - */ > - spin_lock(ptl); > - ptep_clear(vma->vm_mm, address, _pte); > - spin_unlock(ptl); > + else { > + src_page = pte_page(pteval); > + if (copy_highpage_mc(page, src_page)) { > + copy_succeeded = false; > + trace_mm_collapse_huge_page_copy(pte_page(*pte), > + src_page, SCAN_COPY_MC); You seem to assume that if there is an error, it will always happen on the page we are copying from. What if the page we are copying to is the fauly one? Can that happen? Can that be detected by copy_mc_to_kernel? And if so, can that be differentiated? -- Oscar Salvador SUSE Labs