On Wed, May 2, 2018 at 9:19 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, May 1, 2018 at 8:34 PM Linus Torvalds > <torva...@linux-foundation.org> > wrote: > >> On Tue, May 1, 2018 at 8:22 PM Dan Williams <dan.j.willi...@intel.com> >> wrote: > >> > All that to say that having a typical RAM page covering poisoned pmem >> > would complicate the 'clear badblocks' implementation. > >> Ugh, ok. > >> I guess the good news is that your patches aren't so big, and don't really >> affect anything else. > > > I pondered this a bit. Doing better might be a big pain in the arse. The > interesting case is where ordinary kernel code (memcpy, plain old memory > operands, etc) access faulty pmem. This means that there's no extable > entry around. If we actually try to recover, we have a few problems: > > - We can't sanely skip the instruction without causing random errors. > > - If the access was through the kernel direct map, then we could plausibly > remap a different page in place of the faulty page. The problem is that, > if the page is *writable* and we share it between more than one faulty > page, then we're enabling a giant information leak. But we still need to > figure out how we're supposed to invalidate the old mapping from a random, > potentially atomic context. > > - If the access is through kmap or similar, then we're talking about > modifying a PTE out from under kernel code that really isn't expecting us > to modify it. > > - How are we supposed to signal the process or fail a syscall? The fault > could have come from interrupt context, softirq context, kernel thread > context, etc, and figuring out who's to blame seems quite awkward and > fragile. > > All that being said, I suspect that we still have issues even with accesses > to user VAs that are protected by extable entries. The whole #MC mechanism > is a supremely shitty interface for recoverable errors (especially on > Intel), and I'm a bit scared of what happens if the offending access is, > say, inside a perf NMI. > > Dan, is there any chance you could put some pressure on the architecture > folks to invent an entirely new, less shitty way to tell the OS about > recoverable memory errors? And to make it testable by normal people? > Needing big metal EINJ hardware to test the house of cards that is #MC is > just awful and means that there are few enough kernel developers that are > actually able to test that I can probably count them on one hand. And I'm > not one of them...
I feel this testing pain too. The EINJ facility is not ubiquitous which is why I punted and wrote patch 6 to unit test this. You're right that does not scale for all the potential places we'd like to be able to safely handle memory errors in the kernel. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
