From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14624 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Subject: [PATCH] pthread: Fix bug that pthread_create may cause priority inversion Date: Mon, 9 Sep 2019 16:54:29 +0200 Message-ID: <20190909145429.GG22009@port70.net> References: <59FB1E003EF3A943BD6BAD197ABD4D6A2B5D55@dggemi524-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="1381"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-14640-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 09 16:54:44 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i7L40-0000EL-6l for gllmg-musl@m.gmane.org; Mon, 09 Sep 2019 16:54:44 +0200 Original-Received: (qmail 9853 invoked by uid 550); 9 Sep 2019 14:54:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9829 invoked from network); 9 Sep 2019 14:54:41 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <59FB1E003EF3A943BD6BAD197ABD4D6A2B5D55@dggemi524-mbx.china.huawei.com> Xref: news.gmane.org gmane.linux.lib.musl.general:14624 Archived-At: * zhaohang (F) [2019-09-09 13:57:36 +0000]: > diff --git a/src/thread/pthread_create.c b/src/thread/pthread_create.c > index 7d4dc2e..ae08c0f 100644 > --- a/src/thread/pthread_create.c > +++ b/src/thread/pthread_create.c > @@ -181,15 +181,8 @@ static int start(void *p) > { > struct start_args *args = p; > if (args->attr) { > - pthread_t self = __pthread_self(); > - int ret = -__syscall(SYS_sched_setscheduler, self->tid, > - args->attr->_a_policy, &args->attr->_a_prio); > - if (a_swap(args->perr, ret)==-2) > - __wake(args->perr, 1, 1); > - if (ret) { > - self->detach_state = DT_DETACHED; > - __pthread_exit(0); > - } > + if (a_cas(args->perr, -1, -2) == -1) > + __wait(args->perr, 0, -2, 1); > } > __syscall(SYS_rt_sigprocmask, SIG_SETMASK, &args->sig_mask, 0, _NSIG/8); > __pthread_exit(args->start_func(args->start_arg)); > @@ -367,10 +360,14 @@ int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict att > } > > if (attr._a_sched) { > - if (a_cas(&err, -1, -2)==-1) > - __wait(&err, 0, -2, 1); > - ret = err; > - if (ret) return ret; > + ret = -__syscall(SYS_sched_setscheduler, new->tid, attr._a_policy, &attr._a_prio); > + if (ret) { > + new->detach_state = DT_DETACHED; > + pthread_cancel(new); > + return ret; the child has the cancel signal blocked so it will never act on the signal. but even if that's fixed, the detached child may not get scheduled to handle the signal for a long time and will take up stack/tid resources. i think Rich already has a solution that will deal with these issues. > + } > + if (a_swap(&err, 0) == -2) > + __wake(&err, 1, 1); > } > > *res = new;