Date: Mon, 5 Jul 2004 22:46:38 +0400 From: Gleb Smirnoff <glebius@cell.sick.ru> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: ng_ksocket on CURRENT Message-ID: <20040705184638.GC60338@cell.sick.ru> In-Reply-To: <Pine.NEB.3.96L.1040705141810.48668A-100000@fledge.watson.org> References: <20040705181106.GA60338@cell.sick.ru> <Pine.NEB.3.96L.1040705141810.48668A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 05, 2004 at 02:19:30PM -0400, Robert Watson wrote: R> > yes, this thread is originating from a callout. Actually, it is R> > impossible to reproduce this as I described in previous letter. Sorry. R> > R> > So you suggest to lock Giant in a callout handle? Or should we somewhat R> > tweak ng_ksocket? R> R> Depends on the callout, but if it's a network-specific callout, I'd R> suggest having callout_init() use the following logic to build the flags R> field: R> R> debug_mpsafenet ? CALLOUT_MPSAFE : 0 R> R> I.e., if we're running without debug.mpsafenet turned on, then run the R> callout with Giant. If the callout does a lot of other stuff, I'd acquire R> Giant conditionally (as your patch does) just around the network bits. R> That said, I'd have Giant include all the netgraph bits, not just the R> socket bits. Ok, I will surround with NET_LOCK_GIANT the place of code where data is sent towards ng_ksocket. I don't want to hold Giant during all callout (it may be long). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040705184638.GC60338>