Date: Tue, 28 Dec 2004 09:47:31 +0100 From: Peter Holm <peter@holm.cc> To: Bosko Milekic <bmilekic@technokratis.com> Cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping Message-ID: <20041228084731.GA766@peter.osted.lan> In-Reply-To: <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> <20041227040216.GA44588@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 26, 2004 at 11:02:16PM -0500, Bosko Milekic wrote: > > > 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. > After more than 18 hours of testing with your patch I ran into a (unrelated ?) "panic: mutex vm object not owned": http://www.holm.cc/stress/log/freeze06.html > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org > 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; > -- Peter Holm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228084731.GA766>