Thread (22 messages) 22 messages, 4 authors, 2016-06-03

Re: [PATCH 5/8] x86, pkeys: allocation/free syscalls

From: Dave Hansen <hidden>
Date: 2016-06-01 19:33:07
Also in: linux-arch, linux-mm, lkml

On 06/01/2016 11:37 AM, Jonathan Corbet wrote:
quoted
+static inline
+int mm_pkey_free(struct mm_struct *mm, int pkey)
+{
+	/*
+	 * pkey 0 is special, always allocated and can never
+	 * be freed.
+	 */
+	if (!pkey || !validate_pkey(pkey))
+		return -EINVAL;
+	if (!mm_pkey_is_allocated(mm, pkey))
+		return -EINVAL;
+
+	mm_set_pkey_free(mm, pkey);
+
+	return 0;
+}
If I read this right, it doesn't actually remove any pkey restrictions
that may have been applied while the key was allocated.  So there could be
pages with that key assigned that might do surprising things if the key is
reallocated for another use later, right?  Is that how the API is intended
to work?
Yeah, that's how it works.

It's not ideal.  It would be _best_ if we during mm_pkey_free(), we
ensured that no VMAs under that mm have that vma_pkey() set.  But, that
search would be potentially expensive (a walk over all VMAs), or would
force us to keep a data structure with a count of all the VMAs with a
given key.

I should probably discuss this behavior in the manpages and address it
more directly in the changelog for this patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help