From: Dave Hansen <dave.hansen@linux.intel.com>
To: Florian Weimer <fweimer@redhat.com>,
linux-x86_64@vger.kernel.org, linux-arch@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>
Subject: Re: MPK: pkey_free and key reuse
Date: Wed, 8 Nov 2017 12:41:30 -0800 [thread overview]
Message-ID: <e7d1e622-bbac-2750-2895-cc151458ff2f@linux.intel.com> (raw)
In-Reply-To: <0f006ef4-a7b5-c0cf-5f58-d0fd1f911a54@redhat.com>
On 11/05/2017 02:35 AM, Florian Weimer wrote:
> I don't think pkey_free, as it is implemented today, is very safe due to
> key reuse by a subsequent pkey_alloc. I see two problems:
>
> (A) pkey_free allows reuse for they key while there are still mappings
> that use it.
I don't agree with this assessment. Is malloc() unsafe? If someone
free()s memory that is still in use, a subsequent malloc() would hand
the address out again for reuse.
> (B) If a key is reused, existing threads retain their access rights,
> while there is an expectation that pkey_alloc denies access for the
> threads except the current one.
Where does this expectation come from? Using the malloc() analogy, we
don't expect that free() in one thread actively takes away references to
the memory held by other threads.
We define free() as only being called on resources to which there are no
active references. If you free() things in use, bad things happen.
pkey_free() is only to be called when there is nothing actively using
the key. If you pkey_free() an in-use key, bad things happen.
next prev parent reply other threads:[~2017-11-08 20:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-05 10:35 MPK: pkey_free and key reuse Florian Weimer
2017-11-08 20:41 ` Dave Hansen [this message]
2017-11-09 14:48 ` Florian Weimer
2017-11-09 16:59 ` Dave Hansen
2017-11-23 12:48 ` Florian Weimer
2017-11-23 13:07 ` Vlastimil Babka
2017-11-23 15:25 ` Dave Hansen
2017-11-24 14:55 ` Florian Weimer
[not found] ` <0f006ef4-a7b5-c0cf-5f58-d0fd1f911a54-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-11-22 8:18 ` MPK: removing a pkey (was: pkey_free and key reuse) Vlastimil Babka
2017-11-22 12:15 ` MPK: removing a pkey Florian Weimer
2017-11-22 12:46 ` Vlastimil Babka
[not found] ` <f0495f01-9821-ec36-56b4-333f109eb761-AlSwsSmVLrQ@public.gmane.org>
2017-11-22 12:49 ` Florian Weimer
2017-11-22 16:10 ` Dave Hansen
2017-11-22 16:21 ` Florian Weimer
[not found] ` <9ec19ff3-86f6-7cfe-1a07-1ab1c5d9882c-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-11-22 16:32 ` Dave Hansen
2017-11-23 8:11 ` Vlastimil Babka
[not found] ` <de93997a-7802-96cf-62e2-e59416e745ca-AlSwsSmVLrQ@public.gmane.org>
2017-11-23 15:00 ` Dave Hansen
2017-11-23 21:42 ` Vlastimil Babka
[not found] ` <2d12777f-615a-8101-2156-cf861ec13aa7-AlSwsSmVLrQ@public.gmane.org>
2017-11-23 23:29 ` Dave Hansen
2017-11-24 8:35 ` Florian Weimer
2017-11-24 8:38 ` Vlastimil Babka
2017-11-23 12:38 ` Florian Weimer
2017-11-23 15:09 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7d1e622-bbac-2750-2895-cc151458ff2f@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=fweimer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-x86_64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).