From owner-freebsd-hackers@FreeBSD.ORG  Mon Apr  1 19:02:02 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id EFB45E9E;
 Mon,  1 Apr 2013 19:02:02 +0000 (UTC) (envelope-from jhb@freebsd.org)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
 by mx1.freebsd.org (Postfix) with ESMTP id D04929CA;
 Mon,  1 Apr 2013 19:02:02 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [209.249.190.124])
 by bigwig.baldwin.cx (Postfix) with ESMTPSA id 54EB0B990;
 Mon,  1 Apr 2013 15:02:02 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: freebsd-hackers@freebsd.org
Subject: Re: helgrind (valgrind plugin) errors coming from nsdispatch(3)
Date: Mon, 1 Apr 2013 14:30:52 -0400
User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; )
References: <514FCEF3.8070902@rawbw.com>
In-Reply-To: <514FCEF3.8070902@rawbw.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201304011430.52414.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
 (bigwig.baldwin.cx); Mon, 01 Apr 2013 15:02:02 -0400 (EDT)
Cc: Yuri <yuri@rawbw.com>, FreeBSD Hackers <hackers@freebsd.org>
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 19:02:03 -0000

On Monday, March 25, 2013 12:13:39 am Yuri wrote:
> While running helgrind on my program, I observed several errors that 
> stem from the nsdispatch calls, see helgrind log below.
> "lock order" error in helgrind is generated when some data is protected 
> by two mutexes, and they were locked in different order on different 
> occasions.
> I think, mutexes in question are nss_lock and conf_lock in 
> lib/libc/net/nsdispatch.c
> 
> It seems like authors of helgrind took an approach that such situation 
> is error prone in general, thus they point it out.
> 
> So what would be the prevalent judgement here, is this something worth 
> fixing in libc, or such errors should be ignored?

Hmm, try locks don't block, so if the only use of the mutex is try locks
and the caller unwinds and releases the rwlock if the mutex try lock fails, no 
deadlock is possible.  The WITNESS checker in the kernel ignores try locks 
when checking for lock order reversals for this reason.

-- 
John Baldwin