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 5DA06C636D3 for ; Wed, 8 Feb 2023 23:01:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5B7B6B0072; Wed, 8 Feb 2023 18:01:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0C1E6B0075; Wed, 8 Feb 2023 18:01:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD3246B0078; Wed, 8 Feb 2023 18:01:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BD00F6B0072 for ; Wed, 8 Feb 2023 18:01:14 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 83D9C1A0DEB for ; Wed, 8 Feb 2023 23:01:14 +0000 (UTC) X-FDA: 80445647268.12.C159998 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf01.hostedemail.com (Postfix) with ESMTP id B291540007 for ; Wed, 8 Feb 2023 23:01:12 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NpxswSfJ; spf=pass (imf01.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.216.54 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=1675897272; 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=3uEYVrycstNqWdwJxUPSrKsA7bcjaRS6UkMNKRcT5A0=; b=KkNlFy3jnxrO5hSsnE1kEoDIR+HbNtgVtLugAHh0M8PHMEt4JTkgzrpTc6Dxu3VgrY3Paq V6ZdkYR6UpN0x6eOtMsMhAXyrKAehNW9yyUVlKkZrUEWQp3LsWRIbo/EGCcLjNSYwjpdmK 59lDUBYj2D209P4RSIfGxM9KqjQv7bU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NpxswSfJ; spf=pass (imf01.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=jiaqiyan@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675897272; a=rsa-sha256; cv=none; b=bY3wmklDhair7cdt+FnJe/gq0+I0uFvwe7Cj9FutjyLfWmj3gyXu/Jf29nstThGQ5/BJG3 12eMNQXuoEajQSzfFnfhRSakfkePsdfPZrqiYHeKMy3CdlbneGqMPbJsa76kDje+Y1zs/A fCagcRs9ih1zqrVoorxxuNr0nLshRMU= Received: by mail-pj1-f54.google.com with SMTP id d13-20020a17090ad3cd00b0023127b2d602so476556pjw.2 for ; Wed, 08 Feb 2023 15:01:12 -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=3uEYVrycstNqWdwJxUPSrKsA7bcjaRS6UkMNKRcT5A0=; b=NpxswSfJY9hR+bHzbwYFxtzz9a3+4Vkyu0cRfjiqbtBe3WF2GyMctjFeZIaS4DYK00 9YwM2YbMNl7ax+qAfRNy+dajD2JeU7MmrSQ9Qq1O5yLP0ZxKstfAHKjZLm6wt6dQQAlg pgrA5pUvFjbKVMMOYK4M/UlYXjX/K7IcMNPLnZkGydTdjSnkOjbMB8Sl4QaEAGpFkCDV 7znYf3W90zLS19ngg7OlIfcY32RXRkAJ1VT4XhFLvcFhJrmRWF8EvCSsRWs8a/q/buFL nR/+y12StlxKSdomD8Gzd2vBcaiOLYF0oMhU9nWRoilSrZ93XB3JQHdCUGYgeeIJkdh7 LIQQ== 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=3uEYVrycstNqWdwJxUPSrKsA7bcjaRS6UkMNKRcT5A0=; b=J9iRp1z/YXghiJina+U8ZtE8PtxWmhFVocFcDfzDTgyibrHOsB5lcdIAc4hhGkTE49 HElfvy6tEoft05sFSWxleUqqr2dDzTV4nL/FBLQAyMsqRMMIpFcgdMFwzQ5Po1tMb4er s4F/RgyutSOB02v9OTre6aiJyk/hp7skGJchQ98DK7bUREfGbgvEFkughueWODe3y8mP 3EjP4q+M/myIBLunc4T0345tWAB3O87MvPBtmcQ/omiTIzu2TT9FOOCgxXoFSU84aw8w pal5JQCekdEoZmKiOMJRpG41lI6E8sgXoHYBYv4PLL4fmc0Z8bp5wsIHq0L1QeAjGBFg N0mQ== X-Gm-Message-State: AO0yUKU3/zHrSXbrHErAICizJ+/Ezu+oNx6hXXocmNRfSSUjVYCC7GRg F25eurriRje2yZypxgvu2jM+brXMI0QGvMjfNbCy9g== X-Google-Smtp-Source: AK7set98DRp6s8aFgdg2/d9P/kJKCBGAefle0Q2B8uwlmKwxoRNZCgWXojRO3AMVaQ51hxP9W4KUw2lnjBnRqbJuUQk= X-Received: by 2002:a17:90a:664c:b0:231:1e0a:8f2c with SMTP id f12-20020a17090a664c00b002311e0a8f2cmr642497pjm.37.1675897271318; Wed, 08 Feb 2023 15:01:11 -0800 (PST) MIME-Version: 1.0 References: <20221205234059.42971-1-jiaqiyan@google.com> <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> In-Reply-To: From: Jiaqi Yan Date: Wed, 8 Feb 2023 15:00:59 -0800 Message-ID: Subject: Re: [PATCH v9 1/2] mm/khugepaged: recover from poisoned anonymous memory To: Alexander Potapenko , kirill@shutemov.name Cc: 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" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B291540007 X-Stat-Signature: r6bthyeihtg9pshbk84to3zaj8w4hz5y X-HE-Tag: 1675897272-159809 X-HE-Meta: U2FsdGVkX18e9OuGtyiJ1eWvRw+9427FnrDHaHZEI+dyod12qb8nYj7N4q3NcEHEH8CwMQeIoGFh4r3ViyEwNym1/W1wVmHqtj2NZqi6ZlrL+9jNiDgnRsSYv6IqPY5HCCoj8e2lTRzQr5WbYerjv3nLsM0M3X9GTJGgzXEDrjDW+R7YS52ZEnMWwRfx6AvMVNHCpwpkslCvsFTB61jr9OleYPuuKj5yowBKWKGDVMiYci+9721bsybpQUfKdSNyINE30J4hqdL1uA2KVABddJkbgxiXAlBD5K/Yc9lVYV5HHVV2ZqNCuXktnLH/IZXko7v2RwT5wcRrKqUVh8cARKgSyIboJqIHBA1KZFcw9HAylRqvqNzmgb7ZgZQs0XUgdWDEiS8TUCDVIDAUNGfrJ0ZvyexlqovbezRob1IOD9uAaENfy4aHKdlzavJ2ObfPe2D7q3dVL2xuaCA8DLUxtclPJB0mIE/3OBN9Iwrt76HmMsMvxxpUgHVK/3svvQxvGbmFeZdK2tcWeiLehjkbl+9mUVrHHwnRppgDNzF7JKqohq4TDsp7iOfSsYNFs+7As3Qg+S+FONannGKCcy0XCwMy5jalSUGcyhn1dacDD9dFaBTJYA993oFqWjC4F8z1hTOnnJg0NmJrawUq7co7mgYkS6qQvbaBD02IbARQevATuXrvy+5ffYk/BQTmXkp9ocGHjtJyARIuvT4ST7jOBmCtHcDPba0f5CVXeg0KNbRN453FswB+QaaITnQj7NGL1j72TPbENe2M696cvSKoc5WRXxl0cM5TP57/QOW58uMCW8LdRIdzpe48ag2Wh4NYPZeoaRiKc3yb03SDaH6HfiWQM6U+9+57vZB7AJN4GU61fTyoJKT4LsxLN7hGk1ZBfKceRsPuG1GYQ8E86thzOzDBhPz6+K6aWBGICEwMEnvfxxnYiAeaW4ELQ1G/t337rpYZp/P1Lbu0c9hCj5N uhXYczUs uAlj3umF5+GoZZku/vQwtyReP7HOoJssPI7rAND7RHC4l+9CpWujc82mwUdSX5adKDCWtJBz2Uw5/e6IeOXlzXcKCSfTVifI+xYkZC8NEFyV/jmGbxVLizc84qK8+Nr0BWX8gR1JUWTYyyAsqznAmzv9oRFFbPHRaUKtaENnRHIkWHmnAHjr3K7TgDq9eDQxZyy2odPrAnIh3D3GSSjHdgIKj1ElmjycSW81B4zhE68uev5h0sUWET79cMMIQfZ2NefTuD18sSVaYHyU= 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, 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 instead > of copying anything. > > kmsan_copy_page_meta() is used when the metadata is copied between two > 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_slot 2. collapse_file is not directly iterating with vaddrs of pages to be copied (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). 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?