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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable 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 CE8C4C636C9 for ; Sat, 17 Jul 2021 18:20:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 51E0561154 for ; Sat, 17 Jul 2021 18:20:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51E0561154 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gentoo.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AB12E8D00F4; Sat, 17 Jul 2021 14:20:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A61678D00EC; Sat, 17 Jul 2021 14:20:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 929188D00F4; Sat, 17 Jul 2021 14:20:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id 70C198D00EC for ; Sat, 17 Jul 2021 14:20:38 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0A87A8249980 for ; Sat, 17 Jul 2021 18:20:37 +0000 (UTC) X-FDA: 78372895314.23.55C72E6 Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by imf30.hostedemail.com (Postfix) with ESMTP id 070EBE00198F for ; Sat, 17 Jul 2021 18:18:49 +0000 (UTC) Date: Sat, 17 Jul 2021 19:18:42 +0100 From: Sergei Trofimovich To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kees Cook , Alexander Potapenko , Thomas Gleixner , Vlastimil Babka , bowsingbetee@pm.me Subject: Re: [PATCH] mm: page_alloc: fix page_poison=1 / INIT_ON_ALLOC_DEFAULT_ON interaction Message-ID: <20210717191842.3ad53af8@zn3> In-Reply-To: <20210713190051.5d841c9269cf7cddf1731e5a@linux-foundation.org> References: <20210712005732.4f9bfa78@zn3> <20210712215816.1512739-1-slyfox@gentoo.org> <20210713190051.5d841c9269cf7cddf1731e5a@linux-foundation.org> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 070EBE00198F X-Stat-Signature: 4kphczu93ducnsnyu9x3aqu6mxhbk86p Authentication-Results: imf30.hostedemail.com; dkim=none; spf=pass (imf30.hostedemail.com: domain of slyfox@gentoo.org designates 140.211.166.183 as permitted sender) smtp.mailfrom=slyfox@gentoo.org; dmarc=pass (policy=none) header.from=gentoo.org X-HE-Tag: 1626545929-150547 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, 13 Jul 2021 19:00:51 -0700 Andrew Morton wrote: > On Mon, 12 Jul 2021 22:58:16 +0100 Sergei Trofimovich wrote: > > > To reproduce the failure we need the following system: > > - kernel command: page_poison=1 init_on_free=0 init_on_alloc=0 > > - kernel config: > > * CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y > > * CONFIG_INIT_ON_FREE_DEFAULT_ON=y > > * CONFIG_PAGE_POISONING=y > > > > 0000000085629bdd: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 0000000022861832: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00000000c597f5b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > CPU: 11 PID: 15195 Comm: bash Kdump: loaded Tainted: G U O 5.13.1-gentoo-x86_64 #1 > > Hardware name: System manufacturer System Product Name/PRIME Z370-A, BIOS 2801 01/13/2021 > > Call Trace: > > dump_stack+0x64/0x7c > > __kernel_unpoison_pages.cold+0x48/0x84 > > post_alloc_hook+0x60/0xa0 > > get_page_from_freelist+0xdb8/0x1000 > > __alloc_pages+0x163/0x2b0 > > __get_free_pages+0xc/0x30 > > pgd_alloc+0x2e/0x1a0 > > ? dup_mm+0x37/0x4f0 > > mm_init+0x185/0x270 > > dup_mm+0x6b/0x4f0 > > ? __lock_task_sighand+0x35/0x70 > > copy_process+0x190d/0x1b10 > > kernel_clone+0xba/0x3b0 > > __do_sys_clone+0x8f/0xb0 > > do_syscall_64+0x68/0x80 > > ? do_syscall_64+0x11/0x80 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > Before the 51cba1eb ("init_on_alloc: Optimize static branches") > > init_on_alloc never enabled static branch by default. It could > > only be enabed explicitly by init_mem_debugging_and_hardening(). > > > > But after the 51cba1eb static branch could already be enabled > > by default. There was no code to ever disable it. That caused > > page_poison=1 / init_on_free=1 conflict. > > > > This change extends init_mem_debugging_and_hardening() to also > > disable static branch disabling. > > > > ... > > > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -840,18 +840,22 @@ void init_mem_debugging_and_hardening(void) > > } > > #endif > > > > - if (_init_on_alloc_enabled_early) { > > - if (page_poisoning_requested) > > + if (_init_on_alloc_enabled_early || > > + IS_ENABLED(CONFIG_INIT_ON_ALLOC_DEFAULT_ON)) { > > + if (page_poisoning_requested) { > > pr_info("mem auto-init: CONFIG_PAGE_POISONING is on, " > > "will take precedence over init_on_alloc\n"); > > - else > > + static_branch_disable(&init_on_alloc); > > + } else > > static_branch_enable(&init_on_alloc); > > } > > - if (_init_on_free_enabled_early) { > > - if (page_poisoning_requested) > > + if (_init_on_free_enabled_early || > > + IS_ENABLED(CONFIG_INIT_ON_FREE_DEFAULT_ON)) { > > + if (page_poisoning_requested) { > > pr_info("mem auto-init: CONFIG_PAGE_POISONING is on, " > > "will take precedence over init_on_free\n"); > > - else > > + static_branch_disable(&init_on_free); > > + } else > > static_branch_enable(&init_on_free); > > } > > > > I'm thinking this is sufficiently serious and sufficiently reported to > warrant a cc:stable backport. Agree? I agree. The patch might be tricky to apply as is too far back. But current release should be fine. -- Sergei