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 A3781C433FE for ; Fri, 18 Nov 2022 19:38:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5AD66B0071; Fri, 18 Nov 2022 14:38:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0AEF8E0001; Fri, 18 Nov 2022 14:38:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD3716B0074; Fri, 18 Nov 2022 14:38:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BF33F6B0071 for ; Fri, 18 Nov 2022 14:38:35 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8C551A097E for ; Fri, 18 Nov 2022 19:38:35 +0000 (UTC) X-FDA: 80147574990.25.C2D3351 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf10.hostedemail.com (Postfix) with ESMTP id 430EAC0007 for ; Fri, 18 Nov 2022 19:38:35 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so9194267pjs.4 for ; Fri, 18 Nov 2022 11:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/+N3RioXUarqC7xJNWj6sGt+lhXT+BVobkSLIF2p8S8=; b=OUh2XchRmBJ3GMpHVsKvYBsSMLxxudrMBdweGbmuv2/hV8XxP7VK5dvWRM4HXYVHHr TzQFyFZ7nvXf3OgPi+gQ1iNdaPI6Uo7R0HEl+bMc8Q0Oayui1kxufd2lLCVSaWVa0jXM vgKths76gkyFXQv5VW5WlaVn+HYQc+PigU/0R75qy6ZPpXaIwa8cVwE6WLfEXm1sa1LN b1GBW4fMJR8nSFjZ50oV59C3jcclL14LTjA4O2rIW7m7O3uyR1Ub4D3PkDpKmFKjD9rr M32eqRH8MFU3aiMH+dRkgqmYOdKX/+s/qoPTLBrnWRXwZIDHWqVENFOsB9NcAIx4b5dM yNog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/+N3RioXUarqC7xJNWj6sGt+lhXT+BVobkSLIF2p8S8=; b=LXxux/Tf+3ytMbxPepSlR1FdunzTI4Jmk5XRNppBhGuScOiRYaCPluUoAo4/AvdEoU rffCaIXTQ9fU7s5I3q8SIaGOlz7ZXDumsvDlM7CRUyhdTmRoZcFUZmOZeCUX0NNU63rO 2XNSCHRLah4wKO4W0SG7pFjkO92Uwy9hqCJyJdAaycwh23m7dPa2R0CNfYkp82QoYBD2 /lb4OEjPOcL4XzVb7aET6/9NxWtpqlGgUDKMJjl+20eoxAzTSuSj/DonhBYUgSwenvU9 QggviivHbPfx6C87IgfXY20jxR2/omipaLJu3XCLwpkYl8SKM6sHoNOLQ7gKtCVQwnSB rK0A== X-Gm-Message-State: ANoB5pnHj918jqHfhhgaToaEYZ4fc6KIxcXRck3mXQRp4dpoO4sHnzJa Hqf8+JitplmHjCNf5nZ3EE5ThG/rI2PXgl/RZTQ7JA== X-Google-Smtp-Source: AA0mqf5WNAp7jdoou2L2OcQfYoT0zYX0p+6wPQ87xhtM8vg/maw/6KN5+/xQYcyCHGlSNoDW6/IaS1bkOIL6tkPTZFc= X-Received: by 2002:a17:90a:6547:b0:213:d08f:a483 with SMTP id f7-20020a17090a654700b00213d08fa483mr9201401pjs.21.1668800313971; Fri, 18 Nov 2022 11:38:33 -0800 (PST) MIME-Version: 1.0 References: <20221118013157.1333622-1-jiaqiyan@google.com> <20221118013157.1333622-2-jiaqiyan@google.com> In-Reply-To: From: Jiaqi Yan Date: Fri, 18 Nov 2022 11:38:22 -0800 Message-ID: Subject: Re: [PATCH v7 1/2] mm/khugepaged: recover from poisoned anonymous memory To: "Luck, Tony" , "shy828301@gmail.com" Cc: "kirill.shutemov@linux.intel.com" , "kirill@shutemov.name" , "tongtiangen@huawei.com" , "akpm@linux-foundation.org" , "naoya.horiguchi@nec.com" , "linmiaohe@huawei.com" , "linux-mm@kvack.org" , "osalvador@suse.de" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668800315; a=rsa-sha256; cv=none; b=kwTJ/lk0LBTPzI8vCIDuixGWPlV+jVwMSYaQpIxQArFtbKR3XxzAaLu50o0MkHlwbn8+GV GoCfF4cGOqbT0ikOYKShzVHPZPphi0P5B0au10o5pn3/uMlOBmmdcnTeDjd1a8+BU30L/P esLneNKSQMl/8PAA4KhUDSCPunZErPg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OUh2XchR; spf=pass (imf10.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668800315; 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=/+N3RioXUarqC7xJNWj6sGt+lhXT+BVobkSLIF2p8S8=; b=38CnhLJBTBwjLtoiILrQ8H7nDa4Bf61bk3BvK2v1KVE2q6fAuANoEH3z6rMbkgaDlPWWge unKvn/A90EOmSggQnPmfc8U58wG4XQBb8ZPos2piN2ZnKSKVVwJWnyLO89tHfHY8RRPk3L iBrfbUEz9wn4MkznIz+iI0/TFbpzA10= X-Stat-Signature: dumncnommrmh6h3dhsjczoena55zc7s1 X-Rspamd-Queue-Id: 430EAC0007 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OUh2XchR; spf=pass (imf10.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1668800314-239450 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 Fri, Nov 18, 2022 at 8:46 AM Luck, Tony wrote: > > +/* > + * Machine check exception handled version of copy_highpage. > + * Return true if copying page content failed; otherwise false. > + * Note handling #MC requires arch opt-in. > + */ > +static inline bool copy_highpage_mc(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); > + kunmap_local(vto); > + kunmap_local(vfrom); > + > + return ret > 0; > +} > > Andrew Morton took my patches to recover from copy-on-write faults > into the -mm tree. They are now sitting in linux-next (hopefully) ready > for the next merge window. > > I had copied this function from an earlier version of your patch, but > there was a suggestion that copy_mc_user_highpage() would be a > more consistent name with other copy code that can handle machine > checks. There was also an upstream change to copy_highpage() > that needed to be reflected here. Thanks for pointing this out, Tony. Is it the kmsan_copy_page_meta(to, from) call in copy_highpage()? I will make sure to include it in copy_highpage_mc(). If there is more, can you provide lore pointers? > > Net result, this version is already in flight: > > static inline int copy_mc_user_highpage(struct page *to, struct page *from, > unsigned long vaddr, struct vm_area_struct *vma) > { > unsigned long ret; > char *vfrom, *vto; > > vfrom = kmap_local_page(from); > vto = kmap_local_page(to); > ret = copy_mc_to_kernel(vto, vfrom, PAGE_SIZE); > if (!ret) > kmsan_unpoison_memory(page_address(to), PAGE_SIZE); Does it make sense to kmsan_unpoison_memory in copy_highpage? (and in copy_mc_highpage if no MC happens?) > kunmap_local(vto); > kunmap_local(vfrom); > > return ret; > } > > -Tony While I am ok to switch to copy_mc_user_highpage for this commit (given __collapse_huge_page_copy originally uses copy_user_highpage), the question is, Yang Shi suggested in a previous version to unify the copy routine used by both __collapse_huge_page_copy (using copy_user_highpage) and collapse_file (using copy_highpage). I prefer MC-aware copy_highpage because collapse_file may have a hard time to adapt to the vaddr and vma in copy_user_highpage's interface, and neither collapse_file nor __collapse_huge_page_copy gain anything from passing vaddr and vma (correct me if I am wrong). So I would still prefer copy_mc_highpage (after renaming and adding kmsan_xxx calls) to be used by both __collapse_huge_page_copy and collapse_file. What are your opinions, Tony and Yang?