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 93244C4332F for ; Wed, 2 Nov 2022 14:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E68A08E0002; Wed, 2 Nov 2022 10:28:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E197B8E0001; Wed, 2 Nov 2022 10:28:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE01E8E0002; Wed, 2 Nov 2022 10:28:29 -0400 (EDT) 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 BF5218E0001 for ; Wed, 2 Nov 2022 10:28:29 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7B07140DA8 for ; Wed, 2 Nov 2022 14:28:29 +0000 (UTC) X-FDA: 80088732738.20.4B2D75F Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf09.hostedemail.com (Postfix) with ESMTP id E4616140007 for ; Wed, 2 Nov 2022 14:28:28 +0000 (UTC) Received: by mail-wm1-f50.google.com with SMTP id i5-20020a1c3b05000000b003cf47dcd316so1390927wma.4 for ; Wed, 02 Nov 2022 07:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=Y9Q0JUaa9L0FDTRBbRHtk7pORF5FI4qgSR7kELJhqR0=; b=YeDR6B6k0057Cx5aXSoaJU/L1oqbxiIWfIcytTEuQKn8ua9kXxpp/FBg8c7GMpufTd 7GALet6uXxPZ7paxcBnR+iC6vKKCugT4P2jfcLM19gmosJHckL/BSvjORqaJlS1swxJw At0smbGcTxf0q6b64htT/WPu0/IcglEsTqXEaM9nHkaskjy6WqbBd5G6wAHVM6cVmxUt hPgjRCyhzqcQm6jC9EyVofwjWgK7ZrG9je7krios4rICKAYjT5+7XEYOxbanY+Ae8d2T TikB5IvjXbNL/1KsddzudxD5sOHytl2Ub7SfQEiIJ8AX1bicM2pZhC0MlnhxQc9bP+8w pzoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Y9Q0JUaa9L0FDTRBbRHtk7pORF5FI4qgSR7kELJhqR0=; b=DS1z7DLdtmKUdsp2vOMexXwT3UEUIbp2/ugNr9RQdl4wJlhppSOqf2PfKFRn/AW7tV DUFY+AVrhsE+xqG/T28mjd6ZM/RhMXc9AgB9EUkHiwBv9YxxPggj4zycruQED9lzSmsb 4CeM2GVnZ6OYY0MbgdxATlMeCJb8I+62AujoAKtfIaIVc9TWpepeYQHSpeKi/msLufUN dRQCnpIZm/LzpbaDvPqLXseBd4ofDZvt0Sabf2RGXfWY9BS0UvA66VeiSvLa1YFHdrzg Nu/GNSKrM5/Eu0Ui0MWb8/eTyh1PDa/flEKBiBfuo0s5j8zYC8g16qKoSOF08wiiVxBy mb9g== X-Gm-Message-State: ACrzQf38BWfIzxW+jfXnEM9hdgVb4NyKr8ndTO9vCAjE8r6OkI/d/IOK 7vpJTGlhGTXIN90JKQpQ1tzOs4gKLD7ZbMOmLYmX2A== X-Google-Smtp-Source: AMsMyM7zcxHhdaic2LXhNvhEh6OciGXa23nTNLJfIg+yjYW2Qm+0NWtRXRM86sNfUrfXj+EcENc2mD58LJ9imUYppLE= X-Received: by 2002:a05:600c:1609:b0:3cf:4dc4:5a99 with SMTP id m9-20020a05600c160900b003cf4dc45a99mr16005402wmn.67.1667399307208; Wed, 02 Nov 2022 07:28:27 -0700 (PDT) MIME-Version: 1.0 References: <20221019170835.155381-1-tony.luck@intel.com> <20221021200120.175753-1-tony.luck@intel.com> <20221021200120.175753-2-tony.luck@intel.com> In-Reply-To: From: Alexander Potapenko Date: Wed, 2 Nov 2022 15:27:50 +0100 Message-ID: Subject: Re: [PATCH v3 1/2] mm, hwpoison: Try to recover from copy-on write faults To: "Luck, Tony" Cc: Miaohe Lin , Matthew Wilcox , Shuai Xue , "Williams, Dan J" , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , Naoya Horiguchi , Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667399309; 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=Y9Q0JUaa9L0FDTRBbRHtk7pORF5FI4qgSR7kELJhqR0=; b=WYXejcuX3XaDcHXx6M8g9hz+05dduTqXikYjlJXMGQ5CeW/A0yXMgBsQA5JbIKNpap+h1/ UV2QX56mUssJt8IFo41MNECW+3Lwn7upe9VDA270i2DP0t/zi4uyURScu0LKkNF4AcVZUx D/vJvAsm4MK21I040nuxgt57PH+BpAk= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YeDR6B6k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of glider@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=glider@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667399309; a=rsa-sha256; cv=none; b=YZfK8dGNFPhf7dQBpjISeWXF4SzW873ZFQE5eB5aYEa+J5loQ4Pn05eHpWrfPvZ8MnJHpH 8PWSt9sARjNxEwg76yMcB1BbxWzRr2XVx5qih9aynKYL9713tXGqFlx8PaHCZn8Z+9UlO0 QGNoBpyMaqMqdoNS/i8g1TVf/qPT6I0= Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YeDR6B6k; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of glider@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E4616140007 X-Stat-Signature: yob9nsy5wjtif6cb1gsoimayzwehkcdt X-HE-Tag: 1667399308-744570 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, Oct 28, 2022 at 6:14 PM Luck, Tony wrote: > > >> + vfrom =3D kmap_local_page(from); > >> + vto =3D kmap_local_page(to); > >> + ret =3D copy_mc_to_kernel(vto, vfrom, PAGE_SIZE); > > > > In copy_user_highpage(), kmsan_unpoison_memory(page_address(to), PAGE_S= IZE) is done after the copy when > > __HAVE_ARCH_COPY_USER_HIGHPAGE isn't defined. Do we need to do somethin= g similar here? But I'm not familiar > > with kmsan, so I can easy be wrong. > > It looks like that kmsan_unpoison_memory() call was added recently, after= I copied > copy_user_highpage() to create copy_mc_user_highpage(). I'm not familiar = with > kmsan either. Adding Alexander to this thread since they added that code. > Given that copy_mc_user_highpage() replaces one of the calls to copy_user_highpage(), it sure makes sense to call kmsan_unpoison_memory() here. KMSAN tracks the status (initialized/uninitialized) of the kernel memory. Newly allocated memory is marked uninitialized, copying memory preserves its status, and writing constants to that memory makes it initialized. Userspace memory does not have its status tracked by KMSAN, so when values are copied from the userspace, KMSAN does nothing with their status. That's why every (successful) copy_from_user event should be followed by kmsan_unpoison_memory(), which marks the corresponding kernel buffer initialized - otherwise the status of that buffer may get stale. > > Anyway, this patch looks good to me. Thanks. > > > > Reviewed-by: Miaohe Lin > > Thanks for the review. > > -Tony --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg