From owner-svn-src-all@FreeBSD.ORG Sun Dec 14 04:06:10 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AD11311; Sun, 14 Dec 2014 04:06:10 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2807F380; Sun, 14 Dec 2014 04:06:10 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so12010909wgh.17 for ; Sat, 13 Dec 2014 20:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XPfzpF/ME1GVcv2XX+5u7nnW+cYDvoTIgiZdkVhVZZ4=; b=kp9dVaN9FB4KHklxfmbj2dwOJ6iqxzWMwmad3X/rRz1igRs9lanIgEjNcW954AxsQB lgQ5A9BIhzByUqmTE2p3nWTnUd/xEHIHuez8Via+xpjAKY2GcqoBTjVELsqUyfyVNYUg 9IePmZGUkwnEMIEyez2KR35lu3YgrDAnAYcq5geEJ43Oee85OGbq5HPJzeQxQQDpUpBY bb8gg0GpvvJ6/V0MuYtsTtCh9S79fPoHrqqv+zX52FrE+A7YvNKc0UZzU66VjmXnBKjZ jaxYXMiJm//rq60zKdzuOLTleULesDc+JDgKBe4qRDagPwyCzFh4VLIvU64poNhIQ0Ec OPkQ== X-Received: by 10.194.90.244 with SMTP id bz20mr40882605wjb.125.1418529968504; Sat, 13 Dec 2014 20:06:08 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id p14sm7970864wie.1.2014.12.13.20.06.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 13 Dec 2014 20:06:07 -0800 (PST) Date: Sun, 14 Dec 2014 05:06:04 +0100 From: Mateusz Guzik To: Benjamin Kaduk Subject: Re: svn commit: r275751 - in head: share/man/man9 sys/kern sys/sys Message-ID: <20141214040604.GA2720@dft-labs.eu> References: <201412132100.sBDL0BvR094009@svn.freebsd.org> <20141213213111.GA2070@dchagin.static.corbina.net> <20141213215011.GA17746@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Chagin Dmitry X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 04:06:10 -0000 On Sat, Dec 13, 2014 at 10:10:18PM -0500, Benjamin Kaduk wrote: > On Sat, 13 Dec 2014, Mateusz Guzik wrote: > > > I think the actual question was when would you call _init_flags and not > > want _NEW and it would have a potential to detect double init. > > That is a fine question to ask, but it is not the one I was trying to ask. > > I can answer yours, though: it detects when buggy code is using > uninitialized memory for a structure that needs initialization. > It detects when provided memory happens to not be zeroed, which may or may not violate a requirement for the structure which contains given lock. I'm guessing the rationale is to simply not have to call malloc with M_ZERO just to satisfy invariants. But then who and where would not want to use this _NEW flag? > If I remember correctly, the need for > https://github.com/openafs/openafs/commit/64da7c133a66a15233c2cdc5d9a8f71d17d80d77 > was detected by this feature of WITNESS. > This sounds valid, but does not answer my concern, see above. > > I think a better approach would be to have a hash with addresses of all > > locks in use. Then _init/_destroy would add/remove it respectively and > > we would not be dependent on the state of the lock (e.g. struct could be > > zeroed by unrelated code and then double init is not detected). > > > > Chains locked separately of course. > > > > I didn't try that, should be totally fine for invariants. > > That is an interesting proposal, which might be better than the current > state of affairs. (I am not signing up to implement it, though.) > Turns out even production code contains some witness-related structs, so growing it just to accomodate for this feature may not be as easy. Someone(tm) will have to check what's the point (I doubt production modules run on debug kernels, at least not reliably). -- Mateusz Guzik