linux-kernel - RE: [PATCH v1 4/4] mm/hwpoison: Fix incorrect "not recovered" report for recovered clean pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <SJ1PR11MB6083A9201E4390F160266AC5FCFE2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 14 Feb 2025 16:51:00 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Miaohe Lin <linmiaohe@...wei.com>, Shuai Xue <xueshuai@...ux.alibaba.com>
CC: "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
	"tianruidong@...ux.alibaba.com" <tianruidong@...ux.alibaba.com>,
	"bp@...en8.de" <bp@...en8.de>, "nao.horiguchi@...il.com"
	<nao.horiguchi@...il.com>
Subject: RE: [PATCH v1 4/4] mm/hwpoison: Fix incorrect "not recovered" report
 for recovered clean pages

> > Then the patch will be like:
> >
> > @@ -883,10 +883,9 @@ static int kill_accessing_process(struct task_struct *p, unsigned long pfn,
> >                    (void *)&priv);
> >      if (ret == 1 && priv.tk.addr)
> >          kill_proc(&priv.tk, pfn, flags);
> > -    else
> > -        ret = 0;
> >      mmap_read_unlock(p->mm);
> > -    return ret > 0 ? -EHWPOISON : -EFAULT;
> > +
> > +    return ret > 0 ? -EHWPOISON : 0;
> >
> > Here, returning 0 indicates that memory_failure() successfully handled the
> > error by dropping the clean page.
>
> I'm not sure whether there's another scene that can make walk_page_range() returns 0. But if the
> only reason for walk_page_range() returning 0 is the poison page is a clean page and it's dropped,
> then this modification should be appropriate. With this change, the callers never send SIGBUS now.
> They might need to be changed too.

Note there shouldn't be a SIGBUS when the action was "dropping a clean page". Full recovery
is possible in this case (user process takes #PF, Linux allocates a new page and fills by reading
from storage).

-Tony