From owner-cvs-all Wed Dec 13 0: 5:27 2000 From owner-cvs-all@FreeBSD.ORG Wed Dec 13 00:05:21 2000 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 82FD937B400; Wed, 13 Dec 2000 00:05:21 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5H00848YGS5P@field.videotron.net>; Wed, 13 Dec 2000 03:05:16 -0500 (EST) Date: Wed, 13 Dec 2000 03:06:27 -0500 (EST) From: Bosko Milekic Subject: Re: cvs commit: src/sys/sys mbuf.h In-reply-to: <20001212221703.V16205@fw.wintelcom.net> To: Alfred Perlstein Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 12 Dec 2000, Alfred Perlstein wrote: > * Bosko Milekic [001212 21:13] wrote: > > bmilekic 2000/12/12 21:13:03 PST > > > > Modified files: > > sys/sys mbuf.h > > Log: > > Eliminate a race in MEXTFREE(). The reference counter decrement and test > > was not atomic. We now make sure that we free the ext buf if the reference > > count is about to reach 0 but also make sure that nobody else has done it > > before us. > > > > While I'm here, change refcnt to u_int (from long). This fixes a compiler > > warning regarding use of atomic_cmpset_long on i386. > > > > Submitted by: jasone > > Reviewed by: jlemon, jake > > I object to what has been done here, I found the bug and now looking > at the code took me about 10 minutes to verify that the bug (or > some variant of it) didn't still exist. Yeah, and it doesn't. > Can you take this code and wrap it with some API so that the mbuf > code is cleaner (readable) and so that I can use it for things like > ucred? I'd rather not inline this nastyness into anything I'm > working on. No, but I'm hoping that we can all agree on an interface eventually, as long as said interface meets all of the requirements/issues that were raised, or the majority of them, at least. I'm not strictly opposed to the idea of an interface for this sort of stuff, I've already made that clear; I'm opposed to rushing into an interface and finishing up with some "product" which will likely have to be drastically changed soon anyway (ironically, I think I remember *you* telling *me* something along these lines some time ago, regarding an issue we were discussing). :-) > If the code is really doing "atomic_dec_and_test" I really don't > understand why we just can't have a function called atomic_dec_and_test. The code you see there does its job, and it's not "incorrect," either. As I understand it, your objection to it has to do with your feeling of it not being "clean" or fear of having to replicate it, or worse, do it slightly differently, in several different places in the kernel code. The fix does not impose any sort of "unified way of dealing with reference counters," which I believe you assume it did. > thanks, > -Alfred Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message