From: Miaohe Lin <linmiaohe@huawei.com>
To: Hao Ge <hao.ge@linux.dev>, Suren Baghdasaryan <surenb@google.com>
Cc: <kent.overstreet@linux.dev>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, Hao Ge <gehao@kylinos.cn>,
<stable@vger.kernel.org>, <nao.horiguchi@gmail.com>,
<akpm@linux-foundation.org>, <pasha.tatashin@soleen.com>,
<david@redhat.com>
Subject: Re: [PATCH] codetag: debug: mark codetags for pages which transitioned from being poison to unpoison as empty
Date: Fri, 23 Aug 2024 15:40:29 +0800 [thread overview]
Message-ID: <292d1141-4edf-ee60-a145-4ca06600076a@huawei.com> (raw)
In-Reply-To: <d6f46ea8-0f09-4942-6818-a58005c8a0c1@linux.dev>
On 2024/8/23 11:37, Hao Ge wrote:
> Hi Suren and Miaohe
>
>
> On 8/23/24 09:47, Hao Ge wrote:
>> Hi Suren and Miaohe
>>
>>
>> Thank you all for taking the time to discuss this issue.
>>
>>
>> On 8/23/24 06:50, Suren Baghdasaryan wrote:
>>> On Thu, Aug 22, 2024 at 2:46 AM Hao Ge <hao.ge@linux.dev> wrote:
>>>> Hi Miaohe
>>>>
>>>>
>>>> Thank you for taking the time to review this patch.
>>>>
>>>>
>>>> On 8/22/24 16:04, Miaohe Lin wrote:
>>>>> On 2024/8/22 10:58, Hao Ge wrote:
>>>>>> From: Hao Ge <gehao@kylinos.cn>
>>>>>>
>>>>> Thanks for your patch.
>>>>>
>>>>>> The PG_hwpoison page will be caught and isolated on the entrance to
>>>>>> the free buddy page pool. so,when we clear this flag and return it
>>>>>> to the buddy system,mark codetags for pages as empty.
>>>>>>
>>>>> Is below scene cause the problem?
>>>>>
>>>>> 1. Pages are allocated. pgalloc_tag_add() will be called when prep_new_page().
>>>>>
>>>>> 2. Pages are hwpoisoned. memory_failure() will set PG_hwpoison flag and pgalloc_tag_sub()
>>>>> will be called when pages are caught and isolated on the entrance to buddy.
>>> Hi Folks,
>>> Thanks for reporting this! Could you please describe in more details
>>> how memory_failure() ends up calling pgalloc_tag_sub()? It's not
>>> obvious to me which path leads to pgalloc_tag_sub(), so I must be
>>> missing something.
>>
>>
>> OK,Let me describe the scenario I encountered.
>>
>> In the Link [1] I mentioned,here is the logic behind it:
>>
>> It performed the following operations:
>>
>> madvise(ptrs[num_alloc], pagesize, MADV_SOFT_OFFLINE)
>>
>> and then the kernel's call stack looks like this:
>>
>> do_madvise
>>
>> soft_offline_page
>>
>> page_handle_poison
>>
>> __folio_put
>>
>> free_unref_page
>>
>
> I just reviewed it and I think I missed a stack.
>
> Actually, it's like this
>
> do_madvise
>
> soft_offline_page
>
> soft_offline_in_use_page
>
> page_handle_poison
>
> __folio_put
>
> free_unref_page
>
>
> And I've come up with a minimal solution. If everyone agrees, I'll send the patch.look this
>
> https://elixir.bootlin.com/linux/v6.11-rc4/source/mm/page_alloc.c#L1056
>
> Let's directly call clear_page_tag_ref after pgalloc_tag_sub.
I tend to agree with you. It should be a good practice to call clear_page_tag_ref()
whenever page_tag finished its work. Do you think below code is also needed?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index de54c3567539..707710f03cf5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1104,6 +1104,7 @@ __always_inline bool free_pages_prepare(struct page *page,
reset_page_owner(page, order);
page_table_check_free(page, order);
pgalloc_tag_sub(page, 1 << order);
+ clear_page_tag_ref(page);
if (!PageHighMem(page)) {
debug_check_no_locks_freed(page_address(page),
Thanks.
.
next prev parent reply other threads:[~2024-08-23 7:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 2:58 Hao Ge
2024-08-22 8:04 ` Miaohe Lin
2024-08-22 9:45 ` Hao Ge
2024-08-22 22:50 ` Suren Baghdasaryan
2024-08-23 1:47 ` Hao Ge
2024-08-23 3:37 ` Hao Ge
2024-08-23 6:20 ` [PATCH] codetag: debug: mark codetags for poisoned page " Hao Ge
2024-08-23 16:39 ` Suren Baghdasaryan
2024-08-25 15:47 ` Hao Ge
2024-08-25 16:36 ` [PATCH v2] " Hao Ge
2024-08-26 6:32 ` Miaohe Lin
2024-08-26 19:07 ` Suren Baghdasaryan
2024-08-23 7:40 ` Miaohe Lin [this message]
2024-08-23 8:10 ` [PATCH] codetag: debug: mark codetags for pages which transitioned from being poison to unpoison " Hao Ge
2024-08-23 16:16 ` Suren Baghdasaryan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=292d1141-4edf-ee60-a145-4ca06600076a@huawei.com \
--to=linmiaohe@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gehao@kylinos.cn \
--cc=hao.ge@linux.dev \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nao.horiguchi@gmail.com \
--cc=pasha.tatashin@soleen.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox