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 C2A7FC433F5 for ; Thu, 17 Feb 2022 07:48:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28FCF6B0074; Thu, 17 Feb 2022 02:48:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 23F6F6B0075; Thu, 17 Feb 2022 02:48:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10A0F6B0078; Thu, 17 Feb 2022 02:48:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 0169A6B0074 for ; Thu, 17 Feb 2022 02:48:57 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A83DB180972C1 for ; Thu, 17 Feb 2022 07:48:57 +0000 (UTC) X-FDA: 79151495514.30.B48CC94 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 2124B40007 for ; Thu, 17 Feb 2022 07:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645084136; h=from:from:reply-to:subject:subject: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=pdAg90pUxF/1MvitVVB0BXYLg+OihYbOUilPPPcMHmA=; b=g5CmoIiYFuNv5JY3b209d0DfmYpN/0QfIQxIeOcYAFRa2X/MoaY3eaZRUrYdEY6o7MgmUJ swYGgC491cowK6mni/5u5EZHwc9CVNBCWa5Rku6Qm0AVAqOZQJpCI/L+vl3qF4EOd3WYYG N8gk2KtnGMAOOX1AZG3urTCNgI1NGWI= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-208-mqtqPENOMXG9t4-FpUm1nw-1; Thu, 17 Feb 2022 02:48:55 -0500 X-MC-Unique: mqtqPENOMXG9t4-FpUm1nw-1 Received: by mail-ed1-f71.google.com with SMTP id cr7-20020a056402222700b0040f59dae606so3032927edb.11 for ; Wed, 16 Feb 2022 23:48:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=pdAg90pUxF/1MvitVVB0BXYLg+OihYbOUilPPPcMHmA=; b=Xo/XWMxUp/Y6/m0lkua7C2jPcnh1EWfbjwueVPGjMPPZmP9O70wSG9tDUQ1LDuwXZE UyUAoQ4JM0sljBiRHpTFsQBX80hDeJCH1y+cj1HoO3KwjJW6vBY4W+h07pK4kQdbJMFG T9Uq1++0ZVREKxW76/F3RHZzF8TBbABvvMaROQlKg8u1nFoCcTHRBTI9yudlr4SHGJqD yeWqH8s5DvHVVJjvv6kvnyDqjmTkW5tQWviw33kfAFpwGuktt6UiAXmWzgRvYnN9Twmy BfAso4hAzgjlzBDMUGBxydPJamW6HixmOIuj5ZTGZ2q4nnAEAM6MiAvCwkKWXHQPEq03 I1PA== X-Gm-Message-State: AOAM53359XldU7u/10aaeDGBDNuslTTBKKS2iegkD/3R2fxBLhDdbONH tJBxYEgV6YLxqvu88eoRQQbrfNFdvQMjSXqXQzozyEmQRgg+OB2DwEtAEoFc3OywDDNnDwW3jVH OgnEpUMBO1lg= X-Received: by 2002:a17:906:2a1b:b0:6ce:a15b:a561 with SMTP id j27-20020a1709062a1b00b006cea15ba561mr1401064eje.403.1645084134149; Wed, 16 Feb 2022 23:48:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJyxVRA0gZHCxAgTIvc/bzkL1W2xJ8UxU08IwpSm4JuYYAe+CPYKxstWgqdBgzO7BNytpAy/Ig== X-Received: by 2002:a17:906:2a1b:b0:6ce:a15b:a561 with SMTP id j27-20020a1709062a1b00b006cea15ba561mr1401050eje.403.1645084133820; Wed, 16 Feb 2022 23:48:53 -0800 (PST) Received: from ?IPV6:2003:cb:c711:b800:254c:2d22:aab2:20a? (p200300cbc711b800254c2d22aab2020a.dip0.t-ipconnect.de. [2003:cb:c711:b800:254c:2d22:aab2:20a]) by smtp.gmail.com with ESMTPSA id q14sm2885329edd.54.2022.02.16.23.48.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Feb 2022 23:48:53 -0800 (PST) Message-ID: Date: Thu, 17 Feb 2022 08:48:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] mm/pages_alloc.c: Don't create ZONE_MOVABLE beyond the end of a node To: Alistair Popple , akpm@linux-foundation.org Cc: jhubbard@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ziy@nvidia.com References: <20220215025831.2113067-1-apopple@nvidia.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220215025831.2113067-1-apopple@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2124B40007 X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=g5CmoIiY; spf=none (imf07.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: kdt5wk7jeoegd4edbjcwtshhag5wft9x X-Rspamd-Server: rspam03 X-HE-Tag: 1645084136-848292 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 15.02.22 03:58, Alistair Popple wrote: > ZONE_MOVABLE uses the remaining memory in each node. It's starting pfn > is also aligned to MAX_ORDER_NR_PAGES. It is possible for the remaining > memory in a node to be less than MAX_ORDER_NR_PAGES, meaning there is > not enough room for ZONE_MOVABLE on that node. > > Unfortunately this condition is not checked for. This leads to > zone_movable_pfn[] getting set to a pfn greater than the last pfn in a > node. > > calculate_node_totalpages() then sets zone->present_pages to be greater > than zone->spanned_pages which is invalid, as spanned_pages represents > the maximum number of pages in a zone assuming no holes. > > Subsequently it is possible free_area_init_core() will observe a zone of > size zero with present pages. In this case it will skip setting up the > zone, including the initialisation of free_lists[]. > > However populated_zone() checks zone->present_pages to see if a zone has > memory available. This is used by iterators such as > walk_zones_in_node(). pagetypeinfo_showfree() uses this to walk the > free_list of each zone in each node, which are assumed to be initialised > due to the zone not being empty. As free_area_init_core() never > initialised the free_lists[] this results in the following kernel crash > when trying to read /proc/pagetypeinfo: > > [ 67.534914] BUG: kernel NULL pointer dereference, address: 0000000000000000 > [ 67.535429] #PF: supervisor read access in kernel mode > [ 67.535789] #PF: error_code(0x0000) - not-present page > [ 67.536128] PGD 0 P4D 0 > [ 67.536305] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI > [ 67.536696] CPU: 0 PID: 456 Comm: cat Not tainted 5.16.0 #461 > [ 67.537096] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 > [ 67.537638] RIP: 0010:pagetypeinfo_show+0x163/0x460 > [ 67.537992] Code: 9e 82 e8 80 57 0e 00 49 8b 06 b9 01 00 00 00 4c 39 f0 75 16 e9 65 02 00 00 48 83 c1 01 48 81 f9 a0 86 01 00 0f 84 48 02 00 00 <48> 8b 00 4c 39 f0 75 e7 48 c7 c2 80 a2 e2 82 48 c7 c6 79 ef e3 82 > [ 67.538259] RSP: 0018:ffffc90001c4bd10 EFLAGS: 00010003 > [ 67.538259] RAX: 0000000000000000 RBX: ffff88801105f638 RCX: 0000000000000001 > [ 67.538259] RDX: 0000000000000001 RSI: 000000000000068b RDI: ffff8880163dc68b > [ 67.538259] RBP: ffffc90001c4bd90 R08: 0000000000000001 R09: ffff8880163dc67e > [ 67.538259] R10: 656c6261766f6d6e R11: 6c6261766f6d6e55 R12: ffff88807ffb4a00 > [ 67.538259] R13: ffff88807ffb49f8 R14: ffff88807ffb4580 R15: ffff88807ffb3000 > [ 67.538259] FS: 00007f9c83eff5c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 > [ 67.538259] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 67.538259] CR2: 0000000000000000 CR3: 0000000013c8e000 CR4: 0000000000350ef0 > [ 67.538259] Call Trace: > [ 67.538259] > [ 67.538259] seq_read_iter+0x128/0x460 > [ 67.538259] ? aa_file_perm+0x1af/0x5f0 > [ 67.538259] proc_reg_read_iter+0x51/0x80 > [ 67.538259] ? lock_is_held_type+0xea/0x140 > [ 67.538259] new_sync_read+0x113/0x1a0 > [ 67.538259] vfs_read+0x136/0x1d0 > [ 67.538259] ksys_read+0x70/0xf0 > [ 67.538259] __x64_sys_read+0x1a/0x20 > [ 67.538259] do_syscall_64+0x3b/0xc0 > [ 67.538259] entry_SYSCALL_64_after_hwframe+0x44/0xae > [ 67.538259] RIP: 0033:0x7f9c83e23cce > [ 67.538259] Code: c0 e9 b6 fe ff ff 50 48 8d 3d 6e 13 0a 00 e8 c9 e3 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 > [ 67.538259] RSP: 002b:00007fff116e1a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 > [ 67.538259] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f9c83e23cce > [ 67.538259] RDX: 0000000000020000 RSI: 00007f9c83a2c000 RDI: 0000000000000003 > [ 67.538259] RBP: 00007f9c83a2c000 R08: 00007f9c83a2b010 R09: 0000000000000000 > [ 67.538259] R10: 00007f9c83f2d7d0 R11: 0000000000000246 R12: 0000000000000000 > [ 67.538259] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 > [ 67.538259] > > Fix this by checking that the aligned zone_movable_pfn[] does not exceed > the end of the node, and if it does skip creating a movable zone on this > node. > > Signed-off-by: Alistair Popple > Fixes: 2a1e274acf0b ("Create the ZONE_MOVABLE zone") > --- > mm/page_alloc.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3589febc6d31..a1fbf656e7db 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -7972,10 +7972,17 @@ static void __init find_zone_movable_pfns_for_nodes(void) > > out2: > /* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */ > - for (nid = 0; nid < MAX_NUMNODES; nid++) > + for (nid = 0; nid < MAX_NUMNODES; nid++) { > + unsigned long start_pfn, end_pfn; > + > zone_movable_pfn[nid] = > roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES); > > + get_pfn_range_for_nid(nid, &start_pfn, &end_pfn); > + if (zone_movable_pfn[nid] >= end_pfn) > + zone_movable_pfn[nid] = 0; > + } > + > out: > /* restore the node_state */ > node_states[N_MEMORY] = saved_node_state; Sounds plausible for me Acked-by: David Hildenbrand -- Thanks, David / dhildenb