Date: Thu, 14 Mar 2002 13:25:24 -0500 (EST) From: "Andrew R. Reiter" <arr@FreeBSD.org> To: Jake Burkholder <jake@locore.ca> Cc: "Andrew R. Reiter" <arr@FreeBSD.org>, freebsd-smp@FreeBSD.org Subject: Re: Patch to lock down modules Message-ID: <Pine.NEB.3.96L.1020314130824.97600D-100000@fledge.watson.org> In-Reply-To: <20020314130843.B52298@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Mar 2002, Jake Burkholder wrote: : :Couple problems: : :I think that you missed a MOD_SLOCK before the : newmod = module_lookupbyname(data->name); :in module_register. Actually, iirc, module_register only got called from one spot, and in that spot, keeping SLOCK held seemed better than dropping it and reaquiring a SLOCK in module_register. If we'd like to keep this more consisten with some of the other funcitons, then I can change this no problem. : :Also in that function the MOD_XLOCK isn't needed until just before the :TAILQ_INSERT_TAIL. The increment of nextid needs something, I would :probably move it to just before the TAILQ_INSERT, under the XLOCK. An :atomic_add_and_return_old_value would be useful here. Also, I think :that you should do another module_lookupbyname after acquiring the :XLOCK and before the TAILQ_INSERT, because conceivably another module :with the same name could show up when you release the SLOCK. Seems reasonable... :Can you explain the wierd logic that was added to linker_file_unload? Ugh, yes, this is kinda ugly. Essentially this is a result of hacking this back and forth between where we should be holding SLOCK over. This is exactly what I wanted to discuss this b/c prior to making this change, I had a much more simple strategy here (but was dropped due to changes to a better strategy for kern_module). We discussed before about possibly having two sets of lookup functions -- internal and external -- perhaps this is a better solution? :Thanks, :Jake : -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020314130824.97600D-100000>