From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19516 invoked from network); 9 Nov 2020 19:43:00 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Nov 2020 19:43:00 -0000 Received: (qmail 24463 invoked by uid 550); 9 Nov 2020 19:42:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24445 invoked from network); 9 Nov 2020 19:42:56 -0000 X-Virus-Scanned: Debian amavisd-new at disroot.org Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1604950963; bh=HhlgeSiioRSCHJFy5tqbE3S13fqjPzVU2mpUL3gKwEs=; h=Subject:From:To:Date:In-Reply-To; b=eHIWEDc4lSKsUv4RyzHNgYMtLlo601f3PoCmZuPoI2ub1Mj4AaSapzWCwmJHpQ3cu Mq7gbCCLTLXvh39iXh2EMBmHjswPw9VOUs4q5QXkEaNwzOMEJl5qyrvvDYGhHEiQi5 i6CZojZqIGJRfYeWTPQEvwGh6pUCfr19YB+AKDEARy2fyllFwudNvkqO4fTZBQTGJ7 6hLf0epjUO/LwGfhZFJx7e8w8f5srYq6g8RLlcmsxJ/pvtJG2SO9/nPWvgkt8VE6Y4 mNTVYt0HN2KXbyxMKFJOb6Z3UeiV/TdzKFf17qqH/nYy00xTtIZfy2fQCozo5ugs9X nwQkJ+lfVMpvg== Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=C3=89rico_Nogueira?= To: , Date: Mon, 09 Nov 2020 15:54:55 -0300 Message-Id: In-Reply-To: <20201109184456.GB534@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH v2] MT fork On Mon Nov 9, 2020 at 10:44 AM -03, Rich Felker wrote: > On Mon, Nov 09, 2020 at 03:01:24PM -0300, =C3=89rico 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 b= y > > > 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 lik= e > > > getdelim would be left still calling malloc. > >=20 > > 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? > >=20 > > if (*pat) { > > char *p =3D strdup(pat); > > if (!p) return GLOB_NOSPACE; > > buf[0] =3D 0; > > size_t pos =3D 0; > > char *s =3D p; > > if ((flags & (GLOB_TILDE | GLOB_TILDE_CHECK)) && *p =3D=3D '~') > > error =3D expand_tilde(&s, buf, &pos); > > if (!error) > > error =3D 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?