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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67B59C433EF for ; Mon, 18 Apr 2022 16:20:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C53A28D0015; Mon, 18 Apr 2022 12:20:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C024D8D0013; Mon, 18 Apr 2022 12:20:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACABC8D0015; Mon, 18 Apr 2022 12:20:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 9CF638D0013 for ; Mon, 18 Apr 2022 12:20:37 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4FB7923EF0 for ; Mon, 18 Apr 2022 16:20:37 +0000 (UTC) X-FDA: 79370512914.07.B7E837F Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf05.hostedemail.com (Postfix) with ESMTP id B688E100013 for ; Mon, 18 Apr 2022 16:20:36 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id b24so17965809edu.10 for ; Mon, 18 Apr 2022 09:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=elXW57Be0NdrpWiKMwVjW4SkRo4i694VaiaG7hyVIl4=; b=I0gFisojySowdcruWqGrwv8BEBkRmS4cmTZOEktl76aTgGdz1Nvl4BWn+e4yiG8QxA AkrmCqQ+9yEP363iPZPxqEU2/5PYVnsO7dIvJeHnqiyNl9lfnMuRXQTHC7MuIfZxZ65A 2fo9zNDfacFqj6oz8puRJQovNkbmcZXqFCuRzsMZ70n2vYjKgaQjORRZhN/Oy3QeTq0u axyz0GDFlrcg6Q2eumKwrZQUU0loxqHUTlmbtEkVgzpYKhT4ovadVfpA3aDFP5RBgT4B O6EId24/SI1DhfxysdXMuZWEWbsSkY0HyzaBiN/c0q2GYqZ/aN2kckrpjbrLpbvU7pXw WwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=elXW57Be0NdrpWiKMwVjW4SkRo4i694VaiaG7hyVIl4=; b=j+IxTVamwzO5+aBEHD8qXaGIS5tbrMtD2DO6xnyPACX4YOssnOcyHbCOxPFLwFJ+VR F5jEgllSf+oI+mfADnPbfVh3kepxHm0+CCVk8UDFgn4K0cJwtDQBKBHd9KvwruIP+gFI LeUIMF5/tL4fxz2YVIFhsslApHEEoqlIVJRoFWFh4nz2udkShRwAJx/9n3gmO3QH2c+j 0lZp6Yl0Z3ETNTMEcltZkaME201RhM+gR9G8pHAXySVChIAJY/7YkZHG/m5ZheBMQIDs PR90HfKZVKkBcHMojBcJ4qZCzmY3+kbWfEYFwoFTvrTc9VX7Of2sty5MSF/hFM3edIUV Xw4g== X-Gm-Message-State: AOAM530ZyiYMFoAa27sNqmqb8+nBkOdI+h0ihkAq03Tr+Wzr6lTcAjQ2 56t06RkpimXHBgEVijtdNCNdtJor6hCgre6PvL51Tw== X-Google-Smtp-Source: ABdhPJxr95S4Cz+dDACB9t3Y9pcQwabk5POhmJfmkYXWHP61HT1QjLu3qRzgMKRSijX9TJ6kp8g9crf/e2B28GnN1os= X-Received: by 2002:a05:6402:644:b0:41d:77bb:d36d with SMTP id u4-20020a056402064400b0041d77bbd36dmr12575830edx.381.1650298835312; Mon, 18 Apr 2022 09:20:35 -0700 (PDT) MIME-Version: 1.0 References: <20220418034444.520928-1-tongtiangen@huawei.com> <20220418034444.520928-4-tongtiangen@huawei.com> <1c314feb-cd78-2bb3-462e-4ea3cefe122e@arm.com> In-Reply-To: From: Pasha Tatashin Date: Mon, 18 Apr 2022 12:20:00 -0400 Message-ID: Subject: Re: [PATCH -next v4 3/4] arm64: mm: add support for page table check To: Tong Tiangen Cc: Anshuman Khandual , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Andrew Morton , Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , LKML , linux-mm , Linux ARM , linux-riscv@lists.infradead.org, Kefeng Wang , Guohanjun Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B688E100013 X-Stat-Signature: 6nw9bofy6k6gu1x6jij5esufd1mp75xk Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=I0gFisoj; spf=pass (imf05.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-Rspam-User: X-HE-Tag: 1650298836-179264 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 Mon, Apr 18, 2022 at 11:47 AM Tong Tiangen wrot= e: > > > > =E5=9C=A8 2022/4/18 17:28, Anshuman Khandual =E5=86=99=E9=81=93: > > On 4/18/22 09:14, Tong Tiangen wrote: > >> From: Kefeng Wang > >> > [...] > >> #endif > > > > Ran this series on arm64 platform after enabling > > > > - CONFIG_PAGE_TABLE_CHECK > > - CONFIG_PAGE_TABLE_CHECK_ENFORCED (avoiding kernel command line option= ) > > > > After some time, the following error came up > > > > [ 23.266013] ------------[ cut here ]------------ > > [ 23.266807] kernel BUG at mm/page_table_check.c:90! > > [ 23.267609] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > > [ 23.268503] Modules linked in: > > [ 23.269012] CPU: 1 PID: 30 Comm: khugepaged Not tainted 5.18.0-rc3-0= 0004-g60aa8e363a91 #2 > > [ 23.270383] Hardware name: linux,dummy-virt (DT) > > [ 23.271210] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BT= YPE=3D--) > > [ 23.272445] pc : page_table_check_clear.isra.6+0x114/0x148 > > [ 23.273429] lr : page_table_check_clear.isra.6+0x64/0x148 > > [ 23.274395] sp : ffff80000afb3ca0 > > [ 23.274994] x29: ffff80000afb3ca0 x28: fffffc00022558e8 x27: ffff800= 00a27f628 > > [ 23.276260] x26: ffff800009f9f2b0 x25: ffff00008a8d5000 x24: ffff800= 009f09fa0 > > [ 23.277527] x23: 0000ffff89e00000 x22: ffff800009f09fb8 x21: ffff000= 089414cc0 > > [ 23.278798] x20: 0000000000000200 x19: fffffc00022a0000 x18: 0000000= 000000001 > > [ 23.280066] x17: 0000000000000001 x16: 0000000000000000 x15: 0000000= 000000003 > > [ 23.281331] x14: 0000000000000068 x13: 00000000000000c0 x12: 0000000= 000000010 > > [ 23.282602] x11: fffffc0002320008 x10: fffffc0002320000 x9 : ffff800= 009fa1000 > > [ 23.283868] x8 : 00000000ffffffff x7 : 0000000000000001 x6 : ffff800= 009fa1f08 > > [ 23.285135] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000= 000000000 > > [ 23.286406] x2 : 00000000ffffffff x1 : ffff000080f2800c x0 : ffff000= 080f28000 > > [ 23.287673] Call trace: > > [ 23.288123] page_table_check_clear.isra.6+0x114/0x148 > > [ 23.289043] __page_table_check_pmd_clear+0x3c/0x50 > > [ 23.289918] pmdp_collapse_flush+0x114/0x370 > > [ 23.290692] khugepaged+0x1170/0x19e0 > > [ 23.291356] kthread+0x110/0x120 > > [ 23.291945] ret_from_fork+0x10/0x20 > > [ 23.292596] Code: 91001041 b8e80024 51000482 36fffd62 (d4210000) > > [ 23.293678] ---[ end trace 0000000000000000 ]--- > > [ 23.294511] note: khugepaged[30] exited with preempt_count 2 > > > > Looking into file mm/page_table_check.c where this problem occured. > > > > /* > > * An enty is removed from the page table, decrement the counters for = that page > > * verify that it is of correct type and counters do not become negati= ve. > > */ > > static void page_table_check_clear(struct mm_struct *mm, unsigned long = addr, > > unsigned long pfn, unsigned long pg= cnt) > > { > > struct page_ext *page_ext; > > struct page *page; > > unsigned long i; > > bool anon; > > > > if (!pfn_valid(pfn)) > > return; > > > > page =3D pfn_to_page(pfn); > > page_ext =3D lookup_page_ext(page); > > anon =3D PageAnon(page); > > > > for (i =3D 0; i < pgcnt; i++) { > > struct page_table_check *ptc =3D get_page_table_check(= page_ext); > > > > if (anon) { > > BUG_ON(atomic_read(&ptc->file_map_count)); > > BUG_ON(atomic_dec_return(&ptc->anon_map_count)= < 0); > > } else { > > BUG_ON(atomic_read(&ptc->anon_map_count)); > > Triggered here =3D=3D=3D=3D>> BUG_ON(atomic_dec_return(&ptc->file_ma= p_count) < 0); > > } > > page_ext =3D page_ext_next(page_ext); > > } > > } > > > > Could you explain what was expected during pmdp_collapse_flush() which = when > > failed, triggered this BUG_ON() ? This counter seems to be page table c= heck > > specific, could it just go wrong ? I have not looked into the details a= bout > > page table check mechanism. > > > > - Anshuman > > . > > Hi Anshuman: > > Thanks for your job. > > Let me briefly explain the principle of page table check(PTC). > > PTC introduces the following struct for page mapping type count: > struct page_table_check { > atomic_t anon_map_count; > atomic_t file_map_count; > }; > This structure can be obtained by "lookup_page_ext(page)" > > When page table entries are set(pud/pmd/pte), page_table_check_set() is > called to increase the page mapping count, Also check for errors (eg:if > a page is used for anonymous mapping, then the page cannot be used for > file mapping at the same time). > > When page table entries are clear(pud/pmd/pte), page_table_check_clear() > is called to decrease the page mapping count, Also check for errors. > > The error check rules are described in the following documents: > Documentation/vm/page_table_check.rst > > The setting and clearing of page table entries are symmetrical. > > Here __page_table_check_pmd_clear() trigger BUGON which indicates that > the pmd entry file mapping count has become negative. > > I guess if PTC didn't detect this exception, would there have been any > problems? It is hard to tell what sort of problem has been detected. More debugging is needed in order to understand it. A huge file entry is being removed from the page table. However, at least one sub page of that entry does not have a record that it was added as a file entry to the page table. At Google we found a few internal security bugs using PTCs. However, this being new on ARM64, it is possible that the bug is in PTC/khugepaged itself. Anshuman is it possible to repro your scenario in QEMU? Thank you, Pasha > > Thanks, > Tong.