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 B99F7C433F5 for ; Tue, 12 Apr 2022 09:30:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4EF2F6B0078; Tue, 12 Apr 2022 05:30:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49EE56B007B; Tue, 12 Apr 2022 05:30:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38DF56B007D; Tue, 12 Apr 2022 05:30:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 2AC2D6B0078 for ; Tue, 12 Apr 2022 05:30:49 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0601A62212 for ; Tue, 12 Apr 2022 09:30:49 +0000 (UTC) X-FDA: 79347707418.13.DA3BBFD Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf03.hostedemail.com (Postfix) with ESMTP id 403822003B for ; Tue, 12 Apr 2022 09:30:48 +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-out1.suse.de (Postfix) with ESMTPS id 3DFCB21607; Tue, 12 Apr 2022 09:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1649755847; 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=Wr5BQ6bZpbMeg7ofiqLD8o/rdHTyB9quz+3pcWOJOkY=; b=v/Lvza07II56g/dJuEQnp1dcyTzwfc9dSfvcZKMQZuJK1dTrmdG7wHq5PuGk7jhR1Sl1tS GJK0cKRbkI6j/3EAXCqN1pFm/RSk3ecAH96CiA4K3wsWnyOhgHaJCZ9/ceA3catGIWBwjb 23tX766j2ddx8GxnnEwzd39nsvVodA8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1649755847; 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=Wr5BQ6bZpbMeg7ofiqLD8o/rdHTyB9quz+3pcWOJOkY=; b=2/sN5yb24YFm/l3MjMercuXJKUvCFNyZ5CMivJRq2oszvegn7haz+jURJPEI7No/pwpn12 vi8bCzw0WDxTgyCw== 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 ED28113A99; Tue, 12 Apr 2022 09:30:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NrtXN8ZGVWJOLgAAMHmgww (envelope-from ); Tue, 12 Apr 2022 09:30:46 +0000 Date: Tue, 12 Apr 2022 11:30:45 +0200 From: Oscar Salvador To: Miaohe Lin Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Xu Yu Subject: Re: [PATCH] mm/memory-failure.c: bail out early if huge zero page Message-ID: References: <49273e6688d7571756603dac996692a15f245d58.1649603963.git.xuyu@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="v/Lvza07"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="2/sN5yb2"; spf=pass (imf03.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 403822003B X-Stat-Signature: abaypfwgsju469t1exgua1pdysijcpof X-HE-Tag: 1649755848-77635 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Apr 12, 2022 at 05:25:52PM +0800, Miaohe Lin wrote: > On 2022/4/12 16:31, Oscar Salvador wrote: > > On Sun, Apr 10, 2022 at 11:22:34PM +0800, Xu Yu wrote: > >> Kernel panic when injecting memory_failure for the global huge_zero_page, > >> when CONFIG_DEBUG_VM is enabled, as follows. > > ... > >> In fact, huge_zero_page is unhandlable currently in either soft offline > >> or memory failure injection. With CONFIG_DEBUG_VM disabled, > >> huge_zero_page is bailed out when checking HWPoisonHandlable() in > >> get_any_page(), or checking page mapping in split_huge_page_to_list(). > >> > >> This makes huge_zero_page bail out early in madvise_inject_error(), and > >> panic above won't happen again. > > > > I would not special case this in madvise_inject_error() but rather > > handle it in memory-failure code. > > We do already have HWPoisonHandlable(), which tells us whether the page > > is of a type we can really do something about, so why not add another > > check in HWPoisonHandlable() for huge_zero_page(), and have that checked > > in memory_failure(). > > IIUC, this does not work. Because HWPoisonHandlable is only called in !MF_COUNT_INCREASED case. > But MF_COUNT_INCREASED is always set when called from madvise_inject_error, so HWPoisonHandlable > is not even called in this scene. Or am I miss something? But nothing stops you from calling it in memory_failure(), right? if (MF_COUNT_INCREASED not set) { .... ... } else if(!HWPoisonHandable(p)) { action_result(pfn, MF_MSG_UNKNOWN, MF_IGNORED); res = -EBUSY; goto unlock_mutex; } > BTW: IIRC, LRU isn't set on huge_zero_page. So the origin HWPoisonHandlable can already filter out this page. I would rather have it as a explicit check than buried in that kind of assumption. But after all, Naoya's suggestion might just be better and more focused. -- Oscar Salvador SUSE Labs