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 58160C7EE2D for ; Fri, 3 Mar 2023 17:16:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4BA36B0072; Fri, 3 Mar 2023 12:16:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFB596B0073; Fri, 3 Mar 2023 12:16:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC4C46B0075; Fri, 3 Mar 2023 12:16:01 -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 BEC516B0072 for ; Fri, 3 Mar 2023 12:16:01 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 66F52C0BED for ; Fri, 3 Mar 2023 17:16:01 +0000 (UTC) X-FDA: 80528239722.26.7B35C95 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf17.hostedemail.com (Postfix) with ESMTP id 87CE840022 for ; Fri, 3 Mar 2023 17:15:59 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=CH6ejB4k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677863759; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XlzvzITR1Gi/9xdM39mhIrHRjfnIX7DfMem42A96GiM=; b=sEf5VJ58UkCRyIfuNOtEsUMmhgzIrzKiL8/VL2UnWZOe1YbZFfutCqIsnDIodCnOgKin+3 w1y4NPCnmlu6YRyPrFlE8dgQLGIng8fvks7LhPBFgZToRuEkOIlxpeLl+0kdAxzddAOVe8 y6g5DKRjgd+fZmvsPCH7Pk79P/d7EWY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=CH6ejB4k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677863759; a=rsa-sha256; cv=none; b=qhgdkn08A9damcixtW6NoInT64aCPIHxZj45H9UzxPTxmbO731aFmDr6QLK0JswsnfFEa1 IXRel4+EyKofwztOnNdyf2389NIFT5+KjAK0qdZcT9vtiInZs0n9YGSKlu3P8YOLBCT6qI 8z594y5JIP6qbyrtLDujVia4SGCZM3c= Received: by mail-pl1-f170.google.com with SMTP id z2so3333948plf.12 for ; Fri, 03 Mar 2023 09:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677863758; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XlzvzITR1Gi/9xdM39mhIrHRjfnIX7DfMem42A96GiM=; b=CH6ejB4kGxQ6FMwekGuq8gb3BHYS2c+iyMDbDZ8rlAibZY5RzCePfftftGS5eWGchQ R5k1fhyHeBcGuXVIM22g4aVLA3QnZymHH4NJtZESRedXjKSkCetgjlq83KRU0aaih8w5 1br6kuZb/FLqPz4pTHIuBBgRzY2uiYWAAE+QxDWe/CUzfUfpUIuuIB6LqgXm2chSIFFQ /DRA8+eDiFudJnY4L/ieR6oLTWFRyDxllx65eZA9xo7XraRGvyfbS7OVNrK7o3xhmP2u 6YiQo4NgX8Tnn2J8eUuS5eRhA/krvJ45/Yqj+/tvw+sLBvhZd83sZxUhnRgH6mjwEFet AFSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677863758; h=content-transfer-encoding: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=XlzvzITR1Gi/9xdM39mhIrHRjfnIX7DfMem42A96GiM=; b=3EZ/EKcAK1QcoNwtjzzZc5O9OWM1K8fkSPknz/m+6hTRigT17aDPiFrnqoqST00VMz ehui/w7/Ar8q0ZoaQQY60fn3sFvOqCdRH6qJ+OW2ew66kyFySNayktkeTZwZPGVVnMVK I1IglodpEZ7+6c6XGHdrbBFUCu6vERJ9XiNcckkB8jVTjAtZIaLp/C/rqdgPKNGKg/xk ypFqcxZddHK+3QFhrpqZmUZ4MM8/5crHHHndIOkQvU7oRyLAHDkdx/MdbhxqQKEHWlUL 7SM9E/dnMWy4pn7nUJyb5UJ3+YPsSiKe2IaivQgtBbwc0IpZm0CX9CtWreUmTop6O7mY xeoQ== X-Gm-Message-State: AO0yUKWz0ZA4+yW8vbgN1NMtX8I6bXA9zmSv/gRCHCbya6gQHOvOKVDy eRsMk31kgcMUgnQ3plXG6VA88zpa3rjC5a43U5/A/A== X-Google-Smtp-Source: AK7set/XojGpR5vrc7ZXSgzTVkDJLY2epxOFRrHTPmlTc/OdJWcvuHuzZUo9VAOwugDsJlk2sjPoEDD2DagS3+O7e00= X-Received: by 2002:a17:902:7142:b0:199:7d2:d9da with SMTP id u2-20020a170902714200b0019907d2d9damr958705plm.11.1677863758101; Fri, 03 Mar 2023 09:15:58 -0800 (PST) MIME-Version: 1.0 References: <20221205234059.42971-2-jiaqiyan@google.com> <20230119150258.npfadnefkpny5fd3@box.shutemov.name> <20230124003349.m64heg7mnqw7snyh@box.shutemov.name> <20230202000102.mqgyquncvqe6wkno@box.shutemov.name> <20230202003034.cgtsz2mixfcige3p@box.shutemov.name> <20230228134009.5h5qhpopkhpp23bt@box.shutemov.name> In-Reply-To: <20230228134009.5h5qhpopkhpp23bt@box.shutemov.name> From: Jiaqi Yan Date: Fri, 3 Mar 2023 09:15:47 -0800 Message-ID: Subject: Re: [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory To: kirill@shutemov.name Cc: Alexander Potapenko , elver@google.com, dvyukov@google.com, kirill.shutemov@linux.intel.com, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 87CE840022 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 37od7uj8xow4jexsjgj9dddmjb5ngpq8 X-HE-Tag: 1677863759-999010 X-HE-Meta: U2FsdGVkX180n9qSIKylZBDE7rpfkWF1pRkuH6nBNx0W2vF0n5vAMAlgHylZCLTK0eqjatX0rOqhOdSWz7IEXnQFohV3xEm2HvEgFzgfQYL8ICbly6ydXOZeQ3k0nYx7lWg5uuT7WHdZVWWGf1cG8fTDQd/Q/d6gp/BQyfF+uzSLfrQkVbSjYTxFQI2w1yfI7FOvonJvuICVq5S59QougOO8ziGVXeBg7MJ9B7ayX/LDpyHZyB2gwvLE0IkwPZ6Sx7oehcteEJy3AUq8Fwb6ydfoCBhEsZWULJVVuEYL87Ioni2myP0XHbyUAVEtJahgI5LwQ5/S6rOa0kzoiNc3UY1aMGEe2dRkS2O06iL5M0xfn6ulXkg/fjx/iz9LpMS/P0U5dOU5xuLYGLYpK0mrEu+FBr4D7Z7TYIZ5Xh60xGUmuGZSrIUXLUqsR6IAh5Zyf9cBYa6IeKG9y0JfNlgOTpNJxi5WI3LhLq7Li2ANmOzvh2UY8Z0z5KiVJBb53Vi6UVkt6ViSVp/nwRz2eTxK4TDw29Xclr5avk3G4lFhaMBqOdnzRStYujB+byC9eTQY7XInVfr53ZVk798d/3EkeC7+SbmX3tM7xUY8fMW57QpKlTMs2ednGK0KAlerQdUl0kNvvtucvAbvOHUMGhpJFYAQvubGGbp4ot1OPu2fUpYpnXx7ddqUwvBb93fLZhBsBH9QMtrIGTdFheu7lAsvE5AhTAZynuzu4p1qwYrRoBOnNUMChQudv7vPtX+tEfTLRiaiOdmnF5dcqhTmDsXuQ6aeyKnYgxS94KXjSzI4tEMRrsHvhNZDirMv1bn+a+RvptukGqZDKtP1BrmvbpolQ6C93RMuJluDdDA8wSXK15UARXZRFNRM8+GggJYgBiKgfNX/6XOkrNx9auBZ83BOkA+J+sU97oikl1nLIuAASfGDx4HrigsG0TnN4NyXB2srhkvWrcJGMRDM9jmfAAr u921sYC3 qJizVjSipDwZ7eVQlgAAp/CFEbSJIhqWjN18s0M50h5tWXEYMhHm+Hop3OL9b//ER+sC8tQ+mDvUgk85qC5Fd0A6nYV+2w5KGlqX7arhu/2UwMdntYdBMkE8DUMW054QQTpi1BX5OWnwxI0OWA6jFBY6i4T/tfeB1v062DMsu7fspDra0jYUTIDCqCx4/6EnMJAStdF+sNQ5Z72oj5cuOrX3rsa64Z/AHPexbPNpPcNRUyDoaz3hXcW4bIKq5mQDsML/HmO0vc2vL8Lc= 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, Feb 28, 2023 at 5:40=E2=80=AFAM wrote: > > On Wed, Feb 08, 2023 at 03:00:59PM -0800, Jiaqi Yan wrote: > > On Wed, Feb 8, 2023 at 3:45 AM Alexander Potapenko = wrote: > > > > > > On Tue, Feb 7, 2023 at 7:20 PM Jiaqi Yan wrote: > > > > > > > > Pinging KMSAN experts, for the general guidance of > > > > kmsan_copy_page_meta vs kmsan_unpoison_memory > > > > > > Oh, sorry, I've missed the previous email. > > > > NP, thanks for jumping in :) > > > > > > > > copy_mc_user_highpage() is expected to copy data from the user page, > > > for which no metadata is ever allocated. > > > Therefore we just initialize the destination shadow with zeros instea= d > > > of copying anything. > > > > > > kmsan_copy_page_meta() is used when the metadata is copied between tw= o > > > kernel pages, therefore it handles the cases when page->kmsan_shadow > > > is NULL for the source and destination pages. > > > > > > It might be a good idea to use kmsan_copy_page_meta() in both cases, > > > but to do that I want to better understand what happens when > > > kmap_local_page(from) is called in copy_mc_user_highpage(). > > > Where does the corresponding struct page come from? > > > > Kirill can correct me, but I think khugepaged always copies user pages > > because it is trying to convert raw pages to THP for better userspace > > application performance. Therefore khugepaged should only need > > copy_mc_user_highpage(), for both file-backed and anonymous memory > > pages. > > > > However, copy_mc_user_highpage() needs both vaddr and vma, so it is a > > little bit hard to use it in collapse_file (i.e. in the file-backed > > case): > > 1. vma is not carried over to collapse_file from khugepaged_scan_mm_slo= t > > 2. collapse_file is not directly iterating with vaddrs of pages to be c= opied > > > > (Although both vaddr and vma are unused auguments in > > copy_mc_user_highpage, I think for cleanness, the caller e.g. > > khugepaged should feed valid values). > > It is not unused for !copy_mc_to_kernel case (basically everything but x8= 6 > and power). And it is used to flush caches. The fact that you don't have > it in your implementation *may* indicate a problem. ah, I agree this looks problematic. Maybe I should give up on unifying the copying routine used by anon and file memory: * for anon, switch to copy_mc_user_highpage, which "works" for all architectures, but #MC is only recoverable on x86 and powerpc. * for shmem, extend copy_highpage to copy_mc_highpage, like how Tony makes copy_mc_user_highpage. > > > So my patchset uses copy_mc_page(and kmsan_copy_page_meta) for both > > file-backed and anon memory pages. I guess as long as > > kmsan_copy_page_meta doesn't do anything unexpected for user pages (at > > least from my reading), we are good? > > > > -- > Kiryl Shutsemau / Kirill A. Shutemov