Message-ID: <23268661-1501-beb3-726e-9e936bd8f53e@intel.com>
Date:   Wed, 1 Feb 2023 10:47:00 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [PATCH] x86/mce: Set PG_hwpoison page flag to avoid the capture
 kernel panic
To:     =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= 
        <naoya.horiguchi@nec.com>, "Luck, Tony" <tony.luck@intel.com>
CC:     Borislav Petkov <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "Song, Youquan" <youquan.song@intel.com>
References: <20230127015030.30074-1-tony.luck@intel.com>
 <20230130023226.GA3955454@hori.linux.bs1.fc.nec.co.jp>
 <SJ1PR11MB6083B06E5B75E429E5143B76FCD39@SJ1PR11MB6083.namprd11.prod.outlook.com>
 <20230131045011.GB3997492@hori.linux.bs1.fc.nec.co.jp>
Content-Language: en-US
From:   Zhiquan Li <zhiquan1.li@intel.com>
In-Reply-To: <20230131045011.GB3997492@hori.linux.bs1.fc.nec.co.jp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bTlVVExsb2g3anFKU0p5Vis2TmNnc3VGMllnZGl2aXV2cEZZWGw2djBWanlB?=
 =?utf-8?B?NXF5QVcvS2E2L1NoVjZ3TGh4NzB3M1VUSlVvb056R09Zd0NFUE5GQXd3Yzh4?=
 =?utf-8?B?cFhqNnR0SmFuM2l0dVpveG83Y1RsemhVUTZsdXpsb1hkaE1DR2JiZVVoNDhO?=
 =?utf-8?B?N29PT09OVjRwbDdDQXNNTk9JUFZ5ZWtIYlpaRS80ZWRnOUsreXlCVU43NkM4?=
 =?utf-8?B?WDVQeDRJUnlHRzdRdEkramFsVzNBaWZ1bUZab0xSYUhMa092L1c2amhtVUJT?=
 =?utf-8?B?TlJPeThqRzhtMFhDYzVJaG9DanRrM1Q4Y2xyTnJnREg0cXpwZVJHd1J2YVk4?=
 =?utf-8?B?NWd3a1RhRENnZ096KzVCUWF0K0NPY3FNc1lNbUl6YzQyZlFlNzZxVGIrRDhO?=
 =?utf-8?B?U3g3RUhFRnRSREk4RGNPVC9JME1jc0hMZ3MyUmRLL2NNUGY3aGhRQkxpSm1Z?=
 =?utf-8?B?VFNQbjZVZnRJTWwzcSs4ajVLSjh0N3kvby94b1RCZk4zMnlQWnI1ZDVUZTFK?=
 =?utf-8?B?c09hNFU5Sys3dkdpVXVBNkhmT0VmeC8wdkV0akpnS3M5QldZaG4zOHhkNWdY?=
 =?utf-8?B?R1V3b1Q4M1FLQ0dvMDZHWjRzNC81c3I0YjBnY2IzVUt4bWJlL0trNkJWbFFP?=
 =?utf-8?B?RlZzTlhCUUNjU1Q2TlUycWhnZDZJVXNob3RwVEFoc25rWGVhRHgvWnY0UDlh?=
 =?utf-8?B?MFRhbmpsb0VLK296SVlkaTNvZmZYVWc3aGNKdjBISktwVWxTZ1ZaS2N3UFVj?=
 =?utf-8?B?bHlBUmZzYVRpaWVhWisvWkJkQm9WbHFrdXhFblRua094ZnBLTytnanltaldN?=
 =?utf-8?B?MEZJWVNvcEJIOWV3dVhZV205V1l6MU85U21GcFVBQlJmOVlXK0JHTkd4M2Nz?=
 =?utf-8?B?R0xFOGRoVzZrVWkxUmo5bHYwazRPaVc5d0QzRTlJZ205M0NFREYwdVBvMmht?=
 =?utf-8?B?TGpPcFFKSURHbHdRcnBqaVRrZ1Q3REw2dFM3MEF2UWs1SUFLc2xaU1pQVFYx?=
 =?utf-8?B?WDJSNVJHTUlkaXpKZTIzOTFuclkzYUxyenNlRUZCYzgreVM1M3RJS3ROV2FN?=
 =?utf-8?B?SDN3UXF2OU1jYWZraDNQM1NhazM0ZnNMR3poMktnRktmRTk3Y1lSNDlpVjNO?=
 =?utf-8?B?clp4V0VUTlkwVW5abk9aNnlIQmdxWlZIR2pwOFU0bVE2Z2c5RmJLMkZNdjdo?=
 =?utf-8?B?SUNub1UzUldIS25JQmlJdmFrVk91YzdGOEVLMHBEUEt2a0pocm5GOVBHQVNC?=
 =?utf-8?B?NzlhT2hLMnorZlhscWx3NFNWN1kyZmxYaVdrVllkRitNZVVnRkpibHRxM3VD?=
 =?utf-8?B?ekM1UHNRNkZOZVY5VGl5SmxGcmdBMiszY1RTTmZGL0pIcnRQaVROb2gwdUpZ?=
 =?utf-8?B?QzhVUWoxSlorU09BNWtTTmVvbjl5M1NUZElVMlFVYmxNWjJicFJoY0p3bTJT?=
 =?utf-8?B?REFmWTJPeDc3TlJ3akJhZFhUNVdJdDE3cm5oQ1dKU0NkWHc4ZDIyZGR5QkVE?=
 =?utf-8?B?ZE4xcHRsM3BvN3BoencrNFpLM1Fod1N6ekVuWXZBaHdlNEIySVF0RE12cDBO?=
 =?utf-8?B?eWdYNkQvdEx5VWo0NkxHSkdVRVM3cU5IeGRLc2lkQVhCc0I3emJnNTJQTE50?=
 =?utf-8?B?cWFpVmdtTlQ4aCtNUWJRWlJCS0lEOEpJUHJKTmFRcUV2WmdMdGJSbFU0cDZD?=
 =?utf-8?B?ZTdRSkN1MHN1TGxMMGZzcTlvMytwS2dBVENZdjZwWUhaeUwwZG5mL1ErTUlC?=
 =?utf-8?B?SldIVXFpNjRtVVlCb3VxUml6Wk9JQUFVVTQwWXI1NEhYUmtLWmpKK3FnTk9a?=
 =?utf-8?B?eEdlQXhFcTZXVmNGY1haVUFwVWt1dGd2c1M3WlJyWWI5SGsxUG9kOXFSSE4v?=
 =?utf-8?B?NzR5TllRbjhFTzBWcVdLVU1IWXVLM3NuWVh0STdXd21KM0dLcWtnQ0tIN29U?=
 =?utf-8?B?bi9UeWQyeW9xYVVHZHFoL1BBaS8rcnhweEFITUJvcGw2SWZpb01wSW1hOEtX?=
 =?utf-8?B?ZEsvYndmN2lDdTVFamNUSWNLTm9NNWFuQk9oZ0FvWHBJZ0xVaVgvSHk5bGlk?=
 =?utf-8?B?Q1NCMk9FeWhOQm1rYnhGOHVpOVQ1bnU0L3BzUlZzTmlEMGwyalpITDFSVzl3?=
 =?utf-8?B?b2tET1FnbXhBUVpXdCs3UTdXZ2ZoWW9RRWp0aTRTV2VnZm1UTTJDWFVQQ1c5?=
 =?utf-8?B?bmc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 25e4269c-2293-4c9f-4f7e-08db03fd7727
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3728.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2023 02:38:56.7793
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: NJtWFIYxSdN+5xEamsfP/RSo1hTVLgLxGxuzmvUgpaXyQgoWy9/enJzkHZKBi+zbP/mMKU3Za9G37aKUxax4Aw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB7056
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 2023/1/31 12:50, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Jan 30, 2023 at 07:21:15PM +0000, Luck, Tony wrote:
>>> Although I'm not sure that SGX memory or PMEM pages are expected to be
>>> included in kdump, but simply setting PageHWPoison does not work for them?
>>> (Maybe that depends on how kdump handles these types of memory.)
>>
>> SGX/TDX pages can't be dumped. They are encrypted with no way for kdump to
>> get the key.
>>
>> PMEM seems pointless (but I don't know what kdump does here).
>>
>>> As for HugeTLB, kdump utility should parse the struct page and be aware of
>>> HugeTLB pages, so maybe setting PageHWPoison on the head page could work.
>>
>> Or maybe kdump can take not of the PageHWPoison flag on the sub-page of the
>> huge page? It depends on whether there is any benefit to the dump to include the
>> not-poisoned parts of a huge page.
> 
> I think that many kdump users filter out HugeTLB pages (setting dump_level
> to filter "User pages") to reduce the size of kdump.  User pages are not
> much helpful to investigate kernel problems, so filtering all sub-pages in
> hwpoisoned hugepage seems to me not so harmful.
> 
> I don't say that saving healthy subpages has no benefit, but I don't know
> much about usecases where user pages in kdump file help.
> 

Many thanks, Naoya and Tony.

The "TODO" comment was initially added by me. I referenced
memory_failure() that gets rid of the three cases specifically, so I'd
like the cases are fully discussed here to make sure it is a strong fix.

- SGX, as Tony said those pages can't be dumped.
- PMEM, although the memory region is figured out by kexec, kdump
utility doesn't have corresponding implementation for it.  So we can
ignore it.
- HugeTLB
  As we known there are complicated processes for HugeTLB pages at
memory_failure(). However, it doesn't make sense for a routine going to
call panic().  Kernel marks the page hwpoisoned would be enough.

The information is sufficient for kdump to make decision on how to deal
with a hwpoisoned huge pages, even though setting the PageHWPoison flag
on the sub-page of a huge page.  It's kdump's responsibility for the
not-poisoned parts of a huge page.  Currently the implementation is to
exclude the whole huge page simply:

-
https://github.com/makedumpfile/makedumpfile/commit/e8b4f93b3260defe86f5e13ca7536c07f2e32914
- https://bugzilla.redhat.com/show_bug.cgi?id=1181649

Best Regards,
Zhiquan