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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2A82C4332F for ; Wed, 2 Nov 2022 14:28:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231130AbiKBO2h (ORCPT ); Wed, 2 Nov 2022 10:28:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230515AbiKBO2c (ORCPT ); Wed, 2 Nov 2022 10:28:32 -0400 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC6BF286D9 for ; Wed, 2 Nov 2022 07:28:28 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id v7so5006149wmn.0 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=VkzCL2+mfiBMBNm7VnprtCzpIkXbV4RRetM/HjEpLSg2duzOusFkGgsavtVm9NWr9p 2z4P7/ItWM3yu1i5woDvGYQao2URO10//sr5jK6aY49DyCF5HjjxtSDf6DCw30gM68oG HEZdDyBt9XHBp4eiqgXevGsCyDVXACYryfIE2Mlu8jE+u/VZ3mn8vq1jCoraI0uY8BDG wMj+B6zlcmvgKN40XR7tatU0NT6l6DiZjCHQkNipHwn8uD6ojYut8nAc0b68pFSFVEBp mY/OJZsQIqsy0qAUY31sBXP+/LZLHANHMC34c97bWpU6KAyJUsMlMSdtIlz9kz/76heM rpUA== X-Gm-Message-State: ACrzQf0h9MVwALqgqN5r55oeSboGSWinBAJWDfP1GfjuNsVz56p4qP1M LZGhukDj8e7UQCzzYGh3jHYK5Hs3z9eUZCR7GHL0AQ== 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3A793C433FE for ; Wed, 2 Nov 2022 14:29:59 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4N2Tn12X4Jz3ds4 for ; Thu, 3 Nov 2022 01:29:57 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=YeDR6B6k; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2a00:1450:4864:20::32f; helo=mail-wm1-x32f.google.com; envelope-from=glider@google.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=YeDR6B6k; dkim-atps=neutral Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4N2TlX3j62z3cH5 for ; Thu, 3 Nov 2022 01:28:39 +1100 (AEDT) Received: by mail-wm1-x32f.google.com with SMTP id o30so1099703wms.2 for ; Wed, 02 Nov 2022 07:28:39 -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=sDwF/QbnY5m4Nbxh9zt/rZCDqBOYGw4vnQtScK+SIWQ9r4f+RJYW1meTJJzmTNRakW wlhuMdt00hZrVmx/rmzmzl1kOD5vniFI2JepYw3Pfv7tFpenhRbtUthFTo/8CFwynrSn 7eMicQsiAj2v2+cG+busrsdHdzCxTNzbfaGK3mFrMnBldy8UKudEm3ewQld0Y82PAXNC xkdRc7/bBzQjYxuWg4nm6URO2UTT7doc3wdjh2GEjAgazLcMGhr3e00o3y8KtZLhKf+e vyrXAU94cdyoetlxtebtcz4Kc6CVLxCi03oDaCPS0oLR1zH9wgPkWknKfd/7vmDj0OoA 2Srg== X-Gm-Message-State: ACrzQf3N2zIZ5Ki4IIIXRqA5CO2lgZV9IvrubL7Y3/24HcVr2WjZT6zm E8Ggd8hQN/y7uzbk+8wf91XcwyuQIH0GA6xh4IO5sw== 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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Miaohe Lin , Matthew Wilcox , Naoya Horiguchi , "linux-kernel@vger.kernel.org" , Nicholas Piggin , "linux-mm@kvack.org" , Shuai Xue , "Williams, Dan J" , "linuxppc-dev@lists.ozlabs.org" , Andrew Morton Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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