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 13515 invoked from network); 30 Jun 2020 06:20:01 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 30 Jun 2020 06:20:01 -0000
Received: (qmail 28488 invoked by uid 550); 30 Jun 2020 06:19:53 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 28466 invoked from network); 30 Jun 2020 06:19:52 -0000
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yqxmail.com; s=dkim;
	t=1593497980; bh=CIBsm+rkuWgk7jyrv57SDkNsHP5ykyPJpafLLv5XIis=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=DpXTtwL+AwDSr6CZE7qQ9c8wEp5aQiBNyUERqDlDJS8H8+8MAYDWQFLmDspDt3cw0
	 87mBQCdaNMwc7VNSm2Cx2Ess0WeBOkMgebLFX+JfH84DtFA4ahaXiuA8OJNFRYrKOM
	 xG97nAxpFkk6qjRJ4Q0m/GrhTJlaTY/XpPJao8S8krbHntKnZGHSxXbBbazs+rj58t
	 tMa3xeX38NJ4ucWl100FOrDLnWdDWXrJv8n0WqobZQ5nIqz/mxtzt0jutHX96H8hMD
	 E6rgLTOMuOQWDrVyVZGxsPwBnEahqbOsRPrr3UuGIOd8FZUJJoAzDzMQcr1L5PcoyA
	 nbeytP0eDI/Yw==
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 29 Jun 2020 23:19:39 -0700
From: Hydro Flask <hydroflask@yqxmail.com>
To: musl@lists.openwall.com
Cc: Rich Felker <dalias@libc.org>
In-Reply-To: <20200630044323.GD6430@brightrain.aerifal.cx>
References: <0217b8838100175725993b0ed0114ee7@thelig.ht>
 <20200630044323.GD6430@brightrain.aerifal.cx>
Message-ID: <b3650e579c2b20b6e076e5c0036f7740@yqxmail.com>
Subject: Re: [musl] Potential deadlock in pthread_kill()

>>         int pthread_kill(pthread_t t, int sig)
>>         {
>>                 int r;
>>                 LOCK(t->killlock);
>>                 r = t->tid ? -__syscall(SYS_tkill, t->tid, sig)
>>                         : (sig+0U >= _NSIG ? EINVAL : 0);
>>                 UNLOCK(t->killlock);
>>                 return r;
>>         }
>> 
>> Thank you for your attention.
> 
> Thanks. It looks like this case was overlooked in the pthread_cancel
> fix that was commit 060ed9367337cbbd59a9e5e638a1c2f460192f25. The
> possibility of blocking signals was even mentioned there but deemed
> unnecessary.
> 
> A simpler/lighter fix might be, before the lock,
> 
> 	if (t==__pthread_self())
> 		return -__syscall(SYS_tkill, t->tid, sig);
> 
> since no lock is needed if targeting self; t->tid is necessarily valid
> in that case.

Just to be clear, this doesn't only occur when calling pthread_kill() 
and using pthread_self() as the target, it can be any target thread, as 
long as it's the same target thread is used in the signal handler and in 
the synchronous context.

Looking at the commit message you references, I think the only fix for 
all cases is to block signals before taking the killlock. If there is a 
way to avoid the killlock altogether that would also fix it. Thanks 
again for confirming the issue.

Hydro