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 917FEC433FE for ; Wed, 20 Apr 2022 13:39:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378578AbiDTNlw (ORCPT ); Wed, 20 Apr 2022 09:41:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233121AbiDTNlv (ORCPT ); Wed, 20 Apr 2022 09:41:51 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F01DD43388 for ; Wed, 20 Apr 2022 06:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650461945; x=1681997945; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=5rhMhH6TF5DbIecBIgZYcaxM4JlyAMgHd4dTkECw8NI=; b=XMJ0v7b4GiqZ19dwziwTmwnd4cr4wtB+G0aUWmv16QTRRqRSlH7gAAN9 krceCJg3i7fAhBbYylEJSxVcIbZYfcGzsVrZA+vE6BOiZ+44nDaSS/RHR ohqI9sFveoQHF18Gybs9vWGJT+nqgmgUBrF7OXt14UAiwH7PvLx0z/emE eOANIUGQMK41l0SaVvUgjFTFe1rBoymNDdufr7JghUWNl4FRW4F86VcJT eRFQMxEG2RXns0u8YyKFJb76VwqtK+eMdGGD5ziJmuDBFSZgRp7PoMo8x mDLLmJeKcgRHp5s2KKq9Tcl8iz+ulQbnASymLItkKncwQWLwc+zxnyy7f A==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="251333061" X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="251333061" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 06:39:04 -0700 X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="562109991" Received: from mileskin-mobl.amr.corp.intel.com (HELO [10.213.184.8]) ([10.213.184.8]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 06:39:03 -0700 Message-ID: <3720f7d9-a4f3-214c-1dea-f8ffc837c1da@intel.com> Date: Wed, 20 Apr 2022 06:39:02 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Qiuxu Zhuo , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Tony Luck , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Naoya Horiguchi Cc: "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:HWPOISON MEMORY FAILURE HANDLING" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" References: <20220420210009.65666-1-qiuxu.zhuo@intel.com> From: Dave Hansen Subject: Re: [PATCH 1/1] x86/mm: Forbid the zero page once it has uncorrectable errors In-Reply-To: <20220420210009.65666-1-qiuxu.zhuo@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/20/22 14:00, Qiuxu Zhuo wrote: > Accessing to the zero page with uncorrectable errors causes unexpected > machine checks. So forbid the zero page from being used by user-space > processes once it has uncorrectable errors. Processes that have already > mapped the zero page with uncorrectable errors will get killed once they > access to it. New processes will not use the zero page. There are lots of pages which are entirely fatal if they have uncorrectable errors. On my laptop, if there were an error, there is a 0.00000596% chance it will be in the zero page. Why is this worth special casing this one page?