From owner-freebsd-bugs@FreeBSD.ORG Sun Feb 2 14:00:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD348A43 for ; Sun, 2 Feb 2014 14:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3B91E9E for ; Sun, 2 Feb 2014 14:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s12E01FQ013130 for ; Sun, 2 Feb 2014 14:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s12E00db013129; Sun, 2 Feb 2014 14:00:00 GMT (envelope-from gnats) Date: Sun, 2 Feb 2014 14:00:00 GMT Message-Id: <201402021400.s12E00db013129@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Eugene Grosbein Subject: Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Eugene Grosbein List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:00:01 -0000 The following reply was made to PR kern/186362; it has been noted by GNATS. From: Eugene Grosbein To: Andriy Gapon Cc: bug-followup@FreeBSD.org Subject: Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL Date: Sun, 02 Feb 2014 20:54:24 +0700 On 02.02.2014 19:55, Andriy Gapon wrote: > > NULL check would be redundant there as it is already established that the lock > is owned and thus must have an owner. > What seems to be happening that is that the thread is trying to acquire a lock > that has been corrupted somehow. E.g. never initialized or its memory location > overwritten. > > Better diagnostics for that case when INVARIANTS are enabled is warranted though. > > Returning to the main issue, I wonder if the following message are related to > the problem: > > module_register: module mac_portacl already exists! > Module mac_portacl failed to register: 17 > > I seem to recall that in some cases our kernel module loading infrastructure may > refuse to load a duplicate module, bu nevertheless re-resolve a symbol name to > point to a symbol in the duplicate module rather than in the original. Which is > a bug, of course. I've disabled loading of mac_portacl in loader.conf keeping options MAC_PORTACL in my kernel and panic is no more. Do you still need additional INVARIANTS-enabled debug info? Eugene Grosbein