From: "Luck, Tony" <tony.luck@intel.com>
To: "Chatre, Reinette" <reinette.chatre@intel.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"bp@alien8.de" <bp@alien8.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Cc: "seanjc@google.com" <seanjc@google.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH V2] x86/sgx: Fix free page accounting
Date: Wed, 10 Nov 2021 19:16:12 +0000 [thread overview]
Message-ID: <bcc3a465dde24f8dab469b4260753e40@intel.com> (raw)
In-Reply-To: <794a7034-f6a7-4aff-7958-b1bd959ced24@intel.com>
>>> The consequence of sgx_nr_free_pages not being protected is that
>>> its value may not accurately reflect the actual number of free
>>> pages on the system, impacting the availability of free pages in
>>> support of many flows. The problematic scenario isu when the
>>
> > In non-atomicity is not a problem, when it is not a problem :-)
This is most definitely a problem.
start with sgx_nr_free_pages == 100
Now have a cpu on node0 allocate a page at the same time as another
cpu on node1 allcoates a page. Each holds the relevent per-node lock,
but that doesn't stop both CPUs from accessing the global together:
CPU on node0 CPU on node1
sgx_nr_free_pages--; sgx_nr_free_pages--;
What is the value of sgx_nr_free_pages now? We want it to be 98,
but it could be 99.
Rinse, repeat thousands of times. Eventually the value of sgx_nr_free_pages
has not even a close connection to the number of free pages.
-Tony
next prev parent reply other threads:[~2021-11-10 19:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 20:00 [PATCH V2] x86/sgx: Fix free page accounting Reinette Chatre
2021-11-10 15:11 ` Jarkko Sakkinen
2021-11-10 18:51 ` Reinette Chatre
2021-11-10 19:16 ` Luck, Tony [this message]
2021-11-11 2:56 ` Jarkko Sakkinen
2021-11-11 2:55 ` Jarkko Sakkinen
2021-11-11 3:26 ` Luck, Tony
2021-11-11 3:50 ` Jarkko Sakkinen
2021-11-11 4:01 ` Dave Hansen
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=bcc3a465dde24f8dab469b4260753e40@intel.com \
--to=tony.luck@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox