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