DragonFly BSD
DragonFly bugs List (threaded) for 2005-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: netgraph panics


To: YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>
From: Hiten Pandya <hmp@xxxxxxxxxxxxx>
Date: Fri, 26 Aug 2005 17:10:48 +0100

YONETANI Tomokazu wrote:
On Mon, Aug 22, 2005 at 01:34:50PM +0100, Hiten Pandya wrote:
When it happens, I can get rid of this anti-foot-shooting which has been
in my tree for more than a year :)


OK, nice work Tomokazu-san. That's a nice stopgap, but read on for my suggestion of a commitable workaround.


This is a good workaround instead of crying panic and not working at all. One more thing you could do is load the ng_ksocket.ko module from kldload(2) system call's context in the module handler, which will then remove the requirement for the user to load this module.

Since the module handler is GUARANTEED to have a process context, you can easily call linker_preload_file from there, and load ng_ksocket.ko.

I mean, you could load ng_ksocket.ko in modhandler, ngb_mod_event() and you can KEEP this ifdef section in ng_mkpeer so that OTHER netgraph module files do not fall into this trap. So under the MOD_LOAD case, you would call the linker_preload_file() function, and unload it under the MOD_UNLOAD case, naturally.

By adding such a workaround, we at least know that the basic netgraph operations will not fail because ng_ksocket.ko is missing, since we preloaded one of the fundamental ng_ modules for them; they only need to worry about the specific ones.

If you can develop upon your foot-shooting measure with the above suggestion, you can go ahead and commit it! :-)

Thanks!

				Hiten Pandya
				hmp@xxxxxxxxxxxxx



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]