[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB57508B2C1407546C4D8B501EE79FA@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 20 May 2025 06:43:37 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Ingo Molnar <mingo@...nel.org>
CC: "Hansen, Dave" <dave.hansen@...el.com>, "jarkko@...nel.org"
<jarkko@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai"
<kai.huang@...el.com>, "linux-sgx@...r.kernel.org"
<linux-sgx@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "Mallick,
Asit K" <asit.k.mallick@...el.com>, "Scarlata, Vincent R"
<vincent.r.scarlata@...el.com>, "Cai, Chong" <chongc@...gle.com>, "Aktas,
Erdem" <erdemaktas@...gle.com>, "Annapurve, Vishal" <vannapurve@...gle.com>,
"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>, "bondarn@...gle.com"
<bondarn@...gle.com>, "Raynor, Scott" <scott.raynor@...el.com>
Subject: RE: [PATCH v5 5/5] x86/sgx: Enable automatic SVN updates for SGX
enclaves
> > Yes, meaning is different, see above.
>
> So that's rather convoluted:
>
> atomic64_inc_not_zero(): returns 1 on successful increase, 0 on
> failure
> sgx_inc_usage_count(): returns 0 on successful increase, 1 on failure
> sgx_open(): returns 0 on successful increase, -EBUSY on failure
>
> Could we at least standardize sgx_inc_usage_count() on -EBUSY in the
> failure case, so it's a more obvious pattern:
>
> + ret = sgx_inc_usage_count();
> + if (ret < 0)
> + return ret;
>
Yes, will rewrite accordingly. Especially since I have to return two different
error codes into sgx_open() now to indicate different nature of issues with
running EUDPATESVN: temporal failure due to lack of entropy (-EAGAIN)
and potentially persistent problem when getting unexpected error codes
(-EIO).
Best Regards,
Elena.
Powered by blists - more mailing lists