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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60CE0C35254 for ; Mon, 17 Feb 2020 12:47:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1059A22525 for ; Mon, 17 Feb 2020 12:47:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1059A22525 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6432A6B0005; Mon, 17 Feb 2020 07:47:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F2EE6B0006; Mon, 17 Feb 2020 07:47:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 508566B0007; Mon, 17 Feb 2020 07:47:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 39E2D6B0005 for ; Mon, 17 Feb 2020 07:47:39 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6593F180AD807 for ; Mon, 17 Feb 2020 12:47:38 +0000 (UTC) X-FDA: 76499595396.03.nest38_5fbf4fc371b0b X-HE-Tag: nest38_5fbf4fc371b0b X-Filterd-Recvd-Size: 6694 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Feb 2020 12:47:37 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id g3so19549366wrs.12 for ; Mon, 17 Feb 2020 04:47:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9zdkLGA3hKCBZeu7VULpfEUevUDa2QPIYuj6g0+A/nM=; b=SK1AJTX5pj/vavR3zM6li58a+DgJjAsCzOb1euIA2XoAA+Th0BB7yTGlslKH7BJMCI hoaYS8Wo3I6WC+29FFBxD11Yu/kDlOIit/YmcKF6JYfpsDDLyw/+6ec91PQKPP0/wYP5 wcCgRBFR4p5DvsMra7wCWgYrTACJWv70vp5APmudOMFxivM04uebYMh9RNXPWGaF0/XT C7FW0rhxFBzMC+v8uOb3rcy44A98mwjVMdtPHT0rl+D+xPCEfKPOnq8KJiBhB7+GfSHo 9gzgNEZqjlwJNmVgfBcOgrDeS733KzGivo2UlSivU3OflN0oP/hjaTQOTpEoZSmMtErb 0CNg== X-Gm-Message-State: APjAAAV7ttiqggVcPntp/JJ5Bpi9hM76y+GCi3Y3eQI1Mmmnt48p279U +ShIo7m8kohTx/2ixoch9x8= X-Google-Smtp-Source: APXvYqzWP70Gdz/G7OGZJ6+ftQQ4zR6+IkjbzSMHbOOObez6YizLdUq6vT/kki3WWM4fQD4bIfWaow== X-Received: by 2002:a5d:4085:: with SMTP id o5mr21812991wrp.321.1581943656636; Mon, 17 Feb 2020 04:47:36 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id x6sm890786wrr.6.2020.02.17.04.47.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 04:47:35 -0800 (PST) Date: Mon, 17 Feb 2020 13:47:35 +0100 From: Michal Hocko To: Baoquan He Cc: David Hildenbrand , kkabe@vega.pgw.jp, Oscar Salvador , bugzilla-daemon@bugzilla.kernel.org, akpm@linux-foundation.org, richardw.yang@linux.intel.com, n-horiguchi@ah.jp.nec.com, linux-mm@kvack.org Subject: Re: [Bug 206401] kernel panic on Hyper-V after 5 minutes due to memory hot-add Message-ID: <20200217124735.GK31531@dhcp22.suse.cz> References: <20200212073123.GG8965@MiWiFi-R3L-srv> <200217144627.M0113305@vega.pgw.jp> <20200217093447.GA1139@linux> <20200217101318.GL26758@MiWiFi-R3L-srv> <383e5dbf-b402-575d-8dae-5e92b51e9834@redhat.com> <20200217103347.GM26758@MiWiFi-R3L-srv> <20200217112054.GA9823@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200217112054.GA9823@MiWiFi-R3L-srv> 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 Mon 17-02-20 19:20:54, Baoquan He wrote: > On 02/17/20 at 11:38am, David Hildenbrand wrote: > > On 17.02.20 11:33, Baoquan He wrote: > > > On 02/17/20 at 11:24am, David Hildenbrand wrote: > > >> On 17.02.20 11:13, Baoquan He wrote: > > >>> On 02/17/20 at 10:34am, Oscar Salvador wrote: > > >>>> On Mon, Feb 17, 2020 at 02:46:27PM +0900, kkabe@vega.pgw.jp wrote: > > >>>>> =========================================== > > >>>>> struct page * __meminit populate_section_memmap(unsigned long pfn, > > >>>>> unsigned long nr_pages, int nid, struct vmem_altmap *altmap) > > >>>>> { > > >>>>> struct page *page, *ret; > > >>>>> unsigned long memmap_size = sizeof(struct page) * PAGES_PER_SECTION; > > >>>>> > > >>>>> page = alloc_pages(GFP_KERNEL|__GFP_NOWARN, get_order(memmap_size)); > > >>>>> if (page) { > > >>>>> goto got_map_page; > > >>>>> } > > >>>>> pr_info("%s: alloc_pages() returned 0x%p (should be 0), reverting to vmalloc(memmap_size=%lu)\n", __func__, page, memmap_size); > > >>>>> BUG_ON(page != 0); > > >>>>> > > >>>>> ret = vmalloc(memmap_size); > > >>>>> pr_info("%s: vmalloc(%lu) returned 0x%p\n", __func__, memmap_size, ret); > > >>>>> if (ret) { > > >>>>> goto got_map_ptr; > > >>>>> } > > >>>>> > > >>>>> return NULL; > > >>>>> got_map_page: > > >>>>> ret = (struct page *)pfn_to_kaddr(page_to_pfn(page)); > > >>>>> pr_info("%s: allocated struct page *page=0x%p\n", __func__, page); > > >>>>> got_map_ptr: > > >>>>> > > >>>>> pr_info("%s: returning struct page * =0x%p\n", __func__, ret); > > >>>>> return ret; > > >>>>> } > > >>>> > > >>>> Could you please replace %p with %px. Wih the first, pointers are hashed so it is trickier > > >>>> to get an overview of the meaning. > > >>>> > > >>>> David could be right about ZONE_NORMAL vs ZONE_HIGHMEM. > > >>>> IIUC, default_kernel_zone_for_pfn and default_zone_for_pfn seem to only deal with > > >>>> (ZONE_DMA,ZONE_NORMAL] or ZONE_MOVABLE. > > >>> > > >>> Ah, I think you both have spotted the problem. > > >>> > > >>> In i386, if w/o momory hot add, normal memory will only include those > > >>> below 896M and they are added into normal zone. The left are added into > > >>> highmem zone. > > >>> > > >>> How this influence the page allocation? > > >>> > > >>> Very huge. As we know, in i386, normal memory can be accessed with > > >>> virt_to_phys, namely PAGE_OFFSET + phys. But highmem has to be accessed > > >>> with kmap. However, the later hot added memory are all put into normal > > >>> memmory, accessing into them will stump into vmalloc area, I would say. > > >>> > > >>> So, i386 doesn't support memory hot add well. Not sure if below change > > >>> can make it work normally. > > >>> > > Please try below code instead, see if it works. However, as David and > and Michal said in other reply, if no real use case, we may not be so > eager to support mem hotplug on i386. Yes please. Can we just mark it broken until there is a real usecase? Convoluting the code even more for something that is not in use is just adding a maintenance burden and the memory hotplug is seriously understuffed in man power already. This is likely a fallout of the hotplug rework (c6f03e2903c9e) from 2 years ago. I cannot really say whether the code worked reasonably before the rework because I never considered hotplug on 32b to be something to even try TBH. Mostly because lowmem is unlikely to ever benefit from hotplug and adding more highmem just makes all the lowmem problems even worse so this is dubious in itself. That being said, I am willing to investigate further if there is a real usecase for this but considering that nobody has noticed the breakage in almost 3 years then I simply suspect that this is not really interesting and marking it explicitly BROKEN is a better option. -- Michal Hocko SUSE Labs