Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp453958imu; Tue, 11 Dec 2018 01:52:11 -0800 (PST) X-Google-Smtp-Source: AFSGD/UJ1LYsI91e7auVgKMgB7pQLQ40X5ChO8R+OVqyo0pmbev5Sk2FsTNtdTPX+ImKBckA8K4t X-Received: by 2002:a65:4784:: with SMTP id e4mr13693838pgs.12.1544521931452; Tue, 11 Dec 2018 01:52:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544521931; cv=none; d=google.com; s=arc-20160816; b=ZaESKG6riYUAjZKOygD5VVN0Mo3O10wt2ML+7IkcG3jiwLqh8IqHDt6kti+pZf85RU 0krP7o51BKtGblBsgcMBf7JQog+38EPr1VGAMtclyE7vOYrOdl/3q6if3mPjkBfdrUv7 +OKkWgM7vuRFhnXoyyXTe9pSjd3QajxSHFpkGQ8iLvbT6p53rM1GMA7yPGI2b4aUAOES wJbRuzEGbqQv+Rs6rTD0ThVRk5oPfJfxdK6MiZdrgGYblOaM1UFRN4gipJe30VWRQP+Q cXcEgjeZYPQtAQF6QsaUE+k236speJQfleSrvvgfyuC8SVGn7oQqWc319E6xZhmFA4a5 /a5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=fHshz6dG9q5FjalI+yNJYMa2+98nNn+rLuJ4jSiPoZw=; b=TnUiclzcESEpeDcZSSoAz9DebsuiSSyKWjq4gY7csE6Q/4HMCls6+I1hriqv1OtxN9 6SPAtZZsZMCFTtG5VtBjY2HTIHZuwZZgRlSOcH4QEdPU9/nspeMo+7QP+kUvjSEY1IdB nG/+zQB1FeypJzUS3NohE5RR4zKx/9oC/ZqSFlKuSjYTi02qAdqbwippccIC+GPTAkLT U9eimrNIdVXM+0TtGIHufT4dbuCI36W/ZzFiXBcFWiXHFbFD53BbcmsCafaJgmntEVkT gC4rFrbV/xvBCTM4xgnvv77rv2qT5FvVbJaKcz2a6jvXk9Br36papVKwTXaB5Sj5Y2OI nYtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ktbOt4rE; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e7si13324328pfh.147.2018.12.11.01.51.53; Tue, 11 Dec 2018 01:52:11 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=ktbOt4rE; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726264AbeLKJtm (ORCPT + 99 others); Tue, 11 Dec 2018 04:49:42 -0500 Received: from mail-ed1-f65.google.com ([209.85.208.65]:39810 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726137AbeLKJtl (ORCPT ); Tue, 11 Dec 2018 04:49:41 -0500 Received: by mail-ed1-f65.google.com with SMTP id b14so11958901edt.6 for ; Tue, 11 Dec 2018 01:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fHshz6dG9q5FjalI+yNJYMa2+98nNn+rLuJ4jSiPoZw=; b=ktbOt4rEZWauE4Rh+G/pmsASgkh3z7G4CoCAkw5WP6vJOQwzaEHsAxuFp0rfMAaNbK 9z4yCBXfHnU+pSlYQMpEA8k9uJrzYTudk6I5I0bTyF4XN8O3zH1FWXjL13QhuuW36EVy o6j1RyprtdBuLw9xzKemQ3tn6mBgQztcDMVSfXZl8Jf7/GG0RjTB4G49FqgBHIxcWt8X o5HDH9kwKl3JuvxMhG+TNTgRIbv0h4zZd5iAJoqjNFtqRvPNo8YazOUcFGSeEIsq3Kh4 0CFjLgdOAja6okhQOgRqt809PocQWPbzsHCQQImkRxkoFOVIrDXN51EnNaxWxct4Zh0j qAuw== 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:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=fHshz6dG9q5FjalI+yNJYMa2+98nNn+rLuJ4jSiPoZw=; b=A3i8j6pcqNLLA58XZV30iMcyrb/zCzPwW2GQ8/9S86qWwhr1cGjxfDpgfaXHTTTivb I6frg0z2oZrYOQ53OPgIuHJtvrihasf0L8KrD5QIUiQTVtAaHICGfyinB7SxyErbdiUD SiUJYayD5bQR/Q8FnVJbt1iM1dFRbqLyGyasEa0QPbc1k5kBzGQHmv5KXKfmgxJb5q4V wxeOJjE1DJT9H4zZJ8KkocVA8OOJ51rp2mjZzPrHXvH80O9bJ5b+J7VhS+kerNxdrgOY WtVpAtV1BXZYGqU06p8pvewruxUKBB24ifiBpmEp3FedGNBf1TKO19McTWO3J5J/ezSA Q5DQ== X-Gm-Message-State: AA+aEWbrENu7pD0ZAWojNyuotlku8cBk3Gs6HTORwDbNhikawA9pohZo 7oonk8fM+zr8BB33o8D3LcA= X-Received: by 2002:a17:906:4e14:: with SMTP id z20-v6mr2721916eju.187.1544521779587; Tue, 11 Dec 2018 01:49:39 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id z6-v6sm2203357ejq.63.2018.12.11.01.49.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Dec 2018 01:49:38 -0800 (PST) Date: Tue, 11 Dec 2018 09:49:38 +0000 From: Wei Yang To: Michal Hocko Cc: Mikhail Zaslonko , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pavel.Tatashin@microsoft.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, gerald.schaefer@de.ibm.com Subject: Re: [PATCH 1/1] mm, memory_hotplug: Initialize struct pages for the full memory section Message-ID: <20181211094938.3mykr3n3tp6rfz4p@master> Reply-To: Wei Yang References: <20181210130712.30148-1-zaslonko@linux.ibm.com> <20181210130712.30148-2-zaslonko@linux.ibm.com> <20181210132451.GO1286@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181210132451.GO1286@dhcp22.suse.cz> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 10, 2018 at 02:24:51PM +0100, Michal Hocko wrote: >On Mon 10-12-18 14:07:12, Mikhail Zaslonko wrote: >> If memory end is not aligned with the sparse memory section boundary, the >> mapping of such a section is only partly initialized. > >It would be great to mention how you can end up in the situation like >this(a user provided memmap or a strange HW). > >> This may lead to >> VM_BUG_ON due to uninitialized struct page access from >> is_mem_section_removable() or test_pages_in_a_zone() function triggered by >> memory_hotplug sysfs handlers: >> >> page:000003d082008000 is uninitialized and poisoned >> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p)) >> Call Trace: >> ([<0000000000385b26>] test_pages_in_a_zone+0xde/0x160) >> [<00000000008f15c4>] show_valid_zones+0x5c/0x190 >> [<00000000008cf9c4>] dev_attr_show+0x34/0x70 >> [<0000000000463ad0>] sysfs_kf_seq_show+0xc8/0x148 >> [<00000000003e4194>] seq_read+0x204/0x480 >> [<00000000003b53ea>] __vfs_read+0x32/0x178 >> [<00000000003b55b2>] vfs_read+0x82/0x138 >> [<00000000003b5be2>] ksys_read+0x5a/0xb0 >> [<0000000000b86ba0>] system_call+0xdc/0x2d8 >> Last Breaking-Event-Address: >> [<0000000000385b26>] test_pages_in_a_zone+0xde/0x160 >> Kernel panic - not syncing: Fatal exception: panic_on_oops >> >> Fix the problem by initializing the last memory section of the highest zone >> in memmap_init_zone() till the very end, even if it goes beyond the zone >> end. > >Why do we need to restrict this to the highest zone? In other words, why >cannot we do what I was suggesting earlier [1]. What does prevent other >zones to have an incomplete section boundary? > >[1] http://lkml.kernel.org/r/20181105183533.GQ4361@dhcp22.suse.cz > I tried to go through the original list and make myself familiar with the bug. Confused why initialize the *last* end_pfn could fix this, since is_mem_section_removable() will iterate on each page of a section. This means we need to initialize all the pages left in the section. One way to fix this in my mind is to record the last pfn in mem_section. This could be done in memory_preset(), since after that we may assume the section is full. Not sure whether you would like it. -- Wei Yang Help you, Help me