On 01/11/2017 05:49 PM, Dave Hansen wrote:
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.
Hi Dave,
You have brought up an interesting scenario with COW pages. I had
started out with the following policies regarding ADI that made sense:
1. New data pages do not get full ADI protection by default, i.e.
TTE.mcd is not set and tags are not set on the new pages. A task that
creates a new data page must make decision to protect these new pages or
not.
2. Any shared page that has ADI protection enabled on it, must stay ADI
protected across all processes sharing it.
COW creates an intersection of the two. It creates a new copy of the
shared data. It is a new data page and hence the process creating it
must be the one responsible for enabling ADI protection on it. It is
also a copy of what was ADI protected data, so should it inherit the
protection instead?
I misspoke earlier. I had misinterpreted the results of test I ran.
Changing the tag on shared memory is allowed by memory controller. The
requirement is every one sharing the page must switch to the new tag or
else they get SIGSEGV.
I am inclined to suggest we copy the tags to the new data page on COW
and that will continue to enforce ADI on the COW'd pages even though
COW'd pages are new data pages. This is the logically consistent
behavior. Does that make sense?
Thanks,
Khalid
--
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>