From owner-cvs-src@FreeBSD.ORG Fri Mar 31 10:36:37 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org 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 5CE4A16A400; Fri, 31 Mar 2006 10:36:37 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B77143D45; Fri, 31 Mar 2006 10:36:37 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id k2VAaaZd059070; Fri, 31 Mar 2006 10:36:37 GMT (envelope-from ariff@repoman.freebsd.org) Received: (from ariff@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id k2VAaamv059069; Fri, 31 Mar 2006 10:36:36 GMT (envelope-from ariff) Message-Id: <200603311036.k2VAaamv059069@repoman.freebsd.org> From: Ariff Abdullah Date: Fri, 31 Mar 2006 10:36:36 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/dev/sound/pcm sound.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 31 Mar 2006 10:36:37 -0000 ariff 2006-03-31 10:36:36 UTC FreeBSD src repository Modified files: sys/dev/sound/pcm sound.c Log: MEGA Fixes / Cleanup -------------------- - Seal the fate of long standing memory leak (4 years, 7 months) during pcm_unregister(). While destroying cdevs, scan / detect possible children and free its SLIST placeholder properly. - Optimize channel allocation / numbering even further. Do brute cyclic checking only if the channel numbering screwed. - Mega vchan create/destroy cleanup: o Implement pcm_setvchans() so everybody can use it freely instead of implementing their own, be it through sysctl or channel auto allocation. o Increase vchan creation/destruction resiliency: + it's possible to increase/decrease total vchans even during busy playback/recording. Busy channel will be left alone, untouched. Abusive test sample: # play whatever... # while : ; do sysctl hw.snd.pcm0.vchans=1 sysctl hw.snd.pcm0.vchans=10 sysctl hw.snd.pcm0.vchans=100 sysctl hw.snd.pcm0.vchans=200 done # Play something else, leave above loop running frantically. + Seal another 4 years old bug where it is possible to destroy (virtual) channel even when its cdevs being referenced by other process. The "First Come First Served" nature of dsp_clone() is the main culprit of this issue, and usually manifest itself as dangling channel <-> process association. Ensure that all of its cdevs are free from being referenced before destroying it (through ORPHAN_CDEVT() macross). All these fixes (including previous fixes) will be MFCed, later. Revision Changes Path 1.103 +239 -300 src/sys/dev/sound/pcm/sound.c