Received-SPF: pass (google.com: domain of linux-kernel+bounces-187947-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <cb88f1e9-4e95-436e-90db-4ea58e30fdc8@oracle.com>
Date: Thu, 23 May 2024 12:58:35 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 3/5] mm/memory-failure: improve memory failure
 action_result messages
To: Miaohe Lin <linmiaohe@huawei.com>, nao.horiguchi@gmail.com,
        akpm@linux-foundation.org, osalvador@suse.de, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20240521235429.2368017-1-jane.chu@oracle.com>
 <20240521235429.2368017-4-jane.chu@oracle.com>
 <e6827d64-0f05-6874-7566-35d56782a6aa@huawei.com>
Content-Language: en-US
From: Jane Chu <jane.chu@oracle.com>
In-Reply-To: <e6827d64-0f05-6874-7566-35d56782a6aa@huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?MHJ1MnhUYTV1dk1sTE02dCtFakl5cFNiMmRWV2JPU1k4YmRNZlNWc3lEL29y?=
 =?utf-8?B?MXB5RWh2MTZLYU45Tlc0Z0FuZXMyMGxSd05zenNHRWp5SnF3Q1pwS1l5dVFo?=
 =?utf-8?B?bDZjQ1pkSkNiVVVEdS9HbXEySk9Pb25aVTRsbzNKQzVDWWpoMHlTM044TWJC?=
 =?utf-8?B?YTZMcGtYWEdxQ2M2cUFvUWVDRlcyUU1xZ3dCemhmTmR1b2UxdFoyWkdic2Nx?=
 =?utf-8?B?MXZFbTIzcFRFOXlPTWRqK3dETUVCLzBocWhtUHk2c2hOK1NpWmhaKzFEMENk?=
 =?utf-8?B?SHQrc1dtZ3M1TlJLc3BIYjRhdUZYSG54Y3hneSt6NDZodWFUbk9McSs2Wk5R?=
 =?utf-8?B?cXRLYS9Jd2E1Y2M1TDk2RVZ2citoM1BKbUk0NlhKMC9KUm1GeTdMVXpRZXVM?=
 =?utf-8?B?ZVpTSEFxc3Via3FpVjZpN0Y5VTBYOWxVN3BwODE3TGplUWNNWVBmLzhWa2Nt?=
 =?utf-8?B?UDlJU1BLRWJaN0pORWxwTGgyZzRaeTVmd3B0VmhVNGJhbGhSYkNzQTRXRmRx?=
 =?utf-8?B?QTFENm56TmZEVEg4WE1jb2YwQjJiVHY2L2J2SG1NbDF5bElBY1FjNy9XdmJu?=
 =?utf-8?B?VnpzdUcrN2dMM1RPdmI3V2FCYWRwc2pFYlVZMFpzVlVrOTBVczJGb3ZBZnV5?=
 =?utf-8?B?UXVDN1c2K2NKbkR3OUZhL0htK1ZKTnprcmZxN2NEcnF4eVZQLzZBNFZVa0NB?=
 =?utf-8?B?MmVqemZnL0xmWER5Qm94dm5SdmJzN0xxaFo4NkQvSEF1U3Fqa3AvZU52dzhr?=
 =?utf-8?B?ekJFNGJoQndXRDF5TVZnTmhFMk44YUtGaFNPdjRVMnVGNzhlRVR1cnRYNXlO?=
 =?utf-8?B?MCtlTVA1N3hyNHNwV1lUbWhEYXkwUmRtTVdOUlo4VmdoeHM0bGNwNFNadzE4?=
 =?utf-8?B?NVhPbERuc09Vbjh2SlMrN2JiQldIMFFORWc5OUlSMm82WmdWelFuR1l3UUVp?=
 =?utf-8?B?aWdIbkpWQ3I4TFNWeGZ6ems4cDdLcXlySFJlZzNRRFlrUktMRDJua0RmR3pv?=
 =?utf-8?B?OHF6YldBSmtuQXNiZzBmWmF1VDNTY1Y1RkNZYjBOeHVLRVhGR2lWZ0VyT2hK?=
 =?utf-8?B?QWtCWVRwTk1ya2s3NnFPLytrWHBCdFdaLzFyYWlSZTlNQm10OWRtQzdwVVZI?=
 =?utf-8?B?MzcwM2lvcyt4Ri8zVzhuYzQyQUxmRFRERFVzQWxnQTJsTnc3cUQraTRDNG1h?=
 =?utf-8?B?NmVvaXpBUFBzQVA3VTZTbEJiOEZBK1NIVlcrd0tLcmYxSHJ1TVlQSXBxc1Qv?=
 =?utf-8?B?M3YyVHJYNmtNYW1rcnlwbEZSalA5K1RTMXpld215aUxscFRzTE51aEo4eWZB?=
 =?utf-8?B?MzJzUXcrM0FMQ2pPcFByVnQ1Vm9RcDUwYm1SQmxDbWd4T1psSnJ1NTZaTDZi?=
 =?utf-8?B?TDQ2eitsK2pBeGgyK01UOHQvWFIzanlDbGZVZ1lEK013ZHA4RXZWeDR6Qit4?=
 =?utf-8?B?bndmdTc0cklZb2VLL3M5ZXppK200TEkzSUQwN3JaRmlJWms5dDlJU3M3QjhG?=
 =?utf-8?B?WDZVa0hTSFBocFp4UXV4QWo5ZytINUU5OXRnb0RNTHZPczMxSWMybE04UkpN?=
 =?utf-8?B?a3ljVG9zbDkxSVFJZkdJUlMxdkdZYUlsemFPSm1LaG1uRmYrYjNaTjQ2SEty?=
 =?utf-8?B?Z3dQeW9JTllFWjRVKzlUZ2lvYlhJS25nelhxM05HUnJGeWZ5TXo0NUpIREZQ?=
 =?utf-8?B?em03Y0RRMXh0Mnp4dmZmbWlGV3NuNFZOWjF5bnJ1MHRnQjJxTVdxcXVkR0sv?=
 =?utf-8?B?ZXFSaCtOY1hXRVFwSGIxN1gvTi92d2ZMNDlSSjh4TFNPMVlaODB0aGV2WlN4?=
 =?utf-8?B?N2owSnNrRHlBb0N6SG1aOFdRMXg0c3RDSlM0UXY0MGk5QnRnL1ozLzMwM1ZZ?=
 =?utf-8?B?VmFtTjJlR1gwZktBN0FBeXUyVVgrOEJTOS9Vd2xxMVIrdzY1dWxsODJCd0RZ?=
 =?utf-8?B?ZTRqWlU1ajYvVlJ3OGZkNlJDUUhrOFg2b0xQTnhlWGtzaW9tR3JlaTlyTm5a?=
 =?utf-8?B?MGcxN0VZZWdraDR2eTFNRWJyazQzbnJGU0paRk5KblYwVFJ6ZStrM050dlNS?=
 =?utf-8?B?VElyeUlnTlZvN3h4dGt1TEtBaU9ucmtKQ04yaC9taG8va05PeVpVdUd3c2F0?=
 =?utf-8?Q?jn8Q7OeOmzGz+Hg3KILT1bcS3?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	P+tOXzK811dYVJ9+sO29FPfGkuYxLYFQcYnBkWbP13uGPVOtTogNsjhHQlJcMUYUBw601h0fqoLy+MyXJjD1UvcrxE4PmBfouqr4XE92aaFf3sLl+Vwbdj+kXlW/p7fLKENIZWjPydHvalnXI4m3hjf3gEKQ9cHY9GNtwr+NLQDUtCaAhFu1uRzGKDR7PN4BHomZbETGoBHLapVf5/CP4LWI8Fx3ejr6hB8NraEPo6/nwZ4z4zx/5qyawEOR4r1rBRMX0MECOK/07+SrdYjkaA9iqKicoB3AKumFVWl5YXll7JHtYegv3Q8jg3FSjM5SAJ6B/NUHAisi6eiQQbyWQXsltEKm6FbfiHDhicdMwP+4iiQTrf7dncCepc6hEPJtfCeme8pudYt9GbWvDzl9z4AdBkGEzH73tvzF80cafxj8S69cPELtbnZdsGUIhBMEZkGqhwgQor149HqtvIcz+G0WFBVyvtZxfT0hTPhVcMQOD9/aw5YXDs87MUjSJzztrfct9Zfk8I8+c7LR541td+AvOJR0UsJhJWx45Vl/vwdML+NMBPU0o/Ex/ArcRIkhHvca1Ie94OetjwhV9tuULG1EGpRUAxVfFAi31xW8rUQ=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dac60e56-beca-4792-cae6-08dc7b62bc29
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4429.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2024 19:58:37.5093
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: dw69Za6OrLdyzVU3u8vUSxLFj1I+m3MJvDAZaTwqL5QcbeNaI/HBQbxDE4oAQESP1DPED9lNcXP7j/u6ScHMNQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB5829
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
 definitions=2024-05-23_11,2024-05-23_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0
 suspectscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2405010000 definitions=main-2405230138
X-Proofpoint-ORIG-GUID: X7XDQNl_ivX6MXc8YWGdWrWykZOqgvVM
X-Proofpoint-GUID: X7XDQNl_ivX6MXc8YWGdWrWykZOqgvVM

On 5/22/2024 7:31 PM, Miaohe Lin wrote:

> [..]
>> +/*
>> + * MF_IGNORED - The m-f() handler marks the page as PG_hwpoisoned'ed.
>> + * But it could not do more to isolate the page from being accessed again,
>> + * nor does it kill the process. This is extremely rare and one of the
>> + * potential causes is that the page state has been changed due to
>> + * underlying race condition. This is the most severe outcomes.
>> + *
>> + * MF_FAILED - The m-f() handler marks the page as PG_hwpoisoned'ed. It
>> + * should have killed the process, but it can't isolate the page, due to
>> + * conditions such as extra pin, unmap failure, etc. Accessing the page
>> + * again will trigger another MCE and the process will be killed by the
>> + * m-f() handler immediately.
>> + *
>> + * MF_DELAYED - The m-f() handler marks the page as PG_hwpoisoned'ed. The
>> + * page is unmapped, but perhaps remains in LRU or file mapping. An attempt
> Would the page remain in LRU or file mapping? IIUC, MF_DELAYED is returned from two functions:
> 1. me_swapcache_dirty. Page lives in swap cache and removed from LRU.
> 2. kvm_gmem_error_folio. Page range is unmapped. It seems page won't be in the LRU or page cache.
> Or am I miss something?
Agreed, I'll fix the comment.
>> + * to access the page again will trigger page fault and the PF handler
>> + * will kill the process.
>> + *
>> + * MF_RECOVERED - The m-f() handler marks the page as PG_hwpoisoned'ed.
>> + * The page has been completely isolated, that is, unmapped, taken out of
>> + * the buddy system, or hole-punnched out of the file mapping.
>> + */
>>   static const char *action_name[] = {
>>   	[MF_IGNORED] = "Ignored",
>>   	[MF_FAILED] = "Failed",
>> @@ -893,6 +915,7 @@ static const char * const action_page_types[] = {
>>   	[MF_MSG_DIFFERENT_COMPOUND]	= "different compound page after locking",
>>   	[MF_MSG_HUGE]			= "huge page",
>>   	[MF_MSG_FREE_HUGE]		= "free huge page",
>> +	[MF_MSG_GET_HWPOISON]		= "get hwpoison page",
>>   	[MF_MSG_UNMAP_FAILED]		= "unmapping failed page",
>>   	[MF_MSG_DIRTY_SWAPCACHE]	= "dirty swapcache page",
>>   	[MF_MSG_CLEAN_SWAPCACHE]	= "clean swapcache page",
>> @@ -906,6 +929,7 @@ static const char * const action_page_types[] = {
>>   	[MF_MSG_BUDDY]			= "free buddy page",
>>   	[MF_MSG_DAX]			= "dax page",
>>   	[MF_MSG_UNSPLIT_THP]		= "unsplit thp",
>> +	[MF_MSG_ALREADY_POISONED]	= "already poisoned",
>>   	[MF_MSG_UNKNOWN]		= "unknown page",
>>   };
>>   
>> @@ -1013,12 +1037,13 @@ static int me_kernel(struct page_state *ps, struct page *p)
>>   
>>   /*
>>    * Page in unknown state. Do nothing.
>> + * This is a catch-all in case we fail to make sense of the page state.
>>    */
>>   static int me_unknown(struct page_state *ps, struct page *p)
>>   {
>>   	pr_err("%#lx: Unknown page state\n", page_to_pfn(p));
>>   	unlock_page(p);
>> -	return MF_FAILED;
>> +	return MF_IGNORED;
>>   }
>>   
>>   /*
>> @@ -2055,6 +2080,8 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb
>>   		if (flags & MF_ACTION_REQUIRED) {
>>   			folio = page_folio(p);
>>   			res = kill_accessing_process(current, folio_pfn(folio), flags);
>> +			action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED);
>> +			return res;
> We might reuse the below "return res;"?
Yes, will fix.
>>   		}
>>   		return res;
> Besides from the above possible nits, this patch looks good to me.
> Acked-by: Miaohe Lin <linmiaohe@huawei.com>
> Thanks.
> .

Thanks!

-jane