Date: Mon, 1 Apr 2013 14:30:52 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Yuri <yuri@rawbw.com>, FreeBSD Hackers <hackers@freebsd.org> Subject: Re: helgrind (valgrind plugin) errors coming from nsdispatch(3) Message-ID: <201304011430.52414.jhb@freebsd.org> In-Reply-To: <514FCEF3.8070902@rawbw.com> References: <514FCEF3.8070902@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304011430.52414.jhb>