linux-kernel - Re: [PATCH v2 3/3] mm/madvise: free hwpoison and swapin error entry in madvise_free_pte

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] [day] [month] [year] [list]

Date:   Fri, 22 Apr 2022 11:15:33 +0800
From:   Miaohe Lin <linmiaohe@...wei.com>
To:     Peter Xu <peterx@...hat.com>
CC:     <akpm@...ux-foundation.org>, <willy@...radead.org>,
        <vbabka@...e.cz>, <dhowells@...hat.com>, <neilb@...e.de>,
        <david@...hat.com>, <apopple@...dia.com>, <surenb@...gle.com>,
        <minchan@...nel.org>, <sfr@...b.auug.org.au>,
        <naoya.horiguchi@....com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] mm/madvise: free hwpoison and swapin error entry
 in madvise_free_pte_range

On 2022/4/22 10:52, Peter Xu wrote:
> On Fri, Apr 22, 2022 at 10:47:32AM +0800, Miaohe Lin wrote:
>> On 2022/4/21 22:28, Peter Xu wrote:
>>> On Thu, Apr 21, 2022 at 08:53:48PM +0800, Miaohe Lin wrote:
>>>> Once the MADV_FREE operation has succeeded, callers can expect they might
>>>> get zero-fill pages if accessing the memory again. Therefore it should be
>>>> safe to delete the hwpoison entry and swapin error entry. There is no
>>>> reason to kill the process if it has called MADV_FREE on the range.
>>>>
>>>> Suggested-by: Alistair Popple <apopple@...dia.com>
>>>> Signed-off-by: Miaohe Lin <linmiaohe@...wei.com>
>>>> ---
>>>>  mm/madvise.c | 13 ++++++++-----
>>>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/mm/madvise.c b/mm/madvise.c
>>>> index 4d6592488b51..5f4537511532 100644
>>>> --- a/mm/madvise.c
>>>> +++ b/mm/madvise.c
>>>> @@ -624,11 +624,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>>>>  			swp_entry_t entry;
>>>>  
>>>>  			entry = pte_to_swp_entry(ptent);
>>>> -			if (non_swap_entry(entry))
>>>> -				continue;
>>>> -			nr_swap--;
>>>> -			free_swap_and_cache(entry);
>>>> -			pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
>>>
>>> Nitpick: IMHO you don't need to invert non_swap_entry() then it'll generate
>>> a smaller diff, just add the new code above "continue".
>>
>> I tried this way, but that lead to long line splitting, so I rewrote the code like this.
>> If you prefer to just add the new code above "continue", I will do it in the next version.
> 
> No worry then, feel free to keep it as is

Will keep it. Thanks!

>>
>>>
>>>> +			if (!non_swap_entry(entry)) {
>>>> +				nr_swap--;
>>>> +				free_swap_and_cache(entry);
>>>> +				pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
>>>> +			} else if (is_hwpoison_entry(entry) ||
>>>> +				   is_swapin_error_entry(entry)) {
>>>> +				pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
>>>
>>> Since it's been discussed and you're reposting a new version anyway, why
>>> not start with either reusing hwpoison or pte markers?  Or do you think it
>>> should be for future to drop the new swap entry again?
>>>
>>
>> IMHO if reusing hwpoison markers, there are some places that we need to distinguish them and do
>> different processing (and maybe also well comment them) which will make code more complicated and
>> somewhat hard to follow. And the "swapin error marker" here is most straightforward. And If pte markers
>> will support the "swapin error case" in the future, I think it's fine to change to use it then.
>> Does this make sense for you?
> 
> Yeah it's fine.  If the pte marker things can finally land as expected,
> maybe I can try it out as the 2nd user of it. :)

Sounds good to me. And if needed, I am glad to do it then. Thanks! ;)

>