Received: by 10.213.65.68 with SMTP id h4csp1492524imn; Thu, 15 Mar 2018 00:47:24 -0700 (PDT) X-Google-Smtp-Source: AG47ELuv/Fkaz55+BNY+ZSc4NetdY5D9Nwj3dyEghxMnYz6hU+OaaYmrLKamhymDU/rbsVGPyYz1 X-Received: by 2002:a17:902:1665:: with SMTP id g92-v6mr1997188plg.195.1521100044297; Thu, 15 Mar 2018 00:47:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521100044; cv=none; d=google.com; s=arc-20160816; b=lYXr/7UTMxhKAoZt9cNGraFGms2r1EcuF+wG3cZhr9Yi/wrKaAfzqNFCLG6QZj6dsL AVfCx97v5CVyx/Zax2ABM9AtvFlVexbrSX+F2GjKRsFi6B/Lx1iMt+/CzcGk7AaQ1clF XvLUp9X9X6J/NlYL/QbVudSNylu/wJzA9w8HH6EyRxWPzcT65/AX8Gz4OwevlU3YP2Q0 YpnZ/EZQAsKLYjpWhAWIgu4MR2M2GrTz8wr5KVE4nlORBmCufelWpHkzzrOmfki8AkIW mKkBAZ5q5laoySRkUmPfLInNGScXAn74XN+q4SHr5l4AhmkOZLb3hTOaVp/vl5pYPLJF G+aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=FTx8amZykOc5CkGLg4mKjQAVkfmvXbOts84aVHWOEXU=; b=kDAgVHNvtJK4Cxy0tcnmmvOqsslu99llgxvtEgu2vyWacMvY139SlPxl6GO24eIAKd XcMBVF/1wGJebBwdSKh+LiFj/e4W8FykBLzQW3KgnkKgqO0g/0rZSDvu5yhg77lWxQEG aUwenkZSXC8lfGWNpsOlkXUUFePZlsbvpUiqBw55qK+3cKVhbOhKDHAEFB7AtvhDrkj5 6e6dXVEBikX28lHMM3Nb2jeU/TmgvS2wgTMhS0M1JwYr8WdzXiusrw4Ayxcbp8OI8rPC ic7SPr6NYvNXDsB30U8MQorcsY/0APiJZJSsLiQOJwslr/BgcmOYRjuYC8rMYgwAWDMJ SBgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=CXrKQj1Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f125si3045871pgc.736.2018.03.15.00.47.09; Thu, 15 Mar 2018 00:47:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=CXrKQj1Z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752041AbeCOHpY (ORCPT + 99 others); Thu, 15 Mar 2018 03:45:24 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:39417 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751555AbeCOHpX (ORCPT ); Thu, 15 Mar 2018 03:45:23 -0400 Received: by mail-io0-f194.google.com with SMTP id d11so1170524iop.6 for ; Thu, 15 Mar 2018 00:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FTx8amZykOc5CkGLg4mKjQAVkfmvXbOts84aVHWOEXU=; b=CXrKQj1Z+bhSxLwldT9NtyqAwd0hTJpcC9Yja4LLYG1LpMiwY1CENZQgGJDcMWfAGg RrLV5nc1TTTAaT/0VvbYCU+u583UTSVN9JNl52Ig2iGIqcQK6bOBW4r5tjDnD0gV2HE7 wCZK8z9NY38w7IS5QEP6D+xKBDa059PMous2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FTx8amZykOc5CkGLg4mKjQAVkfmvXbOts84aVHWOEXU=; b=ZjxlJGb5OMuUejvg0jA9kwVr73wOYqV3zbaOdo7NIBmvw4tuj725V1V9QmQ7i2QcHS m+9Odb+Iu6zRJhmdHeFHvsQLyb6j+JzXN4W91Keajgbx1uVEQVwBkeN0EUU+Q/0RhwVI +tlYYSS32KbpBE2l2+saQMMjUwdC6qQG8E63iyrPYntZ1qKSmkxq+DnyRp4U0Wfkugau ET1iwtCHl0ckoqG83+3TozeFbSMNN6SGOfHRAUuFWYr2pjY6DH6RzOw3zPLOImRknJd9 iiNaKqXUzghzEddRYtqR4lG80Tg3zO9VAys9IZZZbnl7/IzOHv9QYBw0uVeaE/iWA/xp HUXg== X-Gm-Message-State: AElRT7GW4NBJqkHErhSdBL/Vy8VkEloVns2vMeRv+JdoE/5FpWlDqHhH 3wvGHyqNkXTbtmEQXCfAJeC3spU0udyYnZt0MtqELA== X-Received: by 10.107.5.199 with SMTP id 190mr8252893iof.107.1521099922351; Thu, 15 Mar 2018 00:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 15 Mar 2018 00:45:21 -0700 (PDT) In-Reply-To: References: <20180314192937.12888-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 15 Mar 2018 07:45:21 +0000 Message-ID: Subject: Re: [PATCH v2] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment" To: Daniel Vacek Cc: linux-arm-kernel , open list , Mark Rutland , Will Deacon , Catalin Marinas , Marc Zyngier , Mel Gorman , Michal Hocko , Paul Burton , Pavel Tatashin , Vlastimil Babka , Andrew Morton , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15 March 2018 at 07:44, Daniel Vacek wrote: > On Thu, Mar 15, 2018 at 8:36 AM, Ard Biesheuvel > wrote: >> On 15 March 2018 at 02:23, Daniel Vacek wrote: >>> On Wed, Mar 14, 2018 at 8:29 PM, Ard Biesheuvel >>> wrote: >>>> This reverts commit 864b75f9d6b0100bb24fdd9a20d156e7cda9b5ae. >>>> >>>> Commit 864b75f9d6b0 ("mm/page_alloc: fix memmap_init_zone pageblock >>>> alignment") modified the logic in memmap_init_zone() to initialize >>>> struct pages associated with invalid PFNs, to appease a VM_BUG_ON() >>>> in move_freepages(), which is redundant by its own admission, and >>>> dereferences struct page fields to obtain the zone without checking >>>> whether the struct pages in question are valid to begin with. >>>> >>>> Commit 864b75f9d6b0 only makes it worse, since the rounding it does >>>> may cause pfn assume the same value it had in a prior iteration of >>>> the loop, resulting in an infinite loop and a hang very early in the >>>> boot. Also, since it doesn't perform the same rounding on start_pfn >>>> itself but only on intermediate values following an invalid PFN, we >>>> may still hit the same VM_BUG_ON() as before. >>>> >>>> So instead, let's fix this at the core, and ensure that the BUG >>>> check doesn't dereference struct page fields of invalid pages. >>>> >>>> Fixes: 864b75f9d6b0 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") >>>> Cc: Daniel Vacek >>>> Cc: Mel Gorman >>>> Cc: Michal Hocko >>>> Cc: Paul Burton >>>> Cc: Pavel Tatashin >>>> Cc: Vlastimil Babka >>>> Cc: Andrew Morton >>>> Cc: Linus Torvalds >>>> Signed-off-by: Ard Biesheuvel >>>> --- >>>> mm/page_alloc.c | 13 +++++-------- >>>> 1 file changed, 5 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>>> index 3d974cb2a1a1..635d7dd29d7f 100644 >>>> --- a/mm/page_alloc.c >>>> +++ b/mm/page_alloc.c >>>> @@ -1910,7 +1910,9 @@ static int move_freepages(struct zone *zone, >>>> * Remove at a later date when no bug reports exist related to >>>> * grouping pages by mobility >>>> */ >>>> - VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); >>>> + VM_BUG_ON(pfn_valid(page_to_pfn(start_page)) && >>>> + pfn_valid(page_to_pfn(end_page)) && >>>> + page_zone(start_page) != page_zone(end_page)); >>> >>> Hi, I am on vacation this week and I didn't have a chance to test this >>> yet but I am not sure this is correct. Generic pfn_valid() unlike the >>> arm{,64} arch specific versions returns true for all pfns in a section >>> if there is at least some memory mapped in that section. So I doubt >>> this prevents the crash I was targeting. I believe pfn_valid() does >>> not change a thing here :( >>> >> >> If this is the case, memblock_next_valid_pfn() is broken since it >> skips valid PFNs, and we should be fixing that instead. > > How do you define valid pfn? Maybe the generic version of pfn_valid() > should be fixed??? > memblock_next_valid_pfn() skips PFNs for which pfn_valid() returns true. That is clearly a bug.