From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, dave.hansen@linux.intel.com,
ebiederm@xmission.com, oleg@redhat.com, bp@alien8.de,
x86@kernel.org, chang.seok.bae@intel.com
Subject: [PATCH] signal: Skip the altstack update when not needed
Date: Thu, 9 Dec 2021 15:24:34 -0800 [thread overview]
Message-ID: <20211209232434.3585-1-chang.seok.bae@intel.com> (raw)
New x86 FPU features require a large signal stack for their large states.
Instead of requiring a large stack for every process, make sure enough
altstack both at sys_sigaltstack() and when enabling the feature in each
process.
The optional size check was added. It helps to reject a too-small altstack
when the large feature is enabled. Also, the architecture code examines
each thread's altstack large enough before enabling the feature.
But threads can be racy without a lock. So, this enforcement mechanism
accompanies a lock to serialize altstack updates and the size check.
On the signal return path, the altstack is restored via do_sigaltstack().
In fact, the threads without altstack ensure it is disabled there. While no
altstack change is needed in this case, this call ends up obtaining the
lock.
When multiple signal returns hit the lock at the same time, this
unnecessarily increases the lock contention.
Add a new check to avoid this. Check if an altstack update is needed. If
not, skip the lock and the update. This may help sys_sigaltstack() in
general. So place it in the function.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 3aac3ebea08f ("x86/signal: Implement sigaltstack size validation")
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
---
kernel/signal.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index a629b11bf3e0..eeb634f954cd 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4185,6 +4185,11 @@ do_sigaltstack (const stack_t *ss, stack_t *oss, unsigned long sp,
ss_mode != 0))
return -EINVAL;
+ if (t->sas_ss_sp == (unsigned long)ss_sp &&
+ t->sas_ss_size == ss_size &&
+ t->sas_ss_flags == ss_flags)
+ return 0;
+
sigaltstack_lock();
if (ss_mode == SS_DISABLE) {
ss_size = 0;
--
2.17.1
next reply other threads:[~2021-12-09 23:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 23:24 Chang S. Bae [this message]
2021-12-09 23:54 ` 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=20211209232434.3585-1-chang.seok.bae@intel.com \
--to=chang.seok.bae@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--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
all inboxes | Powered by JetHome®