From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id D12F22477B for ; Sat, 20 Jan 2024 22:32:30 +0100 (CET) Received: (qmail 11316 invoked by uid 550); 20 Jan 2024 21:30:30 -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 11281 invoked from network); 20 Jan 2024 21:30:29 -0000 Date: Sat, 20 Jan 2024 16:32:32 -0500 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20240120213232.GY4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] Split fork and abort locks On Sat, Jan 20, 2024 at 09:12:28AM +0100, Markus Wichmann wrote: > Hi all, > > a while ago I had noticed that __abort_lock was being taken in some > functions that have nothing to do with SIGABRT. Namely in the forking > functions. Investigating this a bit, I noticed that __abort_lock had > become dual purpose. But this is a code smell. > > Actually, there are several locks that have expanded in scope a bit > since their introduction. At least the ptc lock (__inhibit_ptc() et al.) > deserves a closer look later on as well. Seems to me like in case of the > default stack size, that lock is used simply because an rwlock was > needed and this one was around. The scope of this lock has always been modification to state that new thread creation depends on, which is largely "how much storage does a new thread need?" Originally, the relevant state was just the amount of TLS memory needed. With the addition of default stack size control, that also became part of the relevant state. In theory these could be protected by different locks, but I don't see any good reason for splitting them. The reason fork takes the __inhibit_ptc lock is that it has to take all the internal locks; this has nothing to do with the scope of what's protected by the particular lock. Rich