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=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 0E73EC433DF for ; Thu, 6 Aug 2020 17:15:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 37F8B23119 for ; Thu, 6 Aug 2020 17:15:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="cmrZQ8Yv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37F8B23119 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4F8A48D0001; Thu, 6 Aug 2020 13:15:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4810A6B0005; Thu, 6 Aug 2020 13:15:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 370E48D0001; Thu, 6 Aug 2020 13:15:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0214.hostedemail.com [216.40.44.214]) by kanga.kvack.org (Postfix) with ESMTP id 1A5476B0003 for ; Thu, 6 Aug 2020 13:15:14 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C7CFC181AEF09 for ; Thu, 6 Aug 2020 17:15:13 +0000 (UTC) X-FDA: 77120794506.04.sand38_4c0c7c226fb9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 7937A800EEAC for ; Thu, 6 Aug 2020 17:15:13 +0000 (UTC) X-HE-Tag: sand38_4c0c7c226fb9 X-Filterd-Recvd-Size: 5305 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Aug 2020 17:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XxaSeZ8vU13ipKwWzVxowozt5SCaySmLqUJlyGW8WBI=; b=cmrZQ8YvjWkEmDNcAnsrELEWBy +U/oGZ90fBu3UCq1CEVkLZ8pQXNZz/HX9XtdneThVBn8S+5rR7beEskioaQxUwouXGRCImpAbOLUg IvIh3MD/OTU10pRzBM2HG8ypZ0FianKgzTtevdllZhIe/BkaCEpQGY6KrlGv1SFM8eQsgsX0cZiaS 1Q9hwQk9NaT839uWgfXwv/Lg3ghYyYsi3b13RJyS+MbQwfglYT54wN9v2nrDnRc/isnCEwZK+V8KU 7jOeRrsVSiyYdxtkxFXhUgjpZL0UGtWy5iNixC/W4kW1o3tD98QhRnD3yUuh+tMvSOG8hE9Gi8aiP X5NTaawA==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3jTp-00050N-0D; Thu, 06 Aug 2020 17:15:01 +0000 Date: Thu, 6 Aug 2020 18:15:00 +0100 From: Matthew Wilcox To: Vlastimil Babka Cc: John Hubbard , Andrew Morton , LKML , linux-mm@kvack.org, cai@lca.pw, kirill@shutemov.name, rppt@linux.ibm.com, william.kucharski@oracle.com, "Kirill A . Shutemov" Subject: Re: [PATCH v2] mm, dump_page: do not crash with bad compound_mapcount() Message-ID: <20200806171500.GA17456@casper.infradead.org> References: <20200804214807.169256-1-jhubbard@nvidia.com> <20200806134851.GN23808@casper.infradead.org> <790ae9a4-6874-ac34-d2a2-28a2137335cb@suse.cz> <20200806153938.GO23808@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 7937A800EEAC X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Thu, Aug 06, 2020 at 05:53:10PM +0200, Vlastimil Babka wrote: > On 8/6/20 5:39 PM, Matthew Wilcox wrote: > >> >> +++ b/mm/huge_memory.c > >> >> @@ -2125,7 +2125,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, > >> >> * Set PG_double_map before dropping compound_mapcount to avoid > >> >> * false-negative page_mapped(). > >> >> */ > >> >> - if (compound_mapcount(page) > 1 && !TestSetPageDoubleMap(page)) { > >> >> + if (head_mapcount(page) > 1 && !TestSetPageDoubleMap(page)) { > >> > > >> > I'm a little nervous about this one. The page does actually come from > >> > pmd_page(), and today that's guaranteed to be a head page. But I'm > >> > not convinced that's going to still be true in twenty years. With the > >> > current THP patchset, I won't allocate pages larger than PMD order, but > >> > I can see there being interest in tracking pages in chunks larger than > >> > 2MB in the future. And then pmd_page() might well return a tail page. > >> > So it might be a good idea to not convert this one. > >> > >> Hmm the function converts the compound mapcount of the whole page to a > >> HPAGE_PMD_NR of base pages. If suddenly the compound page was bigger than a pmd, > >> then I guess this wouldn't work properly anymore without changes anyway? > >> Maybe we could stick something like VM_BUG_ON(PageTransHuge(page)) there as > >> "enforced documentation" for now? > > > > I think it would work as-is. But also I may have totally misunderstood it. > > I'll write this declaratively and specifically for x86 (PMD order is 9) > > ... tell me when I've made a mistake ;-) > > > > This function is for splitting the PMD. We're leaving the underlying > > page intact and just changing the page table. So if, say, we have an > > underlying 4MB page (and maybe the pages are mapped as PMDs in this > > process), we might get subpage number 512 of this order-10 page. We'd > > need to check the DoubleMap bit on subpage 1, and the compound_mapcount > > also stored in page 1, but we'd only want to spread the mapcount out > > over the 512 subpages from 512-1023; we wouldn't want to spread it out > > over 0-511 because they aren't affected by this particular PMD. > > Yeah, and then we decrease the compound mapcount, which is a counter of "how > many times is this compound page mapped as a whole". But we only removed (the > second) half of the compound mapping, so imho that would be wrong? I'd expect that count to be incremented by 1 for each PMD that it's mapped to? ie change the definition of that counter slightly. > > Having to reason about stuff like this is why I limited the THP code to > > stop at PMD order ... I don't want to make my life even more complicated > > than I have to! > > Kirill might correct me but I'd expect the THP code right now has baked in many > assumptions about THP pages being exactly HPAGE_PMD_ORDER large? There are somewhat fewer places that make that assumption after applying the ~80 patches here ... http://git.infradead.org/users/willy/pagecache.git I have mostly not touched the anonymous THPs (obviously some of the code paths are shared), although both Kirill & I think there's a win to be had there too.