misc/176771: user-mode netgraph node hangs when replying to control message

Keith Reynolds keith.reynolds at tidalscale.com
Fri Mar 8 23:30:00 UTC 2013

>Number:         176771
>Category:       misc
>Synopsis:       user-mode netgraph node hangs when replying to control message
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 08 23:30:00 UTC 2013
>Originator:     Keith Reynolds
>Release:        10.0-CURRENT
FreeBSD ts_bhyve1.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245569: Tue Mar  5 14:24:01 PST 2013     root at ts_bhyve1.local:/usr/obj/usr/src/sys/TS  amd64
When a netgraph client calls NgSendReplyMsg() to reply to a netgraph control message that is marked as having a reply (msg->header.cmd & NGM_HASREPLY), the library blocks waiting for a reply that will never come, because the message that's being sent *IS* the reply. It doesn't account for the possibility that the user-mode client is replying to a netgraph control message rather than originating one.
Write a user-mode netgraph client that responds to the NGM_GENERIC_COOKIE/NGM_TEXT_STATUS control message, which is marked as NGM_HASREPLY, and use "ngctl status <node_path>" to query it. The call to NgSendReplyMsg() will block until another control message comes in, which won't happen until you use ngctl to send another request.
See the attached patch to lib/libnetgraph/msg.c. The change checks msg->header.flags & NGF_RESP to determine if the message being sent is the expected reply before blocking to wait for one.

Patch attached with submission follows:

Index: msg.c
--- msg.c	(revision 245569)
+++ msg.c	(working copy)
@@ -234,7 +234,7 @@
 	/* Wait for reply if there should be one. */
-	if (msg->header.cmd & NGM_HASREPLY) {
+	if (msg->header.cmd & NGM_HASREPLY && !(msg->header.flags & NGF_RESP)) {
 		struct pollfd rfds;
 		int n;


More information about the freebsd-bugs mailing list