public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Arjun Shankar <arjun@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc/release/2.37/master] linux: Use rseq area unconditionally in sched_getcpu (bug 31479)
Date: Mon, 18 Mar 2024 17:49:16 +0000 (GMT)	[thread overview]
Message-ID: <20240318174916.2900F3858C35@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=829b64598bc4e801d2e2878a5d0d0bcbd9314094

commit 829b64598bc4e801d2e2878a5d0d0bcbd9314094
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Mar 15 19:08:24 2024 +0100

    linux: Use rseq area unconditionally in sched_getcpu (bug 31479)
    
    Originally, nptl/descr.h included <sys/rseq.h>, but we removed that
    in commit 2c6b4b272e6b4d07303af25709051c3e96288f2d ("nptl:
    Unconditionally use a 32-byte rseq area").  After that, it was
    not ensured that the RSEQ_SIG macro was defined during sched_getcpu.c
    compilation that provided a definition.  This commit always checks
    the rseq area for CPU number information before using the other
    approaches.
    
    This adds an unnecessary (but well-predictable) branch on
    architectures which do not define RSEQ_SIG, but its cost is small
    compared to the system call.  Most architectures that have vDSO
    acceleration for getcpu also have rseq support.
    
    Fixes: 2c6b4b272e6b4d07303af25709051c3e96288f2d
    Fixes: 1d350aa06091211863e41169729cee1bca39f72f
    Reviewed-by: Arjun Shankar <arjun@redhat.com>
    (cherry picked from commit 7a76f218677d149d8b7875b336722108239f7ee9)
    Fixes: 9da8174362860b4fc564c8ca8c11fc3c51ed1de9

Diff:
---
 sysdeps/unix/sysv/linux/sched_getcpu.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/sysdeps/unix/sysv/linux/sched_getcpu.c b/sysdeps/unix/sysv/linux/sched_getcpu.c
index 4457d714bc..22700ef846 100644
--- a/sysdeps/unix/sysv/linux/sched_getcpu.c
+++ b/sysdeps/unix/sysv/linux/sched_getcpu.c
@@ -33,17 +33,9 @@ vsyscall_sched_getcpu (void)
   return r == -1 ? r : cpu;
 }
 
-#ifdef RSEQ_SIG
 int
 sched_getcpu (void)
 {
   int cpu_id = THREAD_GETMEM_VOLATILE (THREAD_SELF, rseq_area.cpu_id);
   return __glibc_likely (cpu_id >= 0) ? cpu_id : vsyscall_sched_getcpu ();
 }
-#else /* RSEQ_SIG */
-int
-sched_getcpu (void)
-{
-  return vsyscall_sched_getcpu ();
-}
-#endif /* RSEQ_SIG */

                 reply	other threads:[~2024-03-18 17:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20240318174916.2900F3858C35@sourceware.org \
    --to=arjun@sourceware.org \
    --cc=glibc-cvs@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).