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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 2E70AC433C1 for ; Fri, 26 Mar 2021 16:03:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 92DB361A2A for ; Fri, 26 Mar 2021 16:03:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92DB361A2A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DFDA96B0070; Fri, 26 Mar 2021 12:03:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D741A6B0071; Fri, 26 Mar 2021 12:03:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA2DA6B0072; Fri, 26 Mar 2021 12:03:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 9AC7C6B0070 for ; Fri, 26 Mar 2021 12:03:24 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4FFC58249980 for ; Fri, 26 Mar 2021 16:03:24 +0000 (UTC) X-FDA: 77962495128.24.AFC28A2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 3D27F3505 for ; Fri, 26 Mar 2021 16:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616774600; 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=LZnm8HdGFNCRnMNSn+oQG/RYs2IjqgWrYp8rf77mRGU=; b=eLo/2p2oNUXfQU18/O+2bFyhNb6LuHDzyBElqYjpngMS9knGaNnFJlZxvylJ7KirEbg2Fl /y6qmnbx6COJ7JxyQge06i2TRwwO3DnhabRptH2wSZerdhgR+kwMVZOvnlR7iMqRsHqcYo IqDw0DadhBknNbi77utPxnnGuPNPdOg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-326-JiLdBBZXPm60hUQHLoHDfg-1; Fri, 26 Mar 2021 12:03:16 -0400 X-MC-Unique: JiLdBBZXPm60hUQHLoHDfg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 76DC9EC1A0; Fri, 26 Mar 2021 16:03:15 +0000 (UTC) Received: from [10.36.112.81] (ovpn-112-81.ams2.redhat.com [10.36.112.81]) by smtp.corp.redhat.com (Postfix) with ESMTP id 49FFD19CB2; Fri, 26 Mar 2021 16:03:13 +0000 (UTC) Subject: Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range To: Michal Hocko Cc: Oscar Salvador , Andrew Morton , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <92fe19d0-56ac-e929-a9c1-d6a4e0da39d1@redhat.com> <5be95091-b4ac-8e05-4694-ac5c65f790a4@redhat.com> <0e735ea7-b3d9-615e-6bba-fa3a16883226@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <3739470f-3b96-fa39-34dc-1ce46a68f1da@redhat.com> Date: Fri, 26 Mar 2021 17:03:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3D27F3505 X-Stat-Signature: uh644bhh49rwfufoqth7rt49h5n5qefc Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616774600-302803 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 26.03.21 16:31, Michal Hocko wrote: > On Fri 26-03-21 15:53:41, David Hildenbrand wrote: >> On 26.03.21 15:38, Michal Hocko wrote: >>> On Fri 26-03-21 09:52:58, David Hildenbrand wrote: > [...] >>>> 2. We won't allocate kasan shadow memory. We most probably have to do it >>>> explicitly via kasan_add_zero_shadow()/kasan_remove_zero_shadow(), see >>>> mm/memremap.c:pagemap_range() >>> >>> I think this is similar to the above. Does kasan has to know about >>> memory which will never be used for anything? >> >> IIRC, kasan will track read/writes to the vmemmap as well. So it could >> theoretically detect if we read from the vmemmap before writing >> (initializing) it IIUC. >> This is also why mm/memremap.c does a kasan_add_zero_shadow() before the >> move_pfn_range_to_zone()->memmap_init_range() for the whole region, >> including altmap space. >> >> Now, I am no expert on KASAN, what would happen in case we have access to >> non-tracked memory. >> >> commit 0207df4fa1a869281ddbf72db6203dbf036b3e1a >> Author: Andrey Ryabinin >> Date: Fri Aug 17 15:47:04 2018 -0700 >> >> kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN >> >> indicates that kasan will crash the system on "non-existent shadow memory" > > Interesting. Thanks for the pointer. > >>>> Further a locking rework might be necessary. We hold the device hotplug >>>> lock, but not the memory hotplug lock. E.g., for get_online_mems(). Might >>>> have to move that out online_pages. >>> >>> Could you be more explicit why this locking is needed? What it would >>> protect from for vmemmap pages? >>> >> >> One example is in mm/kmemleak.c:kmemleak_scan(), where we scan the vmemmap >> for pointers. We don't want the vmemmap to get unmapped while we are working >> on it (-> fault). > > Hmm, but they are not going away during offline. They just have a less > defined state. Or what exactly do you mean by unmapped? Hmm, also true. We should double check if we're touching other code that should better be synchronized with the memory hotplug lock. -- Thanks, David / dhildenb