From: Dave Hansen <dave.hansen@intel.com>
To: Haitao Huang <haitao.huang@linux.intel.com>,
jarkko@kernel.org, dave.hansen@linux.intel.com,
linux-sgx@vger.kernel.org, x86@kernel.org
Cc: reinette.chatre@intel.com, kai.huang@intel.com, stable@vger.kernel.org
Subject: Re: [PATCH] x86/sgx: Return VM_FAULT_SIGBUS for EPC exhaustion
Date: Wed, 25 Oct 2023 07:31:57 -0700 [thread overview]
Message-ID: <b8ec3061-436f-41d3-8bff-635a90774dfb@intel.com> (raw)
In-Reply-To: <20231020025353.29691-1-haitao.huang@linux.intel.com>
On 10/19/23 19:53, Haitao Huang wrote:
> In the EAUG on page fault path, VM_FAULT_OOM is returned when the
> Enclave Page Cache (EPC) runs out. This may trigger unneeded OOM kill
> that will not free any EPCs. Return VM_FAULT_SIGBUS instead.
So, when picking an error code and we look the documentation for the
bits, we see:
> * @VM_FAULT_OOM: Out Of Memory
> * @VM_FAULT_SIGBUS: Bad access
So if anything we'll need a bit more changelog where you explain how
running out of enclave memory is more "Bad access" than "Out Of Memory".
Because on the surface this patch looks wrong.
But that's just a naming thing. What *behavior* is bad here? With the
old code, what happens? With the new code, what happens? Why is the
old better than the new?
next prev parent reply other threads:[~2023-10-25 14:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 2:53 [PATCH] x86/sgx: Return VM_FAULT_SIGBUS for EPC exhaustion Haitao Huang
2023-10-23 23:30 ` Jarkko Sakkinen
2023-10-25 14:31 ` Dave Hansen [this message]
2023-10-25 23:58 ` Huang, Kai
2023-10-26 16:01 ` Reinette Chatre
2023-10-26 16:34 ` Haitao Huang
2023-10-26 21:16 ` Huang, Kai
2023-10-28 8:24 ` Ingo Molnar
2023-10-26 21:10 ` Huang, Kai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8ec3061-436f-41d3-8bff-635a90774dfb@intel.com \
--to=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=stable@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.