From owner-freebsd-threads@FreeBSD.ORG  Mon Dec  8 08:21:44 2003
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
Delivered-To: freebsd-threads@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 59C2B16A4CE
	for <threads@FreeBSD.org>; Mon,  8 Dec 2003 08:21:44 -0800 (PST)
Received: from bbnest.net (m208023.ap.plala.or.jp [219.164.208.23])
	by mx1.FreeBSD.org (Postfix) with ESMTP id E6C7A43F85
	for <threads@FreeBSD.org>; Mon,  8 Dec 2003 08:21:42 -0800 (PST)
	(envelope-from bland@FreeBSD.org)
Received: from FreeBSD.org (bland@localhost [127.0.0.1])
	by bbnest.net (8.12.10/8.12.10) with ESMTP id hB8Folj2054681
	for <threads@FreeBSD.org>; Tue, 9 Dec 2003 00:50:47 +0900 (JST)
	(envelope-from bland@FreeBSD.org)
Message-ID: <3FD49DD7.60409@FreeBSD.org>
Date: Tue, 09 Dec 2003 00:50:47 +0900
From: Alexander Nedotsukov <bland@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031104
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: threads@FreeBSD.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Minor pthrerad_mutex_unlock() issue
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2003 16:21:44 -0000

Guys,

During recent bug hunting in ports I found wired (or better to say as I 
think incorrect) behaviour of mutex unlocking code. Final unlock in code 
snippet given bellow will fail with EINVAL. There is special '?' switch 
in thr_mutex.c:mutex_lock_common() wich proceses mutexes with 0 
initialized m_owner field this way. Normally it should rerturn EPERM I 
guess. It was confusing to see EINVAL return from pthread_cond_wait() as 
a side effect of this. I was looking for some memory corruption instead 
of realizing that simply there is no prior mutex locking took place :-(

#include <stdio.h>
#include <pthread.h>
int main()
{
pthread_mutex_t m;
pthread_mutex_init(&m, NULL);
printf("%d", pthread_mutex_unlock(&m));
return 0;
}

I propose to remove special procesing for m_owner == NULL. Simple != 
curthread will be enough to report EPERM.

All the best,
Alexander.
ps.
Btw, pthread_cond_*() man pages need to be updated to indicate that 
there is EPERM return code possible.