public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: libc-alpha@sourceware.org
Subject: [PATCH 10/15] elf: Fix DTV gap reuse logic [BZ #27135]
Date: Mon, 15 Feb 2021 12:01:43 +0000	[thread overview]
Message-ID: <9a591c9dc467341d41766ce388fbb500f8c0bb3e.1613390045.git.szabolcs.nagy@arm.com> (raw)
In-Reply-To: <cover.1613390045.git.szabolcs.nagy@arm.com>

For some reason only dlopen failure caused dtv gaps to be reused.

It is possible that the intent was to never reuse modids for a
different module, but after dlopen failure all gaps are reused
not just the ones caused by the unfinished dlopened.

So the code has to handle reused modids already which seems to
work, however the data races at thread creation and tls access
(see bug 19329 and bug 27111) may be more severe if slots are
reused so this is scheduled after those fixes. I think fixing
the races are not simpler if reuse is disallowed and reuse has
other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are
removed from the middle of the slotinfo list. The value does
not have to be correct: incorrect true value causes the next
modid query to do a slotinfo walk, incorrect false will leave
gaps and new entries are added at the end.

Fixes bug 27135.
---
 elf/dl-close.c |  6 +++++-
 elf/dl-open.c  | 10 ----------
 elf/dl-tls.c   |  5 +----
 3 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/elf/dl-close.c b/elf/dl-close.c
index 3720e47dd1..9f31532f41 100644
--- a/elf/dl-close.c
+++ b/elf/dl-close.c
@@ -88,7 +88,11 @@ remove_slotinfo (size_t idx, struct dtv_slotinfo_list *listp, size_t disp,
       /* If this is not the last currently used entry no need to look
 	 further.  */
       if (idx != GL(dl_tls_max_dtv_idx))
-	return true;
+	{
+	  /* There is an unused dtv entry in the middle.  */
+	  GL(dl_tls_dtv_gaps) = true;
+	  return true;
+	}
     }
 
   while (idx - disp > (disp == 0 ? 1 + GL(dl_tls_static_nelem) : 0))
diff --git a/elf/dl-open.c b/elf/dl-open.c
index 83b8e96a5c..661f26977e 100644
--- a/elf/dl-open.c
+++ b/elf/dl-open.c
@@ -890,16 +890,6 @@ no more namespaces available for dlmopen()"));
 	 state if relocation failed, for example.  */
       if (args.map)
 	{
-	  /* Maybe some of the modules which were loaded use TLS.
-	     Since it will be removed in the following _dl_close call
-	     we have to mark the dtv array as having gaps to fill the
-	     holes.  This is a pessimistic assumption which won't hurt
-	     if not true.  There is no need to do this when we are
-	     loading the auditing DSOs since TLS has not yet been set
-	     up.  */
-	  if ((mode & __RTLD_AUDIT) == 0)
-	    GL(dl_tls_dtv_gaps) = true;
-
 	  _dl_close_worker (args.map, true);
 
 	  /* All l_nodelete_pending objects should have been deleted
diff --git a/elf/dl-tls.c b/elf/dl-tls.c
index c4466bd9fc..b0257185e9 100644
--- a/elf/dl-tls.c
+++ b/elf/dl-tls.c
@@ -187,10 +187,7 @@ _dl_next_tls_modid (void)
 size_t
 _dl_count_modids (void)
 {
-  /* It is rare that we have gaps; see elf/dl-open.c (_dl_open) where
-     we fail to load a module and unload it leaving a gap.  If we don't
-     have gaps then the number of modids is the current maximum so
-     return that.  */
+  /* The count is the max unless dlclose or failed dlopen created gaps.  */
   if (__glibc_likely (!GL(dl_tls_dtv_gaps)))
     return GL(dl_tls_max_dtv_idx);
 
-- 
2.17.1


  parent reply	other threads:[~2021-02-15 12:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 11:56 [PATCH 00/15] Dynamic TLS related data race fixes Szabolcs Nagy
2021-02-15 11:56 ` [PATCH 01/15] aarch64: free tlsdesc data on dlclose [BZ #27403] Szabolcs Nagy
2021-04-01 12:57   ` Adhemerval Zanella
2021-04-06 13:43     ` Szabolcs Nagy
2021-04-06 16:52       ` Adhemerval Zanella
2021-02-15 11:56 ` [PATCH 02/15] elf: Fix data race in _dl_name_match_p [BZ #21349] Szabolcs Nagy
2021-04-01 14:01   ` Adhemerval Zanella
2021-04-06 16:41     ` Szabolcs Nagy
2021-02-15 11:57 ` [PATCH 03/15] Add test case for [BZ #19329] Szabolcs Nagy
2021-04-02 19:10   ` Adhemerval Zanella
2021-02-15 11:59 ` [PATCH 04/15] Add a DTV setup test [BZ #27136] Szabolcs Nagy
2021-04-02 19:35   ` Adhemerval Zanella
2021-02-15 11:59 ` [PATCH 05/15] elf: Fix a DTV setup issue " Szabolcs Nagy
2021-04-02 19:46   ` Adhemerval Zanella
2021-02-15 11:59 ` [PATCH 06/15] elf: Fix comments and logic in _dl_add_to_slotinfo Szabolcs Nagy
2021-04-02 20:50   ` Adhemerval Zanella
2021-04-06 15:48     ` Szabolcs Nagy
2021-04-06 17:47       ` Adhemerval Zanella
2021-04-07  7:57         ` Szabolcs Nagy
2021-04-07 14:20           ` Adhemerval Zanella
2021-02-15 12:00 ` [PATCH 07/15] elf: Refactor _dl_update_slotinfo to avoid use after free Szabolcs Nagy
2021-04-06 19:40   ` Adhemerval Zanella
2021-04-07  8:01     ` Szabolcs Nagy
2021-04-07 14:28       ` Adhemerval Zanella
2021-04-07 14:36         ` Adhemerval Zanella
2021-04-07 17:05   ` Adhemerval Zanella
2021-02-15 12:01 ` [PATCH 08/15] elf: Fix data races in pthread_create and TLS access [BZ #19329] Szabolcs Nagy
2021-02-15 12:01 ` [PATCH 09/15] elf: Use relaxed atomics for racy accesses " Szabolcs Nagy
2021-02-15 12:01 ` Szabolcs Nagy [this message]
2021-02-15 12:02 ` [PATCH 11/15] x86_64: Avoid lazy relocation of tlsdesc [BZ #27137] Szabolcs Nagy
2021-04-09  0:14   ` Ben Woodard
2021-04-09 13:38     ` Szabolcs Nagy
2021-04-09 14:55       ` Ben Woodard
2021-02-15 12:02 ` [PATCH 12/15] i386: " Szabolcs Nagy
2021-02-15 12:02 ` [PATCH 13/15] x86_64: Remove lazy tlsdesc relocation related code Szabolcs Nagy
2021-02-15 12:03 ` [PATCH 14/15] i386: " Szabolcs Nagy
2021-02-15 12:03 ` [PATCH 15/15] elf: " Szabolcs Nagy
2021-02-15 12:08 ` [PATCH 03/15] Add test case for [BZ #19329] Szabolcs Nagy
2021-02-15 12:08 ` [PATCH 06/15] elf: Fix comments and logic in _dl_add_to_slotinfo Szabolcs Nagy
     [not found] ` <CGME20210215115731epcas5p45614957debad2f679230d0bd1efbd57f@epcms5p7>
2021-02-15 12:11   ` [PATCH 02/15] elf: Fix data race in _dl_name_match_p [BZ #21349] Maninder Singh

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=9a591c9dc467341d41766ce388fbb500f8c0bb3e.1613390045.git.szabolcs.nagy@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=libc-alpha@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).