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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 3CFF3C47088 for ; Wed, 26 May 2021 23:04:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9BE72613D2 for ; Wed, 26 May 2021 23:04:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BE72613D2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A97F46B0036; Wed, 26 May 2021 19:04:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2D1D6B006E; Wed, 26 May 2021 19:04:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 574E66B0070; Wed, 26 May 2021 19:04:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 112146B0036 for ; Wed, 26 May 2021 19:04:50 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9429C9894 for ; Wed, 26 May 2021 23:04:49 +0000 (UTC) X-FDA: 78184913898.17.CA1B466 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf04.hostedemail.com (Postfix) with ESMTP id 51AF62C6 for ; Wed, 26 May 2021 23:04:45 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id j10so3449057edw.8 for ; Wed, 26 May 2021 16:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e+lq37qKI+oQQ5eC5isuuDqSVssXilsmmXniH/3lcLs=; b=eaEJLD5bQsXCevDFBPPEnuiFou+49aKNsH0ZbRKcr2bR0NqvWfBHY1PjuLfxTSocS/ gksxymAUiWfbiBFS488NwzQQSKHIwBI1RXQoe+adIhTR0L3IeSTdJhnsDhluqdE2inqs H+IfwOmNn2IhlxMr1orI99pwIsT2vJut7d8csja+RLENcRW5YTG7RSmnQVZAXo5j6YEF 8F+0BhoFQDE4L+5vP26aUIXC62tn3I5TFj8xqvVttW4bqfFPBsOzhzb2ZpuxBWczjGSM inY3EvFLtT9aS4YDyRXljPPQ6NznoBITX+TTISpWj/Z/bAak/DSKptpnmctMsTdGkxlO SZUw== 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=e+lq37qKI+oQQ5eC5isuuDqSVssXilsmmXniH/3lcLs=; b=mpX/UXzx7tYQJoPIT/9xlUpuRofcVzqacz5LFTtuOPRWw4bLqiY0keI59hzjPRYvDp yhzpHRp0XpRW/VXtXAohIHJAwmkWHnvnMcPpf9I3dblWSO571vvl3otg8uFKY2J69QLl 24B3LNz9c/9X2kinwDasezX49x2MswVdm6Pjrl6PT5MSR4gYO90X02aB6QRBdT9EImjO mxIlw2H1lsBwhXDCXHJ3j+g08eP5pT/RPgdXjUo16MUrLKAPb8cgF8+kUdIMs4ll3DRR nl8+E38dEQKb6kJ4EW38PLnl5tK1UuTQs9Omqsqw1FeoMwjZVfHgSzPFs1tMSEOq1vzg vSJw== X-Gm-Message-State: AOAM5332gSQ1fbWFWHHI/QHrtO1PvnTwZliQkVHNYYqoQ84mnZXz8ssf D6tCX/Rwakl+eOFexGg+uR+UtbX3ctSP98fBnp4= X-Google-Smtp-Source: ABdhPJwnRXvFEAhe5YRIU84nIhbncr+t37M/f5KMWgLCq4a6Vq1J0OaktVtCR4gfCWapDA9knvi/DqbG7UuTCY68XG8= X-Received: by 2002:a05:6402:51ce:: with SMTP id r14mr629192edd.151.1622070287905; Wed, 26 May 2021 16:04:47 -0700 (PDT) MIME-Version: 1.0 References: <20210525162145.3510-1-shy828301@gmail.com> <20210525162145.3510-2-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Wed, 26 May 2021 16:04:35 -0700 Message-ID: Subject: Re: [v3 PATCH 2/2] mm: thp: check page_mapped instead of page_mapcount for split To: Hugh Dickins Cc: Zi Yan , "Kirill A. Shutemov" , =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= , Wang Yugui , Andrew Morton , Linux MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 51AF62C6 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=eaEJLD5b; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Stat-Signature: ssui5zjxq59bnm5iyeaea13xd8sjw6d3 X-HE-Tag: 1622070285-106869 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 Wed, May 26, 2021 at 3:48 PM Hugh Dickins wrote: > > On Wed, 26 May 2021, Yang Shi wrote: > > On Tue, May 25, 2021 at 4:58 PM Hugh Dickins wrote: > > > On Tue, 25 May 2021, Yang Shi wrote: > > > > > > > > We should be able to make dump_page() print total mapcount, right? The > > > > dump_page() should be just called in some error paths so taking some > > > > extra overhead to dump more information seems harmless, or am I > > > > missing something? Of course, this can be done in a separate patch. > > > > > > I didn't want to ask that of you, but yes, if you're willing to add > > > total_mapcount() into dump_page(), I think that would be ideal; and > > > could be helpful for other cases too. > > > > > > Looking through total_mapcount(), I think it's safe to call from > > > dump_page() - I always worry about extending crash info with > > > something that depends on a maybe-corrupted pointer which would > > > generate a further crash and either recurse or truncate the output - > > > but please check that carefully. > > > > Yes, it is possible. If the THP is being split, some VM_BUG_* might be > > triggered if total_mapcount() is called. But it is still feasible to > > print total mapcount as long as we implement a more robust version for > > dump_page(). > > Oh dear. I think the very last thing the kernel needs is yet another > subtly different variant of *mapcount*(). > > Do you have a specific VM_BUG_* in mind there? Of course there's > the VM_BUG_ON_PAGE(PageTail) at the start of it, and you'd want to > print total_mapcount(head) to avoid that one. There are two more places in total_mapcount() other than the tail page assertion. #1. compound_mapcount() has !PageCompound assertion. The similar problem has been met before, please refer to commit 6dc5ea16c86f ("mm, dump_page: do not crash with bad compound_mapcount()"). #2. PageDoubleMap has !PageHead assertion. > > Looks like __dump_page() is already careful about "head", checking > whether "page" is within the expected bounds. Of course, once we're > in serious VM_WARN territory, there might be races which could flip > fields midway: PageTail set by the time it reaches total_mapcount()? It seems possible, at least theoretically. > Narrow the race (rather like it does with PageSlab) by testing > PageTail immediately before calling total_mapcount(head)? TBH I don't think of a simple testing to narrow all the races. We have to add multiple testing in total_mapcount(), it seems too hacky. Another variant like below might be neater? +static inline int __total_mapcount(struct page *head) +{ + int i, compound, nr, ret; + + compound = head_compound_mapcount(head); + nr = compound_nr(head); + if (PageHuge(head)) + return compound; + ret = compound; + for (i = 0; i < nr; i++) + ret += atomic_read(&head[i]._mapcount) + 1; + /* File pages has compound_mapcount included in _mapcount */ + if (!PageAnon(head)) + return ret - compound * nr; + if (head[1].flags & PG_double_map) + ret -= nr; + return ret; +} > > Hugh