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 B6679C433EF for ; Thu, 31 Mar 2022 08:57:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 419676B0073; Thu, 31 Mar 2022 04:57:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C7DE6B0074; Thu, 31 Mar 2022 04:57:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 28FE36B0075; Thu, 31 Mar 2022 04:57:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 1962C6B0073 for ; Thu, 31 Mar 2022 04:57:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D5EE9246D9 for ; Thu, 31 Mar 2022 08:57:10 +0000 (UTC) X-FDA: 79304077020.12.EB034B9 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf27.hostedemail.com (Postfix) with ESMTP id 2269940019 for ; Thu, 31 Mar 2022 08:57:09 +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 BAB291FD03; Thu, 31 Mar 2022 08:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1648717028; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o+QZvD8swjFnMSJcmeUxxDnjqZ670h4F9PHw1e2uO6Y=; b=DmVMe88X3xPisr03GZBMxO5DXXi9/CkJGwJrW1Oco73dhNHYTLOIcv4psO68j1x4APyjGD h/fDXEYsHFkjziCZpf/ZsZ2OfEUSR94mZr0A9qZB4Drtc35nGHRJB5XQ9xm3sifmA9thWb HR8pPbJnKdDkNashwvh2t5bqB+HTz8s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1648717028; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o+QZvD8swjFnMSJcmeUxxDnjqZ670h4F9PHw1e2uO6Y=; b=KwH0swrJbUSJFqGbJXITNAgtw3SAxx4MzaJ9KGYutSuFtaD5X+/We2vRP2DeYlLGRUMV6m lwTVRIEMjMyxJnDg== 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 8CE10133D4; Thu, 31 Mar 2022 08:57:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id MxO9IeRsRWIlKwAAMHmgww (envelope-from ); Thu, 31 Mar 2022 08:57:08 +0000 Message-ID: <3c30c5e9-c2fb-9f24-1207-8c342045996b@suse.cz> Date: Thu, 31 Mar 2022 10:57:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] mm: page_alloc: validate buddy before check its migratetype. Content-Language: en-US To: Zi Yan , Linus Torvalds Cc: Steven Rostedt , David Hildenbrand , Mel Gorman , Mike Rapoport , Oscar Salvador , Andrew Morton , Linux-MM , Linux Kernel Mailing List References: <20220330221238.396357-1-zi.yan@sent.com> <63234E12-AF64-4D85-A2BF-8A4EF5359F91@nvidia.com> <7586AEB3-FE81-4D51-ADAE-737E74625444@nvidia.com> From: Vlastimil Babka In-Reply-To: <7586AEB3-FE81-4D51-ADAE-737E74625444@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: bidh8iyds5nex5ksos1khstzfzanc9k7 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=DmVMe88X; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=KwH0swrJ; spf=pass (imf27.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2269940019 X-HE-Tag: 1648717029-647417 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 3/31/22 02:10, Zi Yan wrote: > On 30 Mar 2022, at 19:48, Zi Yan wrote: > >> On 30 Mar 2022, at 19:03, Linus Torvalds wrote: >> >>> On Wed, Mar 30, 2022 at 3:12 PM Zi Yan wrote: >>>> >>>> Fixes: 1dd214b8f21c ("mm: page_alloc: avoid merging non-fallbackable pageblocks with others") >>> >>> Oh, btw - should this perhaps be backported further back than that >>> alleged "fixes" commit? >>> >>> It does look like maybe the problem potentially existed before too, >>> and was just much harder to trigger. >>> >>> That said, google doesn't find any other reports that look like >>> Steven's oops, so maybe it really never happened and backporting isn't >>> called for. >>> >>> Or possibly my google-fu is just bad. >>> >> >> There might not be any issue with the original code because this bug >> could only be triggered when CONFIG_FLATMEM and CONFIG_MEMORY_ISOLATION >> are both set, which never happens, since CONFIG_MEMORY_ISOLATION >> depends on CONFIG_SPARSEMEM. Good point. Which means unset_migratetype_isolate() that Linus pointed out, is currently also safe as it's a CONFIG_MEMORY_ISOLATION code. We could still implement the suggested page_find_buddy() wrapper using page_is_buddy() internally, as well as the cleanup of __free_one_page(), but it's not urgent. >> By checking Steven's boot log, it should be PFN 0x21ee00 that triggers >> the bug, since the physical memory range ends at PFN 0x21edff. >> PFN 0x21ee00 is 2MB aligned instead of MAX_ORDER-1 (4MB) aligned. >> The original code assumes all physical memory ranges are at least >> MAX_ORDER-1 aligned, which is true when CONFIG_SPARSEMEM is set >> (CONFIG_MEMORY_ISOLATION depends on it), since CONFIG_SPARSEMEM >> allocates pageblock_flags array (the NULL-deferenced bitmap points >> to) at section size granularity (128MB > 4MB). However, CONFIG_FLATMEM >> does not do this. It allocates pageblock_flags array at the exact size >> of the physical memory. So checking 0x21ee00 will not cause NULL >> dereferencing when CONFIG_MEMORY_ISOLATION is set and the original >> if statement can be true. >> >> Now I am wondering if the page_is_buddy() check is correct for >> CONFIG_FLATMEM. Is mem_map allocation aligned to MAX_ORDER-1 >> or just the present physical memory range? Is PageBuddy(0x21ee00) >> accessing some random memory location? > > OK. mem_map seems to be MAX_ORDER-1 aligned, so there is no > problem with PageBuddy(0x21ee00). Yeah mem_map has to be in all config variants, otherwise buddy merging would have been blowing up in page_is_buddy() even prior to all the "sometimes avoid merging pageblock" changes. > > -- > Best Regards, > Yan, Zi