On 2025/2/23 14:18, Barry Song wrote: > On Sun, Feb 23, 2025 at 3:42 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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@xxxxxxxxx/ > > Thanks > Barry