Re: [PATCH v2 0/2] mm: fix PMD level mTHP accounting bugs
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | org.kernel.vger.linux-cxl,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 7/21/26 15:57, Nico Pache wrote: > On Fri, Jul 17, 2026 at 7:29 PM Andrew Morton <[email protected]> wrote: >> >> On Fri, 17 Jul 2026 00:44:58 -0600 Nico Pache <[email protected]> wrote: >> >>> While running selftests I noticed the PMD level per-mTHP stats (nr_anon) >>> remained elevated after each run. After further investigation I noticed >>> this accounting error occurs for both the migration.private_anon_htlb_test >>> and the HMM tests. >>> >>> In the HMM case this is due to folio_add_new_anon_rmap() incrementing the >>> mTHP stats, but never containing a corresponding decrement in >>> free_zone_device_folio(). We solve this by making sure to decrement the >>> counter when freeing device memory. >>> >>> In the migration case, we are incrementing this counter without first >>> checking whether this folio is a hugetlb folio, which relies on a separate >>> accounting system. We solve this by adding the proper hugetlb check before >>> incrementing this counter. >>> >>> With these changes in place, the two tests no longer cause elevated PMD >>> level accounting issues. >> >> Thanks, I've updated mm.git's mm-hotfixes-unstable branch to this >> version. > > Thanks! > >> >> Sashiko is worried about the existing code ("list corruption or a >> use-after-free panic"): >> https://sashiko.dev/#/patchset/[email protected] > > https://sashiko.dev/#/patchset/[email protected] > > I dug into this, although I'm not very familiar with device memory. In general: Don't let a tool waste your time on unrelated things if it wasn't you that asked the tool for it. Someone else asked the tool to find unrelated things. I thought we only support anonymous THP for device-private, not device-coherent. Maybe lib/test_hmm.c could somehow trigger it by selecting MIGRATE_VMA_SELECT_COMPOUND? But in migrate_device_coherent_folio() we have WARN_ON_ONCE(folio_test_large(folio)); So this would already be pretty broken and I wouldn't spend any more time on it. -- Cheers, David