Re: netgraph panics

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

On Mon, Aug 22, 2005 at 01:34:50PM +0100, Hiten Pandya wrote:
> The problem is that in 4.x, the netgraph code used to be called from 
> either the syscall process context (if compiled in) or the kldload(2) 
> process context.  When our network socket code changed, it started calling 
> the ng_mkpeer() function from the socket dispatch thread (netisr_cpuX), 
> which doesn't have a process associated with it, unlike the system call 
> context paths.
> 
> One of these days I basically need to fix the linker API to work without 
> the process context or use a different one.

When it happens, I can get rid of this anti-foot-shooting which has been
in my tree for more than a year :)

Index: ng_base.c
===================================================================
RCS file: /home/source/dragonfly/cvs/src/sys/netgraph/netgraph/ng_base.c,v
retrieving revision 1.15
diff -u -r1.15 ng_base.c
--- ng_base.c	2 Jun 2005 22:11:46 -0000	1.15
+++ ng_base.c	25 Aug 2005 03:55:52 -0000
@@ -318,6 +318,13 @@
 
 	/* Locate the node type */
 	if ((type = ng_findtype(typename)) == NULL) {
+#ifdef notyet
+		/*
+		 * FIXME: the code below leads to a panic, since linker_*
+		 * functions require a process context, but we're called
+		 * from a pure thread, which is not associated with a
+		 * process.
+		 */
 		char *path, filename[NG_TYPELEN + 4];
 		linker_file_t lf;
 		int error;
@@ -335,6 +342,10 @@
 		/* Try again, as now the type should have linked itself in */
 		if ((type = ng_findtype(typename)) == NULL)
 			return (ENXIO);
+#else
+		printf("required module ng_%s not loaded\n", typename);
+		return (ENXIO);
+#endif
 	}
 
 	/* Call the constructor */