On 3/3/21 7:03 AM, Jarkko Sakkinen wrote: > diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c > index 52d070fb4c9a..ed99c60024dc 100644 > --- a/arch/x86/kernel/cpu/sgx/main.c > +++ b/arch/x86/kernel/cpu/sgx/main.c > @@ -305,7 +305,6 @@ static void sgx_reclaim_pages(void) > { > struct sgx_epc_page *chunk[SGX_NR_TO_SCAN]; > struct sgx_backing backing[SGX_NR_TO_SCAN]; > - struct sgx_epc_section *section; > struct sgx_encl_page *encl_page; > struct sgx_epc_page *epc_page; > pgoff_t page_index; > @@ -378,11 +377,7 @@ static void sgx_reclaim_pages(void) > kref_put(&encl_page->encl->refcount, sgx_encl_release); > epc_page->flags &= ~SGX_EPC_PAGE_RECLAIMER_TRACKED; > > - section = &sgx_epc_sections[epc_page->section]; > - spin_lock(§ion->lock); > - list_add_tail(&epc_page->list, §ion->page_list); > - section->free_cnt++; > - spin_unlock(§ion->lock); > + sgx_free_epc_page(epc_page); > } > } In current upstream (3fb6d0e00e), sgx_free_epc_page() calls __eremove(). This code does not call __eremove(). That seems to be changing behavior where none was intended. Was this, perhaps, based on top of Kai's series that changes the behavior of sgx_free_epc_page()?