All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	<linux-sgx@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Zhimin Luo <zhimin.luo@intel.com>
Subject: Re: [PATCH] x86/sgx: Fix deadloop in __sgx_alloc_epc_page()
Date: Fri, 30 Aug 2024 14:02:34 +0800	[thread overview]
Message-ID: <ZtFgem6_2j05S0MJ@ziqianlu-kbl> (raw)
In-Reply-To: <f2b0ffc7-f8f8-4ebc-99da-9139c372bd09@intel.com>

On Thu, Aug 29, 2024 at 08:17:53AM -0700, Dave Hansen wrote:
> Generally, I think it's a bad idea to refer to function names in
> subjects.  This, for instance would be much more informative:
> 
> 	x86/sgx: Fix deadlock in SGX NUMA node search

Indeed, will use this as subject, thanks.

> On 8/28/24 19:38, Aaron Lu wrote:
> > When current node doesn't have a EPC section configured by firmware and
> > all other EPC sections memory are used up, CPU can stuck inside the
> > while loop in __sgx_alloc_epc_page() forever and soft lockup will happen.
> > Note how nid_of_current will never equal to nid in that while loop because
> > nid_of_current is not set in sgx_numa_mask.
> > 
> > Also worth mentioning is that it's perfectly fine for firmware to not
> > seup an EPC section on a node. Setting an EPC section on each node can
> > be good for performance but that's not a requirement functionality wise.
> 
> The changelog is a little rough, but I think Kai gave some good
> suggestions.  The other thing you can do is dump the text in chatgpt (or
> whatever) and have it fix your grammar.  It actually does a pretty
> decent job.

Thanks for the suggestion.

> 
> Also, you didn't say _how_ you fixed this.  That needs to be in here.
> Something along the lines of:
> 
> 	Rework the loop to start and end on *a* node that has SGX
> 	memory.  This avoids the deadlock looking for the current SGX-
> 	lacking node to show up in the loop when it never will.

Will add this to the changelog, thanks for the write-up.

> 
> The code looks fine, so feel free to add:
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Thanks.

> 
> Also, I do think we should probably add some kind of sanity warning to
> the SGX code in another patch.  If a node on an SGX system has CPUs and
> memory, it's very likely it will also have some EPC.  It can be
> something soft like a pr_info(), but I think it would be nice to have.

I think there are systems with valid reason to not setup an EPC section
per node, e.g. a 8 sockets system with SNC=2, there would be a total of
16 nodes and it's not possible to have one EPC section per node because
the upper limit of EPC sections is 8. I'm not sure a warning is
appropriate here, what do you think?

  reply	other threads:[~2024-08-30  6:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29  2:38 [PATCH] x86/sgx: Fix deadloop in __sgx_alloc_epc_page() Aaron Lu
2024-08-29  7:47 ` Huang, Kai
2024-08-29  7:56 ` Huang, Kai
2024-08-29 13:22   ` Aaron Lu
2024-08-29 15:17 ` Dave Hansen
2024-08-30  6:02   ` Aaron Lu [this message]
2024-08-30 14:03     ` Dave Hansen
2024-09-02  7:57       ` Aaron Lu
2024-08-29 16:44 ` Jarkko Sakkinen
2024-08-30  6:14   ` Aaron Lu
2024-09-03 16:05     ` Jarkko Sakkinen
2024-09-04  1:39       ` Aaron Lu
2024-09-04 14:17         ` Jarkko Sakkinen

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=ZtFgem6_2j05S0MJ@ziqianlu-kbl \
    --to=aaron.lu@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jarkko@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=x86@kernel.org \
    --cc=zhimin.luo@intel.com \
    /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.