From owner-freebsd-current@FreeBSD.ORG Wed Jul 14 16:04: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 F371B16A4CE; Wed, 14 Jul 2004 16:04:19 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C4B443D45; Wed, 14 Jul 2004 16:04:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6EG3vip055068; Wed, 14 Jul 2004 12:03:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6EG3vJF055065; Wed, 14 Jul 2004 12:03:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jul 2004 12:03:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20040714154254.GB9999@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Some netgraph node global locking patches 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: Wed, 14 Jul 2004 16:04:20 -0000 On Wed, 14 Jul 2004, Gleb Smirnoff wrote: > On Wed, Jul 14, 2004 at 10:25:31AM -0400, Robert Watson wrote: > R> > On Wed, Jul 14, 2004 at 12:30:40AM -0400, Robert Watson wrote: > R> > R> //depot/vendor/freebsd/src/sys/netgraph/ng_eiface.c > R> > R> //depot/vendor/freebsd/src/sys/netgraph/ng_fec.c > R> > R> //depot/vendor/freebsd/src/sys/netgraph/ng_iface.c > R> > > R> > Well, these three are quite straightforward and identical. Look fine. > R> > R> I was somewhat hoping someone would actually give them a try and > R> demonstrate that practice matches the theory. :-) > > I can test ng_iface. Since change is similar we could assume ng_eiface, > ng_fec tested, then. Would it be enough to test on UP hardware? Yes, as long as you're running with witness and invariants, and can exercise each of the code paths that hits mutexes (and return paths) it should be sufficient to merge the changes. > R> My recollection of the quicksort algorithm is extremely vague, but I > R> recall that it involves recursion, and recursion is generally bad in the > R> kernel due to stack depth. > > Yes it does. But qsort() already used in ng_ppp is as much recursive as > qsort_r() is. It will help us to get rid of global variable. I Cc phk@ > to this mail, because he copied qsort() to libkern from libc. I think this sounds reasonable to me. I'm not objecting, just making a cautionary note :-). > R> This sounds good. I've chatted some with Julian about locking down access > R> to private data, but I've not had a chance to really digest and think > R> through it yet. Is this something you're interested in looking at? :-) > > Yes, it is. AFAIU, at this moment netgraph locks node in way that only > one netgraph callback can run at a time. It means one thread per node. > So there is no need to lock private data separately. Do I miss smth? I think you are correct, but I need to reread his e-mail about node locking before agreeing. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research