Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4009693pxb; Tue, 2 Nov 2021 02:25:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxD7fi05ivJf5N65Rzpetm7SNqucTVe2TzNJv5rT99HW7krCIDLzTW+Jqsr+6hUPzqLzqhp X-Received: by 2002:a05:6602:1607:: with SMTP id x7mr3333197iow.134.1635845154052; Tue, 02 Nov 2021 02:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635845154; cv=none; d=google.com; s=arc-20160816; b=msbp47ToUcXsbLUh5SOZmZAIo1bf0EH+mfFhU6F8tRgV44W6ZZ+tTbLcpOmaSbsadk PATLpt3FZaK6ETxLPdUkSgksn0J2Lq5oTEIOo/kjsp8a9xF+qT1QvZ5EICdMez8nQ+wY O2oRb8w2/8vEONJDPSNXd5BhfLRQ47SPae2wVJcudNGBgyMKXum8RHhnT7xUEO58+MpT d4mijcaXMepmKY8xs4mDm3Q84ExANhN7BWa0yJsctGB0/Uexd80Jy02+uK/aqCqkC25j XDak3/ZCORfhwHqcxhgsXil8RVdceme8JagWMm3KNeg+0o2pOHcDTlT9NQ++WfbA44EO h5Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :organization:from:references:cc:to:content-language:user-agent :mime-version:date:message-id:dkim-signature; bh=Is5x4qunizskcubykNuexE0rm+el3szUQ1h1UP1TOd8=; b=EOlk2GDY1d6cVsyZYo906bQgutWSZjaoHJunzKbaQtF5KYuEtqHVepHu9bhM/iFNYa VzU67kxwIw9wEjHlvyqBTKEwsjbl+7mCoXBZl5APacWD3j1TZ9/IjpwSa9GRyYDXQf+A BgI3MbRXsN0TwrkmnKnLFbzVXshVTARB7yMbHQvshFX16a0dAZBZhYIrNYD7ZBDsiPPh DMN5qtYWiVIc6GMgPy1TbmZqQJxkm1dXIOd19QYVENoW8lRpYJFx3DeLHCT5m/3okb/c gCj2Cnh22YdHP/L4cDRqlM+SQdkZUJ9CCAkhSc+6PddH1zFd7b4VBGmi8PaLVvFOD72M mI9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=f5Uk3s2B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m22si8682694iow.61.2021.11.02.02.25.40; Tue, 02 Nov 2021 02:25:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=f5Uk3s2B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229881AbhKBJ1X (ORCPT + 99 others); Tue, 2 Nov 2021 05:27:23 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:55307 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbhKBJ1W (ORCPT ); Tue, 2 Nov 2021 05:27:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635845087; 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=Is5x4qunizskcubykNuexE0rm+el3szUQ1h1UP1TOd8=; b=f5Uk3s2BxgM5tPLSusZcmpc7Z5UO5MYRWbmvj3z85wcvRRu2SVPl3+w+AHNktSu9pjVd6m gnwXPi0rmLjBnwgN6yc7yntDP0ybkPkIB9adeRVMOdA9ZtaTTWx9GOXZYpNa4ZLFn6odRU 7LLxaTFcLneEBBV5MY+ZCVeWIcBxH7Q= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-135-QqnZ5n2MOX-nuPKykdSExg-1; Tue, 02 Nov 2021 05:24:46 -0400 X-MC-Unique: QqnZ5n2MOX-nuPKykdSExg-1 Received: by mail-wr1-f72.google.com with SMTP id j12-20020adf910c000000b0015e4260febdso7243409wrj.20 for ; Tue, 02 Nov 2021 02:24:45 -0700 (PDT) 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 :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=Is5x4qunizskcubykNuexE0rm+el3szUQ1h1UP1TOd8=; b=Gs+zb0iUL7gfbnWxy+9eI7cAOcTr4IwtBMffg06I9VcSx77EPH9Oe6WFkobaeuylnl mrgmY4AwfnO/zGCOcy1tTZPXVtWa4MWuN8FkHko0/DU5an++L6/fIzd1eJV9DPnNr8rz 6sh0QXX8GbB2+7J/62gIiFlpdDAzH8nEk8ZPusFL96O4qv9bm6RaThPh8w7Vq+YaSNPx kvKAK2ZUQ1qIqxDdvXDo+Av6qESU5NmAqehJbB+h1+xKSNvQmqnfM4/0YM+I0Ed30zQo za20l8fC6wnYLGuU47W+MpAI5wv8F2PaD7EV06HfTPmxTuY6GnXdrA9+Os/xZMn3Jl/O byXg== X-Gm-Message-State: AOAM532AR5Q4c60btHgteBEZ/q83A0NKGwhvie5RkHFL0h1l4HctmwZc j4G5/GCvC768jP8erThwtFxHUO2duZ1gqjBdxmixKKb4W7FbIvkMzF2zTQA0IDZS2IMnaS/w99r 86xXd8wmB/qUJDF8LAwV1vIZY X-Received: by 2002:adf:c604:: with SMTP id n4mr44318063wrg.202.1635845085001; Tue, 02 Nov 2021 02:24:45 -0700 (PDT) X-Received: by 2002:adf:c604:: with SMTP id n4mr44318038wrg.202.1635845084800; Tue, 02 Nov 2021 02:24:44 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6810.dip0.t-ipconnect.de. [91.12.104.16]) by smtp.gmail.com with ESMTPSA id p13sm2193869wmi.0.2021.11.02.02.24.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 02:24:44 -0700 (PDT) Message-ID: Date: Tue, 2 Nov 2021 10:24:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Michal Hocko , Alexey Makhalov Cc: "linux-mm@kvack.org" , Andrew Morton , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Oscar Salvador References: <20211101201312.11589-1-amakhalov@vmware.com> <7136c959-63ff-b866-b8e4-f311e0454492@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: fix panic in __alloc_pages In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> In add_memory_resource() we hotplug the new node if required and set it >>> online. Memory might get onlined later, via online_pages(). >> >> You are correct. In case of memory hot add, it is true. But in case of adding >> CPU with memoryless node, try_node_online() will be called only during CPU >> onlining, see cpu_up(). >> >> Is there any reason why try_online_node() resides in cpu_up() and not in add_cpu()? >> I think it would be correct to online node during the CPU hot add to align with >> memory hot add. > > I am not familiar with cpu hotplug, but this doesn't seem to be anything > new so how come this became problem only now? So IIUC, the issue is that we have a node a) That has no memory b) That is offline This node will get onlined when onlining the CPU as Alexey says. Yet we have some code that stumbles over the node and goes ahead trying to use the pgdat -- that code is broken. If we take a look at build_zonelists() we indeed skip any !node_online(node). Any other code should do the same. If the node is not online, it shall be ignored because we might not even have a pgdat yet -- see hotadd_new_pgdat(). Without node_online(), the pgdat might be stale or non-existant. The node onlining logic when onlining a CPU sounds bogus as well: Let's take a look at try_offline_node(). It checks that: 1) That no memory is *present* 2) That no CPU is *present* We should online the node when adding the CPU ("present"), not when onlining the CPU. -- Thanks, David / dhildenb