From owner-freebsd-current@FreeBSD.ORG Mon Dec 27 04:02:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BE516A4CE for ; Mon, 27 Dec 2004 04:02:20 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0014543D46 for ; Mon, 27 Dec 2004 04:02:19 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBR42G4I045388; Sun, 26 Dec 2004 23:02:16 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBR42GMV045387; Sun, 26 Dec 2004 23:02:16 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Sun, 26 Dec 2004 23:02:16 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041227040216.GA44588@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20041227013745.GA5267@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 04:02:20 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'll have to reserve some more time to think about this. One way I > think it might be solvable would be to change that check that > triggers the NULL return explicitly check for the bucketzone, and not > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > more. Please try the attached patch and let me know if with it you can or cannot trigger the original (seemingly infinite) looping. Although I still haven't quite figured out how the described scenario could lead to infinite looping exactly (I did conclude that it could lead to some looping, though), the patch is worth trying as I believe the scenario *could* occur. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="uma_mwaitok_null.diff" Index: uma_core.c =================================================================== RCS file: /home/ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.111 diff -u -r1.111 uma_core.c --- uma_core.c 26 Dec 2004 00:35:12 -0000 1.111 +++ uma_core.c 27 Dec 2004 03:58:25 -0000 @@ -1939,9 +1939,19 @@ * buckets there too we will recurse in kmem_alloc and bad * things happen. So instead we return a NULL bucket, and make * the code that allocates buckets smart enough to deal with it + * + * XXX: While we want this protection for the bucket zones so that + * recursion from the VM is handled (and the calling code that + * allocates buckets knows how to deal with it), we do not want + * to prevent allocation from the slab header zones (slabzone + * and slabrefzone) if uk_recurse is not zero for them. The + * reason is that it could lead to NULL being returned for + * slab header allocations even in the M_WAITOK case, and the + * caller can't handle that. */ if (keg->uk_flags & UMA_ZFLAG_INTERNAL && keg->uk_recurse != 0) - return (NULL); + if ((zone != slabzone) && (zone != slabrefzone)) + return (NULL); slab = NULL; --BXVAT5kNtrzKuDFl--