From owner-svn-src-all@FreeBSD.ORG Sun Dec 14 03:15:30 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 16AF2ACA; Sun, 14 Dec 2014 03:15:30 +0000 (UTC) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7FEC4EE9; Sun, 14 Dec 2014 03:15:29 +0000 (UTC) X-AuditID: 12074422-f79476d000000d9e-17-548cff9edf45 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C2.76.03486.E9FFC845; Sat, 13 Dec 2014 22:10:22 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sBE3ALDI024518; Sat, 13 Dec 2014 22:10:21 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBE3AJOq012339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Dec 2014 22:10:20 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBE3AIae005928; Sat, 13 Dec 2014 22:10:18 -0500 (EST) Date: Sat, 13 Dec 2014 22:10:18 -0500 (EST) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: Mateusz Guzik Subject: Re: svn commit: r275751 - in head: share/man/man9 sys/kern sys/sys In-Reply-To: <20141213215011.GA17746@dft-labs.eu> Message-ID: References: <201412132100.sBDL0BvR094009@svn.freebsd.org> <20141213213111.GA2070@dchagin.static.corbina.net> <20141213215011.GA17746@dft-labs.eu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1p33vyfE4N9OCYvTs1+yWTQeXMxi 8ad9CpDYtJDVounLAiYHVo8Zn+azeOycdZc9gCmKyyYlNSezLLVI3y6BK+Perlb2gpscFa9e n2FvYPzN1sXIySEhYCLx8s1xVghbTOLCvfVAcS4OIYHFTBIv/y1lh3A2Mkr8WtUO5Rxikug6 OIcJwmlglJi/aR0LSD+LgLbEvhPPwGaxCahJPN7bDDVXUWLzqUnMILaIgKrE86PrWUGamQVe Mkoc2b4PrEhYwFvi2OddYEdxChhKfHo5iQnE5hVwlNi28QzU6muMEvdOfmcHSYgK6Eis3j+F BaJIUOLkzCdgNrOAlsTy6dtYJjAKzUKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGu qV5uZoleakrpJkZQmLO7KO1g/HlQ6RCjAAejEg+vRW93iBBrYllxZe4hRkkOJiVR3opHPSFC fEn5KZUZicUZ8UWlOanFhxglOJiVRHj7vgPleFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRm p6YWpBbBZGU4OJQkeFX/ATUKFqWmp1akZeaUIKSZODhBhvMADU8CqeEtLkjMLc5Mh8ifYlSU Eud1A0kIgCQySvPgemFp6BWjONArwrx1IFU8wBQG1/0KaDAT0ODLjGCDSxIRUlINjI6LTjWI mMl9EilY8pCT//ilh/OOm3AWxc5+dZHvubzuDg875UXs/e7PTxfOyTSQ2nC5RGCOytSUPcdn fsguDtpiKRvt935Wj1zxxVniN38rHfUu6vi1bv3Mt5sefTiwqdbQXUj8XHA7x1MFjRvr7ZdN 22Z4a9K9hwxhXnM9ym4ozv6pEVHEVq/EUpyRaKjFXFScCAB4i1izHgMAAA== 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 03:15:30 -0000 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. If I remember correctly, the need for https://github.com/openafs/openafs/commit/64da7c133a66a15233c2cdc5d9a8f71d17d80d77 was detected by this feature of WITNESS. > 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.) -Ben