Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages

[Jarkko Sakkinen]

On Wed, May 27, 2020 at 06:36:18PM -0700, Sean Christopherson wrote:
> On Thu, May 28, 2020 at 04:23:19AM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 27, 2020 at 10:46:38PM +0200, Borislav Petkov wrote:
> > > On Tue, May 26, 2020 at 09:21:11PM -0700, Sean Christopherson wrote:
> > > > In other words, sgx_alloc_epc_section() is poorly named.  It doesn't
> > > > actually allocate EPC, it allocates kernel structures to map and track EPC.
> > > > sgx_(un)map_epc_section() would be more accurate and would hopefully
> > > > alleviate some of the confusion.
> 
> ...
> 
> > I'm not sure I follow fully Sean's reasoning but the way alloc is used
> > mostly in Linux is to ask through some API the used kernel memory
> > allocator to give memory for some kernel data structures.
> 
> Function names are usually some form of
> 
>   <namespace>_<verb>_<object>
> 
> where 'object' is the target of the 'verb'.  So sgx_alloc_epc_section()
> is most likely going to be read as "SGX, allocate an EPC section".  But
> that code doesn't allocate an EPC section, it maps an EPC section, and on
> success, adds the section's pages to the unsanitized list, i.e. what
> effectively becomes the pool of EPC pages.  The allocation part is a side
> effect of how we track EPC pages, it's not the primary purpose of the
> function.
> 
> Maybe sgx_add_epc_section() and sgx_remove_epc_section() would be better
> than map/unmap?
> 
> Eliminating the misnamed sgx_alloc_epc_section() frees up the "alloc" verb
> for use in the actual EPC page allocation paths, i.e. avoids having to
> rename those to "grab".  IMO, "alloc" is the best name as it most closely
> aligns with the nomenclature for regular pages, e.g. "grab" is most often
> used to elevate refcounts.

I'm thinking that you are over-engineering something this :-) Naming is
never perfect.

But I do get the original comment about sgx_alloc_page().

/Jarkko