From owner-freebsd-bugs@FreeBSD.ORG Sun Feb 2 13:00:01 2014 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D0FD90F for ; Sun, 2 Feb 2014 13: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 6A2AB1A4A for ; Sun, 2 Feb 2014 13: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 s12D01m4099799 for ; Sun, 2 Feb 2014 13: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 s12D01TK099798; Sun, 2 Feb 2014 13:00:01 GMT (envelope-from gnats) Date: Sun, 2 Feb 2014 13:00:01 GMT Message-Id: <201402021300.s12D01TK099798@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Andriy Gapon 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: Andriy Gapon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 13:00:01 -0000 The following reply was made to PR kern/186362; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, eugen@grosbein.net Cc: Subject: Re: kern/186362: [panic] _mtx_lock_sleep() misses check for NULL Date: Sun, 02 Feb 2014 14:55:28 +0200 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. -- Andriy Gapon