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

[Sean Christopherson]

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.