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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 B3A8BC433E0 for ; Tue, 12 Jan 2021 20:52:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 400172311F for ; Tue, 12 Jan 2021 20:52:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 400172311F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BDC9C6B00D3; Tue, 12 Jan 2021 15:52:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B400E6B00D4; Tue, 12 Jan 2021 15:52:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2E866B00D5; Tue, 12 Jan 2021 15:52:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8A03E6B00D3 for ; Tue, 12 Jan 2021 15:52:17 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4A936180AD81D for ; Tue, 12 Jan 2021 20:52:17 +0000 (UTC) X-FDA: 77698320714.04.view37_3300ca827518 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 1B5BB800EEA9 for ; Tue, 12 Jan 2021 20:52:17 +0000 (UTC) X-HE-Tag: view37_3300ca827518 X-Filterd-Recvd-Size: 6928 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 20:52:15 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id r5so3851378eda.12 for ; Tue, 12 Jan 2021 12:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=igUkdL4hc98zgwZyYfUvzpN2tIurwQ9y1Rg/DLI8Hes=; b=XKg4ur4aKi8mS1g2q2IzWLf7nq3NPbpuz37jjJzPntepgC/Jh/GUl1Lc+ZFtHqbwJm I9HRLMMUfLZ4JAwoit/6XFM9b3QoHv9XS6PJ3SG5jN3OP5etdxuM5SerHnefSQscANXO Ex/ooAYHonG28OZSy39VOeyRzJFG6CM6QbtkTPh5u1HAuM64FRxzyv060nBP6mxDPeVs MOXkMGCcPE5toPO108rHy3h8YGSc0dMp6QsVxHJ+PAVjE8jXxiHFO9MsmMVOwulCR4hG SfXh9NVe8+5ybflZUk6jvYu46HMJj1F3esvKBsqqpBauP3xJcAHNok/gg0DsirH6KWx8 UT7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=igUkdL4hc98zgwZyYfUvzpN2tIurwQ9y1Rg/DLI8Hes=; b=r3HfkSlm8goNdeHKiC4/oy1KhWOyRqoQ9pkVg4cj+QP1MqgfToHQt8pFshx6TbEf+8 lO1KjODdS4Rtx9BiljH2rTTXSt+4OoEa+PWEFAOX7B2HE06dBQfGyuYRSzdIUnYaB9Mk lEHYbIq8un+h1H2hfT7xPSkAZICKWKHCPdLUmvjBIqhub6M+/V+onAhDkk6OiY/xKtIc L6FTfukJaTK14fgwsqNNZO3xrFlQ3jSatiig612A75syfVtm7Lew22nbRVwOgWyPrljg JJWi1Ze3OafoUO1Jx2NYfSkrTTeX8O92BpkGub8lPplG4JHAhWRqR/98XK4hHOoWbt8x XCjQ== X-Gm-Message-State: AOAM531k0ef+uW44OyThLZZQ6NteRbzeCwiijDth3lu56DRd7UDBF+51 ukPxPJDGcliCVbfjbUUPWtQhIL0LKTu3/vl2Lvxd3Q== X-Google-Smtp-Source: ABdhPJyuyWgqRIMJC98ViB7sEAgKRXvqDgVKMOXcoLQs2zafRAgYEYid196V0DbGfnqFYnbaAhDjD0xvcGpN7W34Y9E= X-Received: by 2002:a05:6402:1102:: with SMTP id u2mr838270edv.18.1610484734302; Tue, 12 Jan 2021 12:52:14 -0800 (PST) MIME-Version: 1.0 References: <160990599013.2430134.11556277600719835946.stgit@dwillia2-desk3.amr.corp.intel.com> <785b9095-eca4-8100-33ea-6ae84e02a92e@redhat.com> <20210106104255.GK13207@dhcp22.suse.cz> <7d7c5dc4-7784-5dcc-fc00-4fe99f0a4a90@redhat.com> <75bb1429-d133-d303-a67a-be16c654ada8@redhat.com> In-Reply-To: From: Dan Williams Date: Tue, 12 Jan 2021 12:52:05 -0800 Message-ID: Subject: Re: [PATCH] mm: Teach pfn_to_online_page() about ZONE_DEVICE section collisions To: David Hildenbrand Cc: Michal Hocko , Linux MM , Andrew Morton , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 Tue, Jan 12, 2021 at 1:44 AM David Hildenbrand wrote: > > On 12.01.21 10:18, Dan Williams wrote: > > On Thu, Jan 7, 2021 at 1:16 AM David Hildenbrand wrote: > >> > >> [...] > >> > >>>>> Well, I would love to have no surprises either. So far there was not > >>>>> actual argument why the pmem reserved space cannot be fully initialized. > >>>> > >>>> Yes, I'm still hoping Dan can clarify that. > >>> > >>> Complexity and effective utility (once pfn_to_online_page() is fixed) > >>> are the roadblocks in my mind. The altmap is there to allow for PMEM > >>> capacity to be used as memmap space, so there would need to be code to > >>> break that circular dependency and allocate a memmap for the metadata > >>> space from DRAM and the rest of the memmap space for the data capacity > >>> from pmem itself. That memmap-for-pmem-metadata will still represent > >>> offline pages. So once pfn_to_online_page() is fixed, what pfn-walker > >>> is going to be doing pfn_to_page() on PMEM metadata? Secondly, there > >> > >> Assume I do > >> > >> pgmap = get_dev_pagemap(pfn, NULL); > >> if (pgmap) > >> return pfn_to_page(pfn); > >> return NULL; > >> > >> on a random pfn because I want to inspect ZONE_DEVICE PFNs. > > > > I keep getting hung up on the motivation to do random pfn inspection? > > > > The problems we have found to date have required different solutions. > > The KVM bug didn't use get_dev_pagemap() to inspect the pfn because it > > could rely on the fact that the page already had an elevated reference > > count. The get_user_pages() path only looks up ZONE_DEVICE pfns when > > it see {pte,pmd,pud}_devmap set in the page table entry. pfn walkers > > have been a problem, but with pfn_to_online_page() fixed what is the > > remaining motivation to inspect ZONE_DEVICE pfns? > > 1) Let's assume we want to implement zone shrinking > (remove_pfn_range_from_zone()->shrink_zone_span()) for ZONE_DEVICE at > some point. I don't expect that will ever be something the kernel will want to do given the association of pgmap to the lifetime of a given device configuration. The mechanism to mutate a ZONE_DEVICE mapping is unbind device, reconfigure device, bind device to establish a new ZONE_DEVICE mapping. > > A simple approach would be going via get_dev_pagemap(pfn, > NULL)->pfn_to_page(pfn), checking for the zone. > > If that's not possible, then extending dev_pagemap (e.g., indicating the > nid) might also work (unless there is another way to get the nid). > > > 2) Let's take a look at mm/memory-failure.c:memory_failure_dev_pagemap() > > IIUC, we might end up doing pfn_to_page(pfn) on a pfn in the reserved > altmap space, so one with an uninitialized memmap. > > E.g., in dax_lock_page() we access page->mapping, which might just be > garbage. dax_mapping() will de-reference garbage. > > Most probably I am missing something here. No you're not, this is a real issue because get_dev_pagemap() is valid for the metadata space. I need to add a patch to validate get_dev_pagemap() vs the pfns that are data vs metadata. > > > > Question is: what are the expectations regarding the memmap if > get_dev_pagemap() succeeded. > > I'm fine documenting that "get_dev_pagemap() does not guarantee that the > "struct page" returned by pfn_to_page() was initialized and can safely > be used. E.g., it might be a pfn in the reserved altmap space, for which > the memmap is never initialized. Accessing it might be dangerous.". > > Then, there has to be a check at relevant places (e.g., > memory_failure_dev_pagemap()), checking somehow if the memmap content > can actually be used. Ok, let me audit and fix that up. Thanks David.