Dan Williams <dan.j.williams@xxxxxxxxx> writes: > Right now the kernel does not install a pte on faults that land on a > page with known poison, but only because the error clearing path is so > convoluted and could only claim that fallocate(PUNCH_HOLE) cleared > errors because that was guaranteed to send 512-byte aligned zero's > down the block-I/O path when the fs-blocks got reallocated. In a world > where native cpu instructions can clear errors the dax write() syscall > case could be covered (modulo 64-byte alignment), and the kernel could > just let the page be mapped so that the application could attempt it's > own fine-grained clearing without calling back into the kernel. I'm not sure we'd want to do allow mapping the PTEs even if there was support for clearing errors via CPU instructions. Any load from a poisoned page will result in an MCE, and there exists the possiblity that you will hit an unrecoverable error (Processor Context Corrupt). It's just safer to catch these cases by not mapping the page, and forcing recovery through the driver. -Jeff
