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=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL 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 20E512350A for ; Mon, 27 May 2024 16:56:21 +0200 (CEST) Received: (qmail 27947 invoked by uid 550); 27 May 2024 14:56:17 -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 27900 invoked from network); 27 May 2024 14:56:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1716821768; x=1717426568; i=nullplan@gmx.net; bh=wrYTrPvhR0FB/dbw86OUAvhIkXoeHGioBb1o1hLr1EI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=uCGDkENSZn9DX4zJwxzc+A7LVaKBaU4iAjvZAxZ+lLQW4lPuZzoCqz9qLO6yBJBY zkQT2XEe/+wUWYe9PkIpKscLUU1Co7jAocxDNaiV7+U60iZIxnVTDJ2Qt9Rt2VZeR mwXgTRhY+IQawNSXit1pdbp5TG/f0Ut2HCbytSJE8mNdDC5kdCey69XX+HaxD26or Zw3LgERPVkiBbL/+P2XN9kH5pYzEwFHW1mT7hu0evt4gnLTmuGdJiQ3yagmvlr7Ik KgJ24zTZCdOwaFAB0kAIq/8qykBflYthFqPwgP9f6WqVprsCWr5WoKrEG8Qb81FqQ 0l+5Q6+rI+iMs9HV7w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Mon, 27 May 2024 16:56:06 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: IMMING <2465853002@qq.com> Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:JdKxim7LkJBzxJZ57JTpK2CfHnBBQK3jqDpx29gGHjFlI84XC6e FHLpUuGYMGOlJJ5IuWNs9G30hN6SHkThKcUcmK/aDWFNqWzquTR+3yhC+WwotjCyDGEGTpF oGfy+mqJqbS9cgl2V6nCFOaGEPkgd9WPYWX1oHGa7jTpGYIdyYZnGb6J0XzH5z8ZiW0c3O6 i2Dcwh5CLDmvBVUiGLZbQ== UI-OutboundReport: notjunk:1;M01:P0:4GXXiRn2u0E=;kqo60BAuSaasQZKxTzwbbmAbMSd 30DJuWx1EtqnwHl2rLV+x6tMFzmqdtT5qs4xqWAYp1VGZ2qCYBd+HZ1xlW9R0giyJgNb64J8d ejrV8j4dmnxlTQxv1GnRmza+IVYX0CV7zqLEJZB5u6eYl6C1ERpC2L2ven056LvQCHr9qQeO3 W/Yi1/484ncntnTHqTwx1uiKncikcLF5FThBVR9X+6HUTFOIU+TMVUkIY15eFcGWW/36xbFGN 84JuZUogI6H6C0qXGCU0pnEVtEjv5Ezul9Mes9DRswAVn5/F3+tiFF8i+7Dj6z3HwW0XKgp5T YiUI/46JYyAn4sB3nHAAhIuZv7FKvy44BjGr0YQO7aLIsTig0M1MZCnM8XVstsATmyjc130lA nbLnb3RNuLsuTMkz3LEY0avM/xeM+gGB34z1kMpsKtkxyViUiaaRj4Eq4kDpkYh58qpy4q/Mn yJOHCv97I0H9VNq+JR1N+S9BtQiKWn4zoILMmIAxnaHoeX5IeFY2skP8SNd6mligRWwZQk4Db kwp6dLK5O9PNp35Wz5YEiIOkvFsjolF8qjhfaqyv8H/EUqpsAhCnKKZDa8QnE9Y5v9vKHsXuA v7cdt9vpZ4brIan+rZICdotYx0MtYvrohM3jtNI8kZTFOVMVdFu2s9awpk/X0WLhnIyCH5qWh HUwODsfcq6OBuq3faIvtJPMJB0bGmtgsMvtg8SLhvYXFnWix2hmNFIu12iM4HCl4ZjT5YToIR CR6JNfN8ytjYpCH1eq5iNocapsdRXDBnlr4HdroGeb/YA2VVbldlY/HwHIOWCyPLMgWRTxiIH NXT+c08+IID8BdM4L/eWiiLxapLDhW7l5pGaW27fuuHJg= Subject: Re: [musl] A question about the implementation of pthread_create and start Am Mon, May 27, 2024 at 08:22:42PM +0800 schrieb IMMING: > Hi, I would like to ask a question about the implementation of pthr= ead_create and start =EF=BC=88musl v1.2.5=EF=BC=89 > Bloody hell, please fix your mail client settings to stop emitting these HTML entities in the plain text! Our MUAs are grown up, they can handle non-ASCII if it's properly declared. > My question is, if SYS_sched_setscheduler returns an error (a non-zero > value), the parent thread will remain in a wait state and I have not > found a way to wake it, which will cause the parent thread to remain > stuck in the pthread_create function and unable to return > > 1.Is my analysis process correct? No. The call to SYS_set_tid_address sets the child's TID address to &a->control, and the CLONE_CHILD_CLEARTID flag. This means that as soon as the child exits, the kernel will set that address to 0 and perform a futex wake on it. This is the same mechanism normally used for the thread list on exit. This means that the parent thread will be woken up as soon as the child thread exits. Reason is that this way, the parent thread gets to clean up the child memory by unmapping it. The only other way to achieve the same thing would be to detach the child thread and let it clean up itself. But this has the problem that we would need to publish the child thread in the list, and it would be visible to the other threads, even though it is at that point doomed to exit. So it is just cleaner for the parent to clean up, since the parent needs the cleanup code anyway in case the __clone() fails. > 2.Is the situation where the parent thread gets stuck in the waite as > expected=EF=BC=9F It is not expected that the parent gets stuck indefinitely. Once the failure of sched_setscheduler has been communicated, it is expected that the child should exit quickly, and that's when the parent is woken up. Or have you identified a case where the parent does get stuck forever? Ciao, Markus