[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK3gATfTcQm32MrQV6oMmKfbnTNPKptymjHmhnn2x1CV4S20iA@mail.gmail.com>
Date: Wed, 2 Sep 2026 10:55:30 +0100
From: Ricardo Barreira <rsf@...gle.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] ldso: increase buffer size to fix loading error
with long paths
> Is this an actual issue you are hitting in usage? The current size was
> chosen to allow the filename of the library to be up to the full
> NAME_MAX, and assuming you would not put prefixes longer than that
> (which is already ridiculously large) in your library path.
Yes, we've hit this when using musl as part of the Android kernel
builds (using Bazel as the build system).
Some of our partners building their custom kernels use a quite long
`--output_base` parameter to Bazel. Combined with Bazel adding its own
path components for build hermeticity (preventing path collisions),
this means that libraries can have quite long path names.
>
> The intent of not using PATH_MAX is to avoid clobbering a whole extra
> page of stack that will never again be used at load-time in every
> single dynamic-linked program. But I suppose we could do something
> like pre-scan the search path for the longest component, and size a
> VLA to fit the longest one, if it's really needed to support longer
> path elements.
I see what you mean. This looks non-trivial as it depends on the
details of what happens in the rest of the function and inside
fixup_rpath? It seems tricky but doable.
Regards,
Ricardo
On Tue, 1 Sept 2026 at 14:35, Rich Felker <dalias@...c.org> wrote:
>
> On Tue, Sep 01, 2026 at 11:25:22AM +0000, Ricardo Barreira wrote:
> > path_open_library fills this buffer with a path, so it needs to be
> > sized accordingly with PATH_MAX+1.
> >
> > Signed-off-by: Ricardo Barreira <rsf@...gle.com>
> > ---
> > ldso/dynlink.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> > index 10471b23..32096f55 100644
> > --- a/ldso/dynlink.c
> > +++ b/ldso/dynlink.c
> > @@ -1056,7 +1056,7 @@ static void makefuncdescs(struct dso *p)
> >
> > static struct dso *load_library(const char *name, struct dso *needed_by)
> > {
> > - char buf[2*NAME_MAX+2];
> > + char buf[PATH_MAX+1];
> > const char *pathname;
> > unsigned char *map;
> > struct dso *p, temp_dso = {0};
> > --
> > 2.55.0.897.gb25b4bd76c-goog
>
> Is this an actual issue you are hitting in usage? The current size was
> chosen to allow the filename of the library to be up to the full
> NAME_MAX, and assuming you would not put prefixes longer than that
> (which is already ridiculously large) in your library path.
>
> The intent of not using PATH_MAX is to avoid clobbering a whole extra
> page of stack that will never again be used at load-time in every
> single dynamic-linked program. But I suppose we could do something
> like pre-scan the search path for the longest component, and size a
> VLA to fit the longest one, if it's really needed to support longer
> path elements.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
