From nobody@FreeBSD.org  Tue Feb 10 22:06:15 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D88AB1065672
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 10 Feb 2009 22:06:15 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id C56A68FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 10 Feb 2009 22:06:15 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n1AM6F2o078671
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 10 Feb 2009 22:06:15 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n1AM6FU9078670;
	Tue, 10 Feb 2009 22:06:15 GMT
	(envelope-from nobody)
Message-Id: <200902102206.n1AM6FU9078670@www.freebsd.org>
Date: Tue, 10 Feb 2009 22:06:15 GMT
From: Brad Huntting <huntting@glarp.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: lock_init() assumes zero-filled struct
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         131573
>Category:       kern
>Synopsis:       [mutex] lock_init() assumes zero-filled struct
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 10 22:10:02 UTC 2009
>Closed-Date:    Tue Nov 13 20:55:29 UTC 2012
>Last-Modified:  Tue Nov 13 20:55:29 UTC 2012
>Originator:     Brad Huntting
>Release:        7.1-STABLE
>Organization:
>Environment:
FreeBSD spork.glarp.com 7.1-STABLE FreeBSD 7.1-STABLE #1: Tue Feb 10 11:58:44 MST 2009     root@spork.glarp.com:/usr/src/sys/amd64/compile/SPORK  amd64

>Description:
In /sys/kern/subr_lock.c, the function lock_init() starts out with:

        /* Check for double-init and zero object. */
        KASSERT(!lock_initalized(lock), ("lock \"%s\" %p already initialized",
            name, lock));

This is fine for locks allocated with MALLOC(...,M_ZERO), but locks allocated on the stack (of some kernel thread) are garbage filled which triggers a panic here (assuming you have options INVARIANTS).

The solutions is to either:  (a) document that lock struct's must be zero filled prior to calling {mtx,rw,sx}_init().  Or (b), remove the KASSERT().

Normally, (b) would be the obvious choice, since adding a bzero() before every call to {mtx,rw,sx}_init() defeats the check anyway.  But in most cases, locks are allocated in softc's which are zero filled so there is no need to bzero().  However, even in this case, the check is of questionable value since locks are normally initialized in an attach() function and destroyed in a detach() function.  If you're attach() method is being called twice you have bigger problems that a reinitialized a lock.


brad
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: gavin 
State-Changed-When: Wed Feb 11 11:53:10 UTC 2009 
State-Changed-Why:  
Mark as feedback: I'm not sure this is a bug, although I do understand 
why the submitter believes it is.  I think you're probably best 
bringing this up on the -current mailing list, and getting some 
discussion or a consensus as to if this is correct or not. 
FWIW, a lot of mutexes are not necessarily initialise just in attach 
routines, and I know this check has been triggered before for real 
bugs. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=131573 
State-Changed-From-To: feedback->closed 
State-Changed-By: eadler 
State-Changed-When: Tue Nov 13 20:55:28 UTC 2012 
State-Changed-Why:  
Feedback timeout. Please email me and I will reopen if needed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=131573 
>Unformatted:
