Re: [musl] [PATCH v2] MT fork

["Érico Nogueira" <ericonr@disroot.org>]

On Mon Nov 9, 2020 at 10:44 AM -03, Rich Felker wrote:
> On Mon, Nov 09, 2020 at 03:01:24PM -0300, Érico Nogueira wrote:
> > On Mon Nov 9, 2020 at 9:07 AM -03, Rich Felker wrote:
> > > One solution you might actually like: getting rid of
> > > application-provided-malloc use inside libc. This could be achieved by
> > > making malloc a thin wrapper for __libc_malloc or whatever, which
> > > could be called by everything in libc that doesn't actually have a
> > > contract to return "as-if-by-malloc" memory. Only a few functions like
> > > getdelim would be left still calling malloc.
> > 
> > This code block in glob() uses strdup(), which I'd assume would have to
> > use the application provided malloc. Wouldn't that have to be worked
> > around somehow?
> > 
> > 	if (*pat) {
> > 		char *p = strdup(pat);
> > 		if (!p) return GLOB_NOSPACE;
> > 		buf[0] = 0;
> > 		size_t pos = 0;
> > 		char *s = p;
> > 		if ((flags & (GLOB_TILDE | GLOB_TILDE_CHECK)) && *p == '~')
> > 			error = expand_tilde(&s, buf, &pos);
> > 		if (!error)
> > 			error = do_glob(buf, pos, 0, s, flags, errfunc, &tail);
> > 		free(p);
> > 	}
>
> It could either be left using public malloc (imo fine since this is
> not an "internal component of libc" but generic library code with no
> tie-in to libc) or use of strdup could be replaced with a trivial
> alternate version that uses __libc_malloc instead. My leaning would be
> towards the former -- only using libc malloc in places where calling
> the application-provided malloc could lead to recursive locking of
> libc-internal locks (because the caller already holds a libc-internal
> lock) or other "inconsistent state" issues (like dlerror buffers at
> pthread_exit time).

Ok, I think I hadn't understood the problem space completely. Given this
explanation, I would agree that allowing this to use an appliccation
provided malloc is fine, and might even be desirable, since it would
perform as many allocations as possible with the provided allocator.

That said, could this somehow hurt malloc tracking inside libc, be it
with valgrind or sanitizers?