On Mon, Mar 11, 2024 at 04:14:06PM +0000, Ryan Roberts wrote: > >> There is also a call to mem_cgroup_uncharge() in delete_from_lru_cache(), which > >> I couldn't convince myself was safe. Perhaps you could do a quick audit of the > >> call sites? > > > > That one is only probably OK. We usually manage to split a folio before > > we get to this point, so we should remove it from the deferred list then. > > You'd need to buy a lottery ticket if you managed to get hwpoison in a > > folio that was deferred split ... > > OK, but "probably"? Given hwpoison is surely not a hot path, why not just be > safe and call folio_undo_large_rmappable()? Actually, it certainly can't be hit. Here's the code path: mem_cgroup_uncharge() is only called from delete_from_lru_cache() delete_from_lru_cache() is called from me_pagecache_clean(), me_swapcache_dirty() and me_swapcache_clean() [1] Those are all called through the error_states dispatch table. which means they're all called through identify_page_state() identify_page_state() (other than for hugetlb) is called only from memory_failure() memory_failure() calls try_to_split_thp_page() and only calls identify_page_state() if it succeeds. ie we cannot be dealing with a large folio at this point, so we don't need to worry about the deferred split list. [1] me not cookie monster me is memory error
