From patchwork Tue Aug 25 22:58:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Berger X-Patchwork-Id: 11736975 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BD6FE138A for ; Tue, 25 Aug 2020 22:56:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 967622075E for ; Tue, 25 Aug 2020 22:56:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fTeJ5i13"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="c/dFY/lU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 967622075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Date:Message-ID:Subject:From:To: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=w2DX6BlHR9le1dGwDohG+cSaknGfQwGIxdUEPdv3xjE=; b=fTeJ5i13kPQ8HxLqROjVXJ+ScL O6IE1ptMmQ+m/vAAxqhwsGYx6Sw4cDhQ053TMqbwzIkxurEYPkLyUi+wdkIcbaNZ4VffTFIzFbipA m73wLE6PRg/pGiTvwFEcLcjV7mcLTndCZjd+ywgKGDYv9XFxDupgPemgVvM536AOy5LRw4IoayWWN TkqDm+92yeoGhGjpV1roqTM+BFEEyJG6Wif5K0TMJG+HWN+qcFN0O9oPBVcZ0Dwt07QTd4nV7su/q tkAeU+Wn/BNEoYtgatYq8cNR0mnitKhcPQtCc0du+TSVEY7+n2bhf2ppI0Ggzw83NQFNJAeOu8MGV 95Tf9o5Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAhqj-0007hK-C1; Tue, 25 Aug 2020 22:55:29 +0000 Received: from mail-pj1-x1042.google.com ([2607:f8b0:4864:20::1042]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAhqh-0007gO-Es for linux-arm-kernel@lists.infradead.org; Tue, 25 Aug 2020 22:55:28 +0000 Received: by mail-pj1-x1042.google.com with SMTP id ls14so245528pjb.3 for ; Tue, 25 Aug 2020 15:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=zzPbrQeMbbDq8vxQXVPO6befCNwmPB7fKgiXV+X7gIE=; b=c/dFY/lUiH0/gKb0XGwbFwRTuQhztL8wGE/O6bznGbsfHXepl/kGCQ69f0Q0rFmLlI ZmudC48SZebBBQOAmtib1quKOjuvuEVuj9GNxYG1X58xlMXBHBjVK/VWuLDIrYaxk5TD XYgnyGmVqIQm+Jw04tsYdHFv69EIOeWDzxeyMF0nnhtWJ/w3RZj9fAyTiuG91p/O+WqA 08hAI1NGzoCLRj7urDzWFD0pJK5x0yOzF1vrgkhB74kiBH3CFfDq8Y9vP0jIlOAuSWDN +2vGq/yehAEtgtQHrNKeAUyVznasHQO2sCf/QJgqaD0j1eUHdsDnfW5kT2/Cpw7fm77H fI3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=zzPbrQeMbbDq8vxQXVPO6befCNwmPB7fKgiXV+X7gIE=; b=emXkzSnuZneSO3fjthq6wgMEbkffXMKWTaaXnEw1nNpvEXKgQKDm+Q7kr2iShQvqNT EwPWZX3W5nSIo+Oye/uXrPIIQW49s6OMxvJeLr4Siq+Rtqbn3XuJdTRHPLXAp/g67Z+S rxdRapNW4inQV7+I4XTT8lG5xMMgLv8kHeecnIFOdkWlg+ixcr9tZumRUr4l9wktudTY ruutEJMBvPPJ5hNo52tG/2rIzTiaKN7DVYF5yuVgulmqTXry8tluEEo3FWB2NvIE+hY4 v5VU4h+ALsArub4aO9V9YE3yhET4nJtk3p6ybPZt3phGAvxybjKNtBPLUYwd76cnSGVd onpg== X-Gm-Message-State: AOAM532yKK6g6UXXZDa0EfmNjjKYv+zFf2su2QoKR5b3gfZnqa2a3JcG CFcGARV8Y8Nh8yMf2sEz380= X-Google-Smtp-Source: ABdhPJw9LpbzR+ZSRIPcFrQy0FTysaBF8gWzi404ijUQz+2/kAgv5ipXDZ3GZ0v87NLueYCuahMHEA== X-Received: by 2002:a17:90a:cc14:: with SMTP id b20mr3252895pju.1.1598396121012; Tue, 25 Aug 2020 15:55:21 -0700 (PDT) Received: from [10.69.56.142] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id f6sm145891pgf.68.2020.08.25.15.55.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Aug 2020 15:55:20 -0700 (PDT) To: stable@vger.kernel.org, Andrew Morton , Mike Rapoport , Pavel Tatashin From: Doug Berger Subject: RFC: backport of commit a32c1c61212d Message-ID: Date: Tue, 25 Aug 2020 15:58:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200825_185527_573462_BF6F4AA1 X-CRM114-Status: GOOD ( 32.90 ) X-Spam-Score: -0.2 (/) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [opendmb[at]gmail.com] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:1042 listed in] [list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , linux-kernel@vger.kernel.org, Baoquan He , Zhaoyang Huang , Greg Kroah-Hartman , zhaoyang , David Hildenbrand , Russell King , Michal Hocko , Olof Johansson , Ingo Molnar , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org I recently tracked down a problem I observed when booting a v5.4 kernel on a sparsemem UMA arm platform which includes a no-map reserved-memory region in the middle of its HighMem zone. When memmap_init_zone() is invoked the pfn's that correspond to the no-map region fail the early_pfn_valid() check and the struct page structures are not initialized creating a "hole" in the memmap. Later in my boot sequence the sock_init() initcall leads to a bpf_prog_alloc() which ends up stealing a page from the block containing the no-map region which then leads to a call of move_freepages_block() to reclassify the migratetype of the entire block. The function move_freepages() includes a check of pfn_valid_within for each page in the range, but since the arm architecture doesn't include HOLES_IN_ZONE this check is optimized out and the uninitialized struct page is accessed. Specifically, PageLRU() calls compound_head() on the page and if the page->compound_head value is odd the value is used as a pointer to the head struct page. For uninitialized memory there is a high chance that a random value of compound head will be odd and contain an invalid pointer value that causes the kernel to abort and panic. As you might imagine specifying HOLES_IN_ZONE for the arm build allows pfn_valid_within to protect against accessing the uninitialized struct page. However, the performance penalty this incurs seems unnecessary. Commit 35fd1eb1e821 ("mm/sparse: abstract sparse buffer allocations") as part of the "sparse_init rewrite" series introduced in v4.19 changed the way sparsemem memmaps are initialized. Prior to this patch the sparsemem memmaps are initialized to all 0's. I observed that on older kernels the "uninitialized" struct page access also occurs, but the 0 page->compound_head indicates no compound head and the page pointer is therefore not corrupted. The other logic ends up causing the page to be skipped and everything "happens to work". While considering solutions to this issue I observed that the problem does not occur in the current upstream as a result of a combination of other commits. The following commits provided functionality to initialize struct page structures for pages that are unavailable like the no-map region in my system: commit a4a3ede2132a ("mm: zero reserved and unavailable struct pages") commit 907ec5fca3dc ("mm: zero remaining unavailable struct pages") commit ec393a0f014e ("mm: return zero_resv_unavail optimization") commit e822969cab48 ("mm/page_alloc.c: fix uninitialized memmaps on a partially populated last section") commit 4b094b7851bf ("mm/page_alloc.c: initialize memmap of unavailable memory directly") However, those commits added the functionality to the free_area_init() and free_area_init_nodes() functions and the non-NUMA arm architecture did not begin calling free_area_init() until the following commit in v5.8: commit a32c1c61212d ("arm: simplify detection of memory zone boundaries") Prior to that commit the non-NUMA arm architecture called free_area_init_node() directly at the end of zone_sizes_init(). So while the problem appears to be fixed upstream by commit a32c1c61212d ("arm: simplify detection of memory zone boundaries") it is still present in stable branches between v4.19.y and v5.7.y inclusive and probably for architectures other than arm as well that didn't call free_area_init(). This upstream commit is not easily/safely backportable to stable branches, but if we focus on the sliver of functionality that adds the initialization code from free_area_init() to the zones_sizes_init() function used by non-NUMA arm kernels I believe a simple patch could be developed for each relevant stable branch to resolve the issue I am observing. Similar patches could also be applied for other architectures that now call free_area_init() upstream but not in one of these stable branches, but I am not in a position to test those architectures. For the linux-5.4.y branch such a patch might look like this: From 671c341b5cdb8360349c33ade43115e28ca56a8a Mon Sep 17 00:00:00 2001 From: Doug Berger Date: Tue, 25 Aug 2020 14:39:43 -0700 Subject: [PATCH] ARM: mm: sync zone_sizes_init with free_area_init The arm architecture does not invoke the common function free_area_init(). Instead for non-NUMA builds it invokes free_area_init_node() directly from zone_sizes_init(). As a result recent changes in free_area_init() are not picked up by arm architecture builds. This commit adds the updates to the zone_sizes_init() function to achieve parity with the free_area_init() functionality. Fixes: 35fd1eb1e821 ("mm/sparse: abstract sparse buffer allocations") Signed-off-by: Doug Berger Cc: stable@vger.kernel.org --- arch/arm/mm/init.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 6f19ba53fd1f..4f171d834c60 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -169,6 +169,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max_low, arm_dma_zone_size >> PAGE_SHIFT); #endif + zero_resv_unavail(); free_area_init_node(0, zone_size, min, zhole_size); }