[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260902123519.GV23438@brightrain.aerifal.cx>
Date: Wed, 2 Sep 2026 08:35:19 -0400
From: Rich Felker <dalias@...c.org>
To: Ricardo Barreira <rsf@...gle.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] ldso: increase buffer size to fix loading error
with long paths
On Wed, Sep 02, 2026 at 10:55:30AM +0100, Ricardo Barreira wrote:
> > 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.
FWIW, you can guarantee uniqueness deterministically in only 64 bytes
trivially using a cryptographic hash of whatever ridiculously-long
thing is being used, or less if you use base32 or base64 instead of
hex encoding for the hash. This is the smart way to do it because it
saves a lot of time on every single filesystem access using the
excessively long pathname. Even if the tooling doesn't want to play
nice with this, I think you can do it with symlinks; you just don't
get rid of the performance cost of the long pathnames because the
processing still happens when resolving the symlink. I'm not sure if
this is an easier or more painful workaround than patching musl
locally for your needs.
> > 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.
I just took a look at it and the approach I suggested is almost
trivial -- if it weren't for the fact that we don't yet have sys_path
loaded. So I think I need to factor out loading of sys_path so it can
be loaded early to compute the length needed. That's still not bad,
but it's a little more refactoring than I was planning to do in 5
minutes of looking at it.
If there's demand for supporting long path components, I'll get back
to this, but it might not be right away.
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.
