On Fri, Jun 14, 2019 at 01:54:24PM +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:06PM +0300, Kirill A. Shutemov wrote: > > From: Alison Schofield <alison.schofield@xxxxxxxxx> > > > > The MKTME (Multi-Key Total Memory Encryption) Key Service needs > > a reference count on encrypted VMAs. This reference count is used > > to determine when a hardware encryption KeyID is no longer in use > > and can be freed and reassigned to another Userspace Key. > > > > The MKTME Key service does the percpu_ref_init and _kill, so > > these gets/puts on encrypted VMA's can be considered the > > intermediaries in the lifetime of the key. > > > > Increment/decrement the reference count during encrypt_mprotect() > > system call for initial or updated encryption on a VMA. > > > > Piggy back on the vm_area_dup/free() helpers. If the VMAs being > > duplicated, or freed are encrypted, adjust the reference count. > > That all talks about VMAs, but... > > > @@ -102,6 +115,22 @@ void __prep_encrypted_page(struct page *page, int order, int keyid, bool zero) > > > > page++; > > } > > + > > + /* > > + * Make sure the KeyID cannot be freed until the last page that > > + * uses the KeyID is gone. > > + * > > + * This is required because the page may live longer than VMA it > > + * is mapped into (i.e. in get_user_pages() case) and having > > + * refcounting per-VMA is not enough. > > + * > > + * Taking a reference per-4K helps in case if the page will be > > + * split after the allocation. free_encrypted_page() will balance > > + * out the refcount even if the page was split and freed as bunch > > + * of 4K pages. > > + */ > > + > > + percpu_ref_get_many(&encrypt_count[keyid], 1 << order); > > } snip > > counts pages, what gives? Yeah. Comments are confusing. We implemented the refcounting w VMA's in mind, and then added the page counting. I'll update the comments and dig around some more based on your overall concerns about the refcounting you mentioned in the cover letter.
