Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Mar 2013 23:26:15 GMT
From:      Keith Reynolds <keith.reynolds@tidalscale.com>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   misc/176771: user-mode netgraph node hangs when replying to control message
Message-ID:  <201303082326.r28NQF69063317@red.freebsd.org>
Resent-Message-ID: <201303082330.r28NU0E5079252@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>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
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Mar 08 23:30:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Keith Reynolds
>Release:        10.0-CURRENT
>Organization:
TidalScale
>Environment:
FreeBSD ts_bhyve1.local 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r245569: Tue Mar  5 14:24:01 PST 2013     root@ts_bhyve1.local:/usr/obj/usr/src/sys/TS  amd64
>Description:
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.
>How-To-Repeat:
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.
>Fix:
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;
 


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303082326.r28NQF69063317>