[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d405428-3847-4862-b146-dd57711c881e@intel.com>
Date: Fri, 7 Jun 2024 10:43:15 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Haitao Huang <haitao.huang@...ux.intel.com>,
Dmitrii Kuvaiskii <dmitrii.kuvaiskii@...el.com>,
dave.hansen@...ux.intel.com, jarkko@...nel.org, kai.huang@...el.com,
reinette.chatre@...el.com, linux-sgx@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: mona.vij@...el.com, kailun.qin@...el.com, stable@...r.kernel.org
Subject: Re: [PATCH v3 2/2] x86/sgx: Resolve EREMOVE page vs EAUG page data
race
On 6/3/24 11:42, Haitao Huang wrote:
>> Second, convince me that this _needs_ a new bit. Why can't we just have
>> a bit that effectively means "return EBUSY if you see this bit when
>> handling a fault".
>
> IIUC, reclaimer_writing_to_pcmd() also uses
> SGX_ENCL_PAGE_BEING_RECLAIMED to check if a page is about being
> reclaimed in order to prevent its VA slot fro being freed. So I think we
> do need separate bit for EREMOVE which does not write to VA slot?
I think the bits should be centered around what action the code needs to
take and not what is being done to the page.
Right now, SGX_ENCL_PAGE_BEING_RECLAIMED has two logical meanings:
1. Don't load the page
2. The page is in the backing store
But now folks are suggesting that a new bit is added which means "do #1,
but not #2".
Let's take a step back and look at what logical outcomes we want in the
code and then create the bits based on _that_.
Powered by blists - more mailing lists