linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: mawupeng <mawupeng1@huawei.com>
To: <21cnbao@gmail.com>, <willy@infradead.org>
Cc: <mawupeng1@huawei.com>, <akpm@linux-foundation.org>,
	<david@redhat.com>, <kasong@tencent.com>, <ryan.roberts@arm.com>,
	<chrisl@kernel.org>, <huang.ying.caritas@gmail.com>,
	<schatzberg.dan@gmail.com>, <hanchuanhua@oppo.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: swap: Avoid infinite loop if no valid swap entry found during do_swap_page
Date: Mon, 24 Feb 2025 09:27:38 +0800	[thread overview]
Message-ID: <61566a74-04aa-44f1-9aa9-624644f06450@huawei.com> (raw)
In-Reply-To: <CAGsJ_4xHaaf_DHsFZ_zEqEd3Nb9C=7JJjy5gGFo+RhEhQYX_tg@mail.gmail.com>



On 2025/2/23 14:18, Barry Song wrote:
> On Sun, Feb 23, 2025 at 3:42 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> On Sat, Feb 22, 2025 at 11:59:53AM +0800, mawupeng wrote:
>>>
>>>
>>> On 2025/2/22 11:45, Matthew Wilcox wrote:
>>>> On Sat, Feb 22, 2025 at 10:46:17AM +0800, Wupeng Ma wrote:
>>>>> Digging into the source, we found that the swap entry is invalid due to
>>>>> unknown reason, and this lead to invalid swap_info_struct. Excessive log
>>>>> printing can fill up the prioritized log space, leading to the purging of
>>>>> originally valid logs and hindering problem troubleshooting. To make this
>>>>> more robust, kill this task.
>>>>
>>>> this seems like a very bad way to fix this problem
>>>
>>> Sure, It's a bad way to fix this. Just a proper way to make it more robust?
>>> Since it will produce lots of invalid and same log?
>>
>> We have a mechanism to prevent flooding the log: <linux/ratelimit.h>.
>> If you grep for 'ratelimit' in include, you'll see a number of
>> convenience functions exist; not sure whether you'll need to use the raw
>> ratelilmit stuff, or if you can just use one of the prepared ones.
>>
> 
> IMHO, I really don’t think log flooding is the issue here; rather, we’re dealing
> with an endless page fault. For servers, that might mean server is unresponsive
> , for phones, they could be quickly running out of battery.

Yes, log flooding is not the main issue here, endless #PF is rather a more serious
problem.

> 
> It’s certainly better to identify the root cause, but it could be due
> to a bit-flip in
> DDR or memory corruption in the page table. Until we can properly fix it, the
> patch seems somewhat reasonable—the wrong application gets killed, it at
> least has a chance to be restarted by systemd, Android init, etc. A PTE pointing
> to a non-existent swap file and never being enabled clearly indicates something
> has gone seriously wrong - either a hardware issue or a kernel bug.
> At the very least, it warrants a WARN_ON_ONCE(), even after we identify and fix
> the root cause, as it still enhances the system's robustness.
> 
> Gaoxu will certainly encounter the same problem if do_swap_page() executes
> earlier than swap_duplicate() where the PTE points to a non-existent swap
> file [1]. That means the phone will heat up quickly.
> 
> [1] https://lore.kernel.org/linux-mm/e223b0e6ba2f4924984b1917cc717bd5@honor.com/
> 
> Thanks
> Barry



  reply	other threads:[~2025-02-24  1:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-22  2:46 Wupeng Ma
2025-02-22  3:45 ` Matthew Wilcox
2025-02-22  3:59   ` mawupeng
2025-02-23  2:42     ` Matthew Wilcox
2025-02-23  6:09       ` Barry Song
2025-02-23  6:18       ` Barry Song
2025-02-24  1:27         ` mawupeng [this message]
2025-02-24  4:22           ` Matthew Wilcox
2025-02-24  7:11           ` Barry Song
2025-02-24 15:37             ` Matthew Wilcox
2025-02-22  7:33 ` Kairui Song
2025-02-22  7:41   ` mawupeng
2025-02-22  8:02     ` Kairui Song
2025-02-22  9:58       ` Barry Song
2025-02-23  2:38 ` kernel test robot
2025-02-23  2:50 ` kernel test robot

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=61566a74-04aa-44f1-9aa9-624644f06450@huawei.com \
    --to=mawupeng1@huawei.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chrisl@kernel.org \
    --cc=david@redhat.com \
    --cc=hanchuanhua@oppo.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=schatzberg.dan@gmail.com \
    --cc=willy@infradead.org \
    /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