Re: [PATCH 2/3] mm: add KUnit coverage for mappingless swapcache folios
Shivam Kalra <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
On 08/08/26 16:40, Kairui Song wrote: > FOLIO_SPLIT_KUNIT_TEST seems a generic test and not limited to SWAP, > but it relys on SWAP, looks a bit strange to me. Fair point, the naming is misleading. FOLIO_SPLIT_SWAPCACHE_KUNIT_TEST would have been a more honest name given the scope. I'll fix this if the KUnit patch is kept. > Faking a swapcache with folio->swap == 0 looks hacky, could go very > wrong if you do any actual work on it. Agreed it is fragile. The reason I went with this approach is that setting up a real swapcache folio in KUnit is quite difficult. > Hmm... you are just testing the gating, not the actual split, that > makes the test not very meaningful I think. And we should not block > non-uniform or high order split for swap cache after sorting things > out, then this test will be doing nothing :) Same reason, testing an actual split in KUnit would require the full swapcache infrastructure that is hard to mock up. The gating check is what this patch actually changes, so it felt like the right thing to cover in a unit test. The real end-to-end split coverage is in patch 3/3 (split_hwpoison_swapcache selftest), which goes through the full memory_failure() -> split -> swapin path with a real swap device. That said, I take your point that once higher-order and non-uniform splits are unblocked for swapcache, these gating assertions would become stale. I'm happy to drop this KUnit patch for v2 and send just patches 1 and 3 if you think the selftest provides sufficient coverage on its own. On the broader question, I'd be interested to see your RFC for the swapcache split cleanup. Would you prefer that I wait for it before sending a v2, or would you be fine with the smaller two-patch series (core fix + selftest) going in first to resolve the TODO? Thanks, Shivam