On Mon, Mar 21, 2022 at 10:28:25AM -0700, Luck, Tony wrote: > On Mon, Mar 21, 2022 at 05:21:05PM +0000, Matthew Wilcox wrote: > > On Mon, Mar 21, 2022 at 10:17:29AM -0700, Luck, Tony wrote: > > > Validation folks are seeing this on a v5.16 kernel. I don't > > > see any changes in v5.17 that look like they address it. > > > > > > Mar 04 14:05:05 JF5300-07B181T kernel: page:00000000696b0b6a refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x195cda44 > > > Mar 04 14:05:05 JF5300-07B181T kernel: flags: 0x57ffffc0801000(reserved|hwpoison|node=1|zone=2|lastcpupid=0x1fffff) > > > Mar 04 14:05:05 JF5300-07B181T kernel: raw: 0057ffffc0801000 ffff6ea817369108 ffff6ea817369108 0000000000000000 > > > Mar 04 14:05:05 JF5300-07B181T kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 > > > Mar 04 14:05:05 JF5300-07B181T kernel: page dumped because: hwpoison: unhandlable page > > > Mar 04 14:05:05 JF5300-07B181T kernel: Memory failure: 0x195cda44: recovery action for unknown page: Ignored > > > > > > Som debugging shows this is an anon page (expected ... that's the > > > type of page where the error was injected. They see shake_page() > > > called three times, but it doesn't change anything, so the page > > > is reported as unhandlable. > > > > Uhm, that's not PageAnon. page->mapping is NULL, and anon pages have > > the bottom bit set with the rest of the page->mapping pointing to its > > anon_vma. Why do you think it's an anon page? > > Sorry. I didn't do that decode ... just copied what was in the internal > report. If it isn't anon, then does that page dump give info on what > type the page is? No (I would have volunteered that if it had a type!) It could be a truncated page cache page. But it has the Reserved bit set, which makes me think it's a device driver or something?
