On 01/11/2017 04:22 PM, Khalid Aziz wrote: ... > All of the tag coordination can happen in userspace. Once a process sets > a tag on a physical page mapped in its address space, another process > that has mapped the same physical page in its address space can only set > the tag to exact same value. Attempts to set a different tag are caught > by memory controller and result in MCD trap and kernel sends SIGSEGV to > the process trying to set a different tag. Again, I don't think these semantics will work for anything other than explicitly shared memory. This behavior ensures that it is *entirely* unsafe to use ADI on any data that any process you do not control might be able to mmap(). That's a *HUGE* caveat for the feature and can't imagine ever seeing this get merged without addressing it. I think it's fairly simple to address, though a bit expensive. First, you can't allow the VMA bit to get set on non-writable mappings. Second, you'll have to force COW to occur on read-only pages in writable mappings before the PTE bit can get set. I think you can probably even do this in the faults that presumably occur when you try to set ADI tags on memory mapped with non-ADI PTEs. >> If you want to use it on copy-on-write'able data, you've got to ensure >> that you've got entirely private copies. I'm not sure we even have an >> interface to guarantee that. How could this work after a fork() on >> un-COW'd, but COW'able data? > > On COW, kernel maps the the source and destination pages with > kmap_atomic() and copies the data over to the new page and the new page > wouldn't be ADI protected unless the child process chooses to do so. What do you mean by "ADI protection"? I think of ADI _protection_ as coming from the PTE and/or VMA bits. Those are copied at fork() from the old VMA to the new one. Is there a reason the child won't implicitly inherit these that I missed? Whether the parent or the child does the COW fault is basically random. Whether they get the ADI-tagged page, or the non-ADI-tagged copy is thus effectively random. Assuming that the new page has its tags cleared (and thus is tagged not to be protected), whether your data continues to be protected or not after a fork() is random. That doesn't seem like workable behavior. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>