[ add Tony, who has wrestled with how to detect rep; movs recover-ability ] On Sun, Mar 10, 2019 at 1:02 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Mar 10, 2019 at 12:54 PM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > Hi Linus, please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > > tags/devdax-for-5.1 > > > > ...to receive new device-dax infrastructure to allow persistent memory > > and other "reserved" / performance differentiated memories, to be > > assigned to the core-mm as "System RAM". > > I'm not pulling this until I get official Intel clarification on the > whole "pmem vs rep movs vs machine check" behavior. > > Last I saw it was deadly and didn't work, and we have a whole "mc-safe > memory copy" thing for it in the kernel because repeat string > instructions didn't work correctly on nvmem. > > No way am I exposing any users to something like that. > > We need a way to know when it works and when it doesn't, and only do > it when it's safe. Unfortunately this particular b0rkage is not constrained to nvmem. I.e. there's nothing specific about nvmem requiring mc-safe memory copy, it's a cpu problem consuming any poison regardless of source-media-type with "rep; movs".
