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 A965DC636D3 for ; Thu, 2 Feb 2023 00:01:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16E4E6B0073; Wed, 1 Feb 2023 19:01:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 11E846B0075; Wed, 1 Feb 2023 19:01:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00CAE6B0078; Wed, 1 Feb 2023 19:01:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E27D86B0073 for ; Wed, 1 Feb 2023 19:01:12 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7B7DC1A07DF for ; Thu, 2 Feb 2023 00:01:12 +0000 (UTC) X-FDA: 80420396784.14.3894CF7 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf15.hostedemail.com (Postfix) with ESMTP id CFF81A0027 for ; Thu, 2 Feb 2023 00:01:09 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZUwVN8S4; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675296070; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PYwRu1DyQrjfO0oEPJkIQ7fkAKm0QDnt+N2E7C1thi0=; b=OuyUZFcTYnOfBquVjGXGBRM5lMIjedYdZzO7jMl7WTXOok4OANLddzgm/255iv2idX8Qoz WYVaWMpccIFM7P21arAroENO4T6ok/hD0rgCxXul3iE8Ln0HJ0z5dROpbwrgkt31IEfrOm 1Rxe6rQDxPEKu7UJ0vbta7eRMveCWmY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZUwVN8S4; spf=none (imf15.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675296070; a=rsa-sha256; cv=none; b=1TrI5DT3OaLCNqyOBiB1eZVv2WQbJNLNdQRYH5+752mUd5Km4zuGiTiJlnnEyPjSBrsTse 1lLaJ9rsm1ElK0CacxQPLpSlZuOc9Lt9WOfDptF0itA6PPElXGw4I/ZDQhe/zJ3pHItr44 pDtpFkv8vjjZ7EkV2OMByLYk6YQ7Yb4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675296069; x=1706832069; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=gmFeKrKSoY/LPcZ4pi6YpIOowy62XaMmzsn99jTcbgc=; b=ZUwVN8S4nUfqmK6IFmCPji1ugZ9bHvHdAkefjiTy7qs4eEMRa6qOqp/u F55l5fTelyDHss3vR86MfF9NhECbm/hBnzmaYnj/3sWiK0vVx15k59QFa iAOeCN8UTlHB4ofo0KRiaexE3WoTUyDRPQInVsggnBEZv4bx4FZgY44NG b3UfFK+ITaTMD+d1tcb/tZEFrfIChX2Tc7XPc0BqLU8f+wmHJeSn+VR1g 8kfNSjhsaL5iV7X3edHjsnjI07tyBxLcjXJ9yIkG3IGY6SN3pCdaAryJE rCa/1MVB4zyWIGcA0TodR0FL3dB09h8oKynaGyUcX0Hxs7L1LI8Dq37kt g==; X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="326007246" X-IronPort-AV: E=Sophos;i="5.97,265,1669104000"; d="scan'208";a="326007246" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2023 16:01:07 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10608"; a="910502148" X-IronPort-AV: E=Sophos;i="5.97,265,1669104000"; d="scan'208";a="910502148" Received: from wlwpo-3.amr.corp.intel.com (HELO box.shutemov.name) ([10.249.34.185]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2023 16:01:04 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id 3F6CE10E381; Thu, 2 Feb 2023 03:01:02 +0300 (+03) Date: Thu, 2 Feb 2023 03:01:02 +0300 From: kirill.shutemov@linux.intel.com To: Jiaqi Yan Cc: kirill@shutemov.name, shy828301@gmail.com, tongtiangen@huawei.com, tony.luck@intel.com, akpm@linux-foundation.org, wangkefeng.wang@huawei.com, naoya.horiguchi@nec.com, linmiaohe@huawei.com, linux-mm@kvack.org, osalvador@suse.de Subject: Re: [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory Message-ID: <20230202000102.mqgyquncvqe6wkno@box.shutemov.name> References: <20221205234059.42971-1-jiaqiyan@google.com> <20221205234059.42971-2-jiaqiyan@google.com> <20230119150258.npfadnefkpny5fd3@box.shutemov.name> <20230124003349.m64heg7mnqw7snyh@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: q1y8q176d7tenxitokwo5pgacm1b7c76 X-Rspamd-Queue-Id: CFF81A0027 X-HE-Tag: 1675296069-438379 X-HE-Meta: U2FsdGVkX1+4JYTy9HOFWvkR7H/Th2r3eg0KB/2bSwf2fzf4ChPLM4h7dGVXJYhnXxsea4AiUrgZkumhl7FONpdZPDvxtFqbPHjqz30/CNJNLsnPV79ttMwjgJAXX024me6RmeMjS8xlUCseG/To+oHCJFGI2rhB+1LSR7LKJa+D3icnawhHV/UY/EYAY9sagOzqC/kK3tpalNY+PVc01xLRCH5dV3JySYzAlB2a3IzsDtJbXugDIt88/y14ybB7l7A/G9ym1fdZp6jJccS1fB7dgB/8E3F99N9pZ1I7lGkmK4/BWavq+n3CpZDev0GCn/SUtgsaLr5Z38srpesRF1f2Mpkt6PVRUnVGbGNljxMmv4uThJyQ3x9Pw4ee1mYf6bOaVH1gqjCMVb7+ksZVS3nYdFaO30DX9bG/AVPh4/9vrYgGafBbUHF/sK8lIldqXZzac4iYgbdkokcrk+uFQYruDmnFtSQCC8zFkVeUIc0t00wyo1JY3v87Q8bfxS4dyS6RydjsEbl4JYL6x3OazsB/7dB92rPVgLnXJjle9dMJPeMKRHDixYk141d22oJxW6x3Zo1dDsAHAB6wAGbjgpPvIixFn8sjjOYjboJPyiZHH6t9Zq1Y6DwrQEj2dt1aVB0IdobL1zSu/Dspb/OrAdco4ny9NuRF9LtXa2PlD2bajv5BKdbu1m4r5IFZC9TIyLo2B8A3QXFHsrAiSVS+KOghF9x9k18NJWghSGwy7gyJoBwM8t9cVy+toFapguZywUSaopO6k1ZTQdelO9uxL5DPm+iOWZyaLI8mI04mYM0CfcWnkXcB0fEu6bHwwHcMbjrqUly9YKh1dqjXn/BA9Vhk5g9g0NkuJXUpfDLb63usTihFQXJGVdlNPBrSTyELJIV3MC687OhTT1KB+OoRfk/L7rH2h5Js2e0+Bw7xxonKxoozmdC2n3NFDCtj5SjJFkBY/g6Xk+q5+HkIyaL 0P6KAWBD zwSc6F5sTu30/LB/v7ebblQjXfBdJTcgufkePO+v/c+hNz7M9HXX0fI6czDo+7l3/12y0xG8SSVNLSDJmVaUxvuOGz5h7qUmeC5Egm51RjdhZ0brmvuGfe0eJr8lvCqTycfc4 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 31, 2023 at 09:16:45PM -0800, Jiaqi Yan wrote: > > > > > +/* > > > > > + * Copies memory with #MC in source page (@from) handled. Returns number > > > > > + * of bytes not copied if there was an exception; otherwise 0 for success. > > > > > + * Note handling #MC requires arch opt-in. > > > > > + */ > > > > > +static int copy_mc_page(struct page *to, struct page *from) > > > > > +{ > > > > > + char *vfrom, *vto; > > > > > + unsigned long ret; > > > > > + > > > > > + vfrom = kmap_local_page(from); > > > > > + vto = kmap_local_page(to); > > > > > + ret = copy_mc_to_kernel(vto, vfrom, PAGE_SIZE); > > > > > + if (ret == 0) > > > > > + kmsan_copy_page_meta(to, from); > > > > > + kunmap_local(vto); > > > > > + kunmap_local(vfrom); > > > > > + > > > > > + return ret; > > > > > +} > > > > > > > > > > > > It is very similar to copy_mc_user_highpage(), but uses > > > > kmsan_copy_page_meta() instead of kmsan_unpoison_memory(). > > > > > > > > Could you explain the difference? I don't quite get it. > > > > > > copy_mc_page is actually the MC version of copy_highpage, which uses > > > kmsan_copy_page_meta instead of kmsan_unpoison_memory. > > > > > > My understanding is kmsan_copy_page_meta covers kmsan_unpoison_memory. > > > When there is no metadata (kmsan_shadow or kmsan_origin), both > > > kmsan_copy_page_meta and kmsan_unpoison_memory just do > > > kmsan_internal_unpoison_memory to mark the memory range as > > > initialized; when there is metadata in src page, kmsan_copy_page_meta > > > will copy whatever metadata in src to dst. So I think > > > kmsan_copy_page_meta is the right thing to do. > > > > Should we fix copy_mc_user_highpage() then? > > I think it depends on what copy_user_highpage() (the original of > copy_mc_user_highpage) is used for. copy_mc_user_highpage is currently > only used by __wp_page_copy_user, is it possible that here we don't > want to (or don't need to) copy page metadata for userspace pages? Tony, could chime in on this? Can we modify copy_mc_user_highpage() to also use kmsan_copy_page_meta()? I don't really understand KMSAN here. > > > > > > > Indentation levels get out of control. Maybe some code restructuring is > > > > required? > > > > > > v10 will change to something like this to reduce 1 level of indentation: > > > > > > if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) > > > continue; > > > src_page = pte_page(pteval); > > > if (!PageCompound(src_page)) > > > release_pte_page(src_page); > > > > I hoped for deeper rework. Maybe split the function into several functions > > and make overall structure more readable? > > How about turning the 2nd loop into > __collapse_huge_page_copy_succeeded and > __collapse_huge_page_copy_failed, one for the case copy succeeded, and > one for failed? Like this: > if (likely(result == SCAN_SUCCEED)) > __collapse_huge_page_copy_succeeded(...); > else > __collapse_huge_page_copy_failed(...); > > My prototype shows it could reduce the level indents. Give it a try and try to get into reader shoes. Get it easily digestible for someone who reads the code for the first time. -- Kiryl Shutsemau / Kirill A. Shutemov