From owner-cvs-src@FreeBSD.ORG Wed Aug 11 22:30:31 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6849C16A4CE; Wed, 11 Aug 2004 22:30:31 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE5C43D45; Wed, 11 Aug 2004 22:30:31 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i7BMUT8g077255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 11 Aug 2004 18:30:30 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i7BMUTfr077252; Wed, 11 Aug 2004 18:30:29 -0400 (EDT) (envelope-from wollman) Date: Wed, 11 Aug 2004 18:30:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200408112230.i7BMUTfr077252@khavrinen.lcs.mit.edu> To: Andre Oppermann In-Reply-To: <411A60D4.7C25D34E@freebsd.org> References: <20040811175052.GA37093@freefall.freebsd.org> <411A60D4.7C25D34E@freebsd.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_divert.c raw_ip.ctcp_hostcache.c tcp_subr.c tcp_syncache.c udp_usrreq.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 22:30:31 -0000 < said: > In all cases the zone is used as kmalloc replacement. It always > initializes a newly allocated object. It always unlinks the object > from any lists before it uma_zfree's it. All such operations are > covered by mutexes, no concurrent access should happen. If there > is any use-after-free then it is a bug that needs to be fixed. No, it is an intentional design choice, not a bug. Lock-free synchronization is good, particularly when you're copying out a giant wodge of PCBs to userland (or doing anything else that might take a really long time). Locks should not be held during this process. -GAWollman