Re: [PATCH 0/3] mm, swap: don't spin or flood the console on a bad swap entry
Andrew Morton <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 10 Aug 2026 09:26:48 -0700 Breno Leitao <[email protected]> wrote: > I've seen some machines at Meta flete that show the following type of > problem: > > 1) It gets some weird warning: > > BUG: Bad page map in process khugepaged pte:f000eef300000017 pmd:00000067 > addr:00007f57c0a01000 vm_flags:20200073 anon_vma:ffff88829af7c340 mapping:0000000000000000 index:7f57c0a01 > > The corruption is most likely the collapse/PT_RECLAIM race fixed by > commit 366a4532d96f ("mm: fix the race between collapse and PT_RECLAIM > under per-vma lock"). But this series is not about tha. > > 2) Then it floods all the monitoring of the fleet, sending the same > message in the loop, crashing the our fleet kernel monitoring > subsystem (which is the part that I am interested in protecting) > > get_swap_device: Bad swap offset entry 3ffffffc043c5 > > For instance, in a host today it logged 6M in a few hours, and it is still > going forever. Two things go wrong. > > 1) get_swap_device() prints unconditionally, unlike print_bad_pte() next > door which suppresses itself with is_bad_page_map_ratelimited(). > > 1) do_swap_page() returns 0 when get_swap_device() fails, so the > fault is retried, reads the same entry and faults again. > Nothing in the round trip changes the PTE. > > Trying to fix it in a naive way: Thanks. Sashiko said a bunch of things, all pre-existing. https://sashiko.dev/#/patchset/[email protected] You might wat to address the first one as it's on-topic for this patchset. Ther are some swap things. The remainder are for the poor uffd maintainers to scratch at, if inclined.