On Thu, Mar 19, 2026 at 4:30 PM Lisa Wang <[email protected]> wrote: > > This patch clarifies the definition of MF_DELAYED to represent cases > where a folio's removal is initiated but not immediately completed > (e.g., due to remaining metadata references). > > Signed-off-by: Lisa Wang <[email protected]> > --- > mm/memory-failure.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index ee42d4361309..4f143334d5a1 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -862,9 +862,10 @@ static int kill_accessing_process(struct task_struct *p, > unsigned long pfn, > * by the m-f() handler immediately. > * > * MF_DELAYED - The m-f() handler marks the page as PG_hwpoisoned'ed.
nit: would it be worth correcting PG_hwpoisoned to PG_hwpoison'ed? as there is really no "PG_hwpoisoned" page flag. > - * The page is unmapped, and is removed from the LRU or file mapping. > - * An attempt to access the page again will trigger page fault and the > - * PF handler will kill the process. > + * It means the page was partially isolated (e.g. removed from file mapping nit: what about "unmapped"? > + * or the LRU) but full cleanup is deferred (e.g. the metadata for the > + * memory, as in struct page/folio, is still referenced). Any further > + * access to the page will result in the process being killed. > * > * MF_RECOVERED - The m-f() handler marks the page as PG_hwpoisoned'ed. > * The page has been completely isolated, that is, unmapped, taken out of > > -- > 2.53.0.959.g497ff81fa9-goog > Reviewed-by: Jiaqi Yan <[email protected]>
