linux-kernel - Re: [PATCH v2 4/5] mm/memory-failure: move hwpoison

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <632479f9-1abd-4c92-86e4-92d08a9b5b2a@oracle.com>
Date: Mon, 20 May 2024 11:15:48 -0700
From: Jane Chu <jane.chu@...cle.com>
To: Miaohe Lin <linmiaohe@...wei.com>, nao.horiguchi@...il.com,
        akpm@...ux-foundation.org, osalvador@...e.de, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] mm/memory-failure: move hwpoison_filter() higher
 up

On 5/11/2024 1:29 AM, Miaohe Lin wrote:

> On 2024/5/10 14:26, Jane Chu wrote:
>> Move hwpoison_filter() higher up as there is no need to spend a lot
>> cycles only to find out later that the page is supposed to be skipped
>> for hwpoison handling.
>>
>> Signed-off-by: Jane Chu <jane.chu@...cle.com>
>> ---
>>   mm/memory-failure.c | 15 +++++++--------
>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 62133c10fb51..2fa884d8b5a3 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -2236,6 +2236,13 @@ int memory_failure(unsigned long pfn, int flags)
>>   		goto unlock_mutex;
>>   	}
>>   
>> +	if (hwpoison_filter(p)) {
>> +		if (flags & MF_COUNT_INCREASED)
>> +			put_page(p);
>> +		res = -EOPNOTSUPP;
>> +		goto unlock_mutex;
>> +	}
> It might not be a good idea to do hwpoison_filter() here. We don't hold extra page refcnt
> yet, so the page state will be really unstable. Or am I miss something?

I agree with you.

It  looks like hwpoison_filter_flags() in particular needs a stable page 
in order to retrieve

a wholesome KPF_ flags set that at any time, although the flags could 
change immediately

afterwards, they won't be torn flags. For that, it looks like the folio 
should be locked as well.

thanks!

-jane

> Thanks.
> .