Re: [PATCH v3 10/18] mm: Allow non-hugetlb large folios to be batch processed

[Matthew Wilcox <willy@infradead.org>]

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