public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH v3 1/2] elf: Port ldconfig away from stack-allocated paths
@ 2023-06-17 16:40 Sergey Bugaev
  2023-06-17 16:40 ` [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific Sergey Bugaev
  0 siblings, 1 reply; 9+ messages in thread
From: Sergey Bugaev @ 2023-06-17 16:40 UTC (permalink / raw)
  To: libc-alpha; +Cc: Adhemerval Zanella, Florian Weimer

ldconfig was allocating PATH_MAX bytes on the stack for the library file
name. The issues with PATH_MAX usage are well documented [0][1]; even if
a program does not rely on paths being limited to PATH_MAX bytes,
allocating 4096 bytes on the stack for paths that are typically rather
short (strlen ("/lib64/libc.so.6") is 16) is wasteful and dangerous.

[0]: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html
[1]: https://eklitzke.org/path-max-is-tricky

Instead, make use of asprintf to dynamically allocate memory of just the
right size on the heap.

Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
---

The only change since v2: Simplified logic a bit by useing xstrdup + an
unconditional free, as suggested by Florian. This is slightly less
efficient, but then so is using heap memory instead of alloca, so, fine.

I kept Adhemerval's Reviewed-by (again), but I'm not sure if that is the
appropriate thing to do. In general, what am I supposed to do when
getting a R-b from someone? (other than understanding that the person
approves the patch)

* Am I supposed to re-send the series with the R-b added and no other
  changes? (Pushing a new version is what I would do when using a
  branch-based workflow like that of GitLab merge requests.)
* Am I supposed to add the R-b the next time I send the series, but only
  if I made no changes to that particular patch?
* Am I supposed to add the R-b the next time I send the series, but only
  if I made minor or no changes to that particular patch, and the
  reviewer can be reasonably assumed to still be happy with it?
  (This variant makes most sense to me.)
* Am I supposed to just change nothing? -- in this case, would the
  eventual committer (the person who pushes the patch) collect and
  append the R-b's that the patch has received?

Sergey

 elf/ldconfig.c | 59 +++++++++++++++++++-------------------------------
 1 file changed, 22 insertions(+), 37 deletions(-)

diff --git a/elf/ldconfig.c b/elf/ldconfig.c
index 349b7356..d26eef1f 100644
--- a/elf/ldconfig.c
+++ b/elf/ldconfig.c
@@ -677,28 +677,18 @@ search_dir (const struct dir_entry *entry)
 
   char *dir_name;
   char *real_file_name;
-  size_t real_file_name_len;
-  size_t file_name_len = PATH_MAX;
-  char *file_name = alloca (file_name_len);
+  char *file_name;
   if (opt_chroot != NULL)
-    {
-      dir_name = chroot_canon (opt_chroot, entry->path);
-      real_file_name_len = PATH_MAX;
-      real_file_name = alloca (real_file_name_len);
-    }
+    dir_name = chroot_canon (opt_chroot, entry->path);
   else
-    {
-      dir_name = entry->path;
-      real_file_name_len = 0;
-      real_file_name = file_name;
-    }
+    dir_name = entry->path;
 
   DIR *dir;
   if (dir_name == NULL || (dir = opendir (dir_name)) == NULL)
     {
       if (opt_verbose)
 	error (0, errno, _("Can't open directory %s"), entry->path);
-      if (opt_chroot != NULL && dir_name != NULL)
+      if (opt_chroot != NULL)
 	free (dir_name);
       return;
     }
@@ -733,25 +723,16 @@ search_dir (const struct dir_entry *entry)
 			 + 1, ".#prelink#.", sizeof (".#prelink#.") - 1) == 0)
 	    continue;
 	}
-      len += strlen (entry->path) + 2;
-      if (len > file_name_len)
-	{
-	  file_name_len = len;
-	  file_name = alloca (file_name_len);
-	  if (!opt_chroot)
-	    real_file_name = file_name;
-	}
-      sprintf (file_name, "%s/%s", entry->path, direntry->d_name);
+      if (asprintf (&file_name, "%s/%s", entry->path, direntry->d_name) < 0)
+	error (EXIT_FAILURE, errno, _("Could not form library path"));
       if (opt_chroot != NULL)
 	{
-	  len = strlen (dir_name) + strlen (direntry->d_name) + 2;
-	  if (len > real_file_name_len)
-	    {
-	      real_file_name_len = len;
-	      real_file_name = alloca (real_file_name_len);
-	    }
-	  sprintf (real_file_name, "%s/%s", dir_name, direntry->d_name);
+	  if (asprintf (&real_file_name, "%s/%s",
+			dir_name, direntry->d_name) < 0)
+	    error (EXIT_FAILURE, errno, _("Could not form library path"));
 	}
+      else
+	real_file_name = xstrdup (file_name);
 
       struct stat lstat_buf;
       /* We optimize and try to do the lstat call only if needed.  */
@@ -761,7 +742,7 @@ search_dir (const struct dir_entry *entry)
 	if (__glibc_unlikely (lstat (real_file_name, &lstat_buf)))
 	  {
 	    error (0, errno, _("Cannot lstat %s"), file_name);
-	    continue;
+	    goto next;
 	  }
 
       struct stat stat_buf;
@@ -778,7 +759,7 @@ search_dir (const struct dir_entry *entry)
 		{
 		  if (strstr (file_name, ".so") == NULL)
 		    error (0, 0, _("Input file %s not found.\n"), file_name);
-		  continue;
+		  goto next;
 		}
 	    }
 	  if (__glibc_unlikely (stat (target_name, &stat_buf)))
@@ -793,7 +774,7 @@ search_dir (const struct dir_entry *entry)
 	      if (opt_chroot != NULL)
 		free (target_name);
 
-	      continue;
+	      goto next;
 	    }
 
 	  if (opt_chroot != NULL)
@@ -806,7 +787,7 @@ search_dir (const struct dir_entry *entry)
 	  lstat_buf.st_ctime = stat_buf.st_ctime;
 	}
       else if (!S_ISREG (lstat_buf.st_mode))
-	continue;
+	goto next;
 
       char *real_name;
       if (opt_chroot != NULL && is_link)
@@ -816,7 +797,7 @@ search_dir (const struct dir_entry *entry)
 	    {
 	      if (strstr (file_name, ".so") == NULL)
 		error (0, 0, _("Input file %s not found.\n"), file_name);
-	      continue;
+	      goto next;
 	    }
 	}
       else
@@ -828,7 +809,7 @@ search_dir (const struct dir_entry *entry)
 	  && __builtin_expect (lstat (real_file_name, &lstat_buf), 0))
 	{
 	  error (0, errno, _("Cannot lstat %s"), file_name);
-	  continue;
+	  goto next;
 	}
 
       /* First search whether the auxiliary cache contains this
@@ -842,7 +823,7 @@ search_dir (const struct dir_entry *entry)
 	    {
 	      if (real_name != real_file_name)
 		free (real_name);
-	      continue;
+	      goto next;
 	    }
 	  else if (opt_build_cache)
 	    add_to_aux_cache (&lstat_buf, flag, isa_level, soname);
@@ -948,6 +929,10 @@ search_dir (const struct dir_entry *entry)
 	  dlib_ptr->next = dlibs;
 	  dlibs = dlib_ptr;
 	}
+
+    next:
+      free (file_name);
+      free (real_file_name);
     }
 
   closedir (dir);
-- 
2.41.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-17 16:40 [PATCH v3 1/2] elf: Port ldconfig away from stack-allocated paths Sergey Bugaev
@ 2023-06-17 16:40 ` Sergey Bugaev
  2023-06-21 13:28   ` Adhemerval Zanella Netto
  2023-06-26 19:39   ` Joseph Myers
  0 siblings, 2 replies; 9+ messages in thread
From: Sergey Bugaev @ 2023-06-17 16:40 UTC (permalink / raw)
  To: libc-alpha

These files could be useful to any port that wants to use ld.so.cache.

Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
---
 sysdeps/{unix/sysv/linux => }/x86/readelflib.c  | 0
 sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename sysdeps/{unix/sysv/linux => }/x86/readelflib.c (100%)
 rename sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h (100%)

diff --git a/sysdeps/unix/sysv/linux/x86/readelflib.c b/sysdeps/x86/readelflib.c
similarity index 100%
rename from sysdeps/unix/sysv/linux/x86/readelflib.c
rename to sysdeps/x86/readelflib.c
diff --git a/sysdeps/unix/sysv/linux/x86_64/dl-cache.h b/sysdeps/x86_64/dl-cache.h
similarity index 100%
rename from sysdeps/unix/sysv/linux/x86_64/dl-cache.h
rename to sysdeps/x86_64/dl-cache.h
-- 
2.41.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-17 16:40 ` [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific Sergey Bugaev
@ 2023-06-21 13:28   ` Adhemerval Zanella Netto
  2023-06-23 12:36     ` Sergey Bugaev
  2023-06-26 19:39   ` Joseph Myers
  1 sibling, 1 reply; 9+ messages in thread
From: Adhemerval Zanella Netto @ 2023-06-21 13:28 UTC (permalink / raw)
  To: Sergey Bugaev, libc-alpha



On 17/06/23 13:40, Sergey Bugaev via Libc-alpha wrote:
> These files could be useful to any port that wants to use ld.so.cache.
> 
> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>

LGTM, thanks.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> ---
>  sysdeps/{unix/sysv/linux => }/x86/readelflib.c  | 0
>  sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>  rename sysdeps/{unix/sysv/linux => }/x86/readelflib.c (100%)
>  rename sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h (100%)
> 
> diff --git a/sysdeps/unix/sysv/linux/x86/readelflib.c b/sysdeps/x86/readelflib.c
> similarity index 100%
> rename from sysdeps/unix/sysv/linux/x86/readelflib.c
> rename to sysdeps/x86/readelflib.c
> diff --git a/sysdeps/unix/sysv/linux/x86_64/dl-cache.h b/sysdeps/x86_64/dl-cache.h
> similarity index 100%
> rename from sysdeps/unix/sysv/linux/x86_64/dl-cache.h
> rename to sysdeps/x86_64/dl-cache.h

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-21 13:28   ` Adhemerval Zanella Netto
@ 2023-06-23 12:36     ` Sergey Bugaev
  2023-06-23 12:46       ` Adhemerval Zanella Netto
  0 siblings, 1 reply; 9+ messages in thread
From: Sergey Bugaev @ 2023-06-23 12:36 UTC (permalink / raw)
  To: Adhemerval Zanella Netto; +Cc: libc-alpha

Hello,

On Wed, Jun 21, 2023 at 4:28 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
> LGTM, thanks.
>
> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

Thanks.

So assuming everyone is happy with this patchset now, what is the
process for getting it pushed? Do I need to ping anyone specific?
Previously Samuel pushed my patches after reviewing them, but I
imagine that wouldn't be the case for patches that are not
Hurd-specific.

(And please also reply to the question about Reviewed-by in the previous patch!)

Sergey

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-23 12:36     ` Sergey Bugaev
@ 2023-06-23 12:46       ` Adhemerval Zanella Netto
  0 siblings, 0 replies; 9+ messages in thread
From: Adhemerval Zanella Netto @ 2023-06-23 12:46 UTC (permalink / raw)
  To: Sergey Bugaev; +Cc: libc-alpha



On 23/06/23 09:36, Sergey Bugaev wrote:
> Hello,
> 
> On Wed, Jun 21, 2023 at 4:28 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>> LGTM, thanks.
>>
>> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> 
> Thanks.
> 
> So assuming everyone is happy with this patchset now, what is the
> process for getting it pushed? Do I need to ping anyone specific?
> Previously Samuel pushed my patches after reviewing them, but I
> imagine that wouldn't be the case for patches that are not
> Hurd-specific.
> 
> (And please also reply to the question about Reviewed-by in the previous patch!)

I will take care of this.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-17 16:40 ` [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific Sergey Bugaev
  2023-06-21 13:28   ` Adhemerval Zanella Netto
@ 2023-06-26 19:39   ` Joseph Myers
  2023-06-26 19:50     ` Adhemerval Zanella Netto
  2023-06-26 20:05     ` Sergey Bugaev
  1 sibling, 2 replies; 9+ messages in thread
From: Joseph Myers @ 2023-06-26 19:39 UTC (permalink / raw)
  To: Sergey Bugaev; +Cc: libc-alpha

On Sat, 17 Jun 2023, Sergey Bugaev via Libc-alpha wrote:

> These files could be useful to any port that wants to use ld.so.cache.
> 
> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
> ---
>  sysdeps/{unix/sysv/linux => }/x86/readelflib.c  | 0
>  sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>  rename sysdeps/{unix/sysv/linux => }/x86/readelflib.c (100%)
>  rename sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h (100%)

This broke the build for x32.

In file included from dl-cache.c:23:
../sysdeps/unix/sysv/linux/x86_64/x32/dl-cache.h:19:10: fatal error: sysdeps/unix/sysv/linux/x86_64/dl-cache.h: No such file or directory
   19 | #include <sysdeps/unix/sysv/linux/x86_64/dl-cache.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-26 19:39   ` Joseph Myers
@ 2023-06-26 19:50     ` Adhemerval Zanella Netto
  2023-06-26 20:05     ` Sergey Bugaev
  1 sibling, 0 replies; 9+ messages in thread
From: Adhemerval Zanella Netto @ 2023-06-26 19:50 UTC (permalink / raw)
  To: libc-alpha



On 26/06/23 16:39, Joseph Myers wrote:
> On Sat, 17 Jun 2023, Sergey Bugaev via Libc-alpha wrote:
> 
>> These files could be useful to any port that wants to use ld.so.cache.
>>
>> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
>> ---
>>  sysdeps/{unix/sysv/linux => }/x86/readelflib.c  | 0
>>  sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h | 0
>>  2 files changed, 0 insertions(+), 0 deletions(-)
>>  rename sysdeps/{unix/sysv/linux => }/x86/readelflib.c (100%)
>>  rename sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h (100%)
> 
> This broke the build for x32.
> 
> In file included from dl-cache.c:23:
> ../sysdeps/unix/sysv/linux/x86_64/x32/dl-cache.h:19:10: fatal error: sysdeps/unix/sysv/linux/x86_64/dl-cache.h: No such file or directory
>    19 | #include <sysdeps/unix/sysv/linux/x86_64/dl-cache.h>
>       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 

It is a straightforward change, I will install a fix.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-26 19:39   ` Joseph Myers
  2023-06-26 19:50     ` Adhemerval Zanella Netto
@ 2023-06-26 20:05     ` Sergey Bugaev
  2023-06-26 20:09       ` Sergey Bugaev
  1 sibling, 1 reply; 9+ messages in thread
From: Sergey Bugaev @ 2023-06-26 20:05 UTC (permalink / raw)
  To: Joseph Myers; +Cc: libc-alpha

On Mon, Jun 26, 2023 at 10:39 PM Joseph Myers <joseph@codesourcery.com> wrote:
> This broke the build for x32.
>
> In file included from dl-cache.c:23:
> ../sysdeps/unix/sysv/linux/x86_64/x32/dl-cache.h:19:10: fatal error: sysdeps/unix/sysv/linux/x86_64/dl-cache.h: No such file or directory
>    19 | #include <sysdeps/unix/sysv/linux/x86_64/dl-cache.h>
>       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thank you :|

Would just #include_next <dl-cache.h> work here? Otherwise, it's
#include <sysdeps/x86_64/dl-cache.h> now.

I'll send a patch.

Sergey

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific
  2023-06-26 20:05     ` Sergey Bugaev
@ 2023-06-26 20:09       ` Sergey Bugaev
  0 siblings, 0 replies; 9+ messages in thread
From: Sergey Bugaev @ 2023-06-26 20:09 UTC (permalink / raw)
  To: Joseph Myers; +Cc: libc-alpha, Adhemerval Zanella

On Mon, Jun 26, 2023 at 11:05 PM Sergey Bugaev <bugaevc@gmail.com> wrote:
> I'll send a patch.

Ah, I see Adhemerval has fixed it already.

Sergey

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-06-26 20:09 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-17 16:40 [PATCH v3 1/2] elf: Port ldconfig away from stack-allocated paths Sergey Bugaev
2023-06-17 16:40 ` [PATCH v3 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific Sergey Bugaev
2023-06-21 13:28   ` Adhemerval Zanella Netto
2023-06-23 12:36     ` Sergey Bugaev
2023-06-23 12:46       ` Adhemerval Zanella Netto
2023-06-26 19:39   ` Joseph Myers
2023-06-26 19:50     ` Adhemerval Zanella Netto
2023-06-26 20:05     ` Sergey Bugaev
2023-06-26 20:09       ` Sergey Bugaev

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).