svn commit: r194012 - in head: . sys/netgraph sys/sys

Julian Elischer julian at elischer.org
Thu Jun 11 20:27:14 UTC 2009


Marko Zec wrote:
> On Thursday 11 June 2009 21:01:40 Pawel Jakub Dawidek wrote:
>> On Thu, Jun 11, 2009 at 04:50:49PM +0000, Marko Zec wrote:
>>> Author: zec
>>> Date: Thu Jun 11 16:50:49 2009
>>> New Revision: 194012
>>> URL: http://svn.freebsd.org/changeset/base/194012
>>>
>>> Log:
>>>   Introduce a mechanism for detecting calls from outbound path of the
>>>   network stack when reentering the inbound path from netgraph, and
>>>   force queueing of mbufs at the outbound netgraph node.
>>>
>>>   The mechanism relies on two components.  First, in netgraph nodes
>>>   where outbound path of the network stack calls into netgraph, the
>>>   current thread has to be appropriately marked using the new
>>>   NG_OUTBOUND_THREAD_REF() macro before proceeding to call further
>>>   into the netgraph topology, and unmarked using the
>>>   NG_OUTBOUND_THREAD_UNREF() macro before returning to the caller.
>>>   Second, netgraph nodes which can potentially reenter the network
>>>   stack in the inbound path have to mark their inbound hooks using
>>>   NG_HOOK_SET_TO_INBOUND() macro.  The netgraph framework will then
>>>   detect when there is a danger of a call graph looping back from
>>>   outbound to inbound path via netgraph, and defer handing off the
>>>   mbufs to the "inbound" node to a worker thread with a clean stack.
>>>
>>>   In this first pass only the most obvious netgraph nodes have been
>>>   updated to ensure no outbound to inbound calls can occur.  Nodes
>>>   such as ng_ipfw, ng_gif etc. should be further examined whether a
>>>   potential for outbound to inbound call looping exists.
>>>
>>>   This commit changes the layout of struct thread, but due to
>>>   __FreeBSD_version number shortage a version bump has been omitted
>>>   at this time, nevertheless kernel and modules have to be rebuilt.
>> Are you sure Marko that you can't use sys/sys/osd.h instead of adding
>> yet another field to the thread structure? Netgraph is optional
>> component and optional components could take advantage of allocating
>> stuff they need dynamically. The OSD (Object-Specific Data) KPI is
>> designed for use by optional components - you can add your data to a
>> thread, you can get it when you want and OSD will call your callback
>> when thread dies, so you can clean up.
>>
>> Maybe you can't, but it's worth checking.
> 
> Hmm how much locking overhead do osd_set() / osd_get() methods introduce?  We 
> have to bump the refcount on each entry to netgraph, and then check it 
> potentially on each hop to next ng node, and finally drop the refcount when 
> done with the function call into netgraph.  Accessing td_ng_outbound directly 
> via curthread is as cheap as it gets performancewise as it requires no 
> locking whatsoever...

I would add that I suspect that we may end up using it in other places 
as well outside of netgraph.



> Cheers,
> 
> Marko
> 
> 
>> PS. Currently OSD works for threads and jails, but it is ready to be
>>     extended to work with other object types, eg. vnodes, ifnets, etc.
>>     Even if you can't use it in this particular case, keep it in mind,
>>     as it might be useful for other vimage-related stuff.
>>
>>> Modified: head/sys/sys/proc.h
>>> =========================================================================
>>> ===== --- head/sys/sys/proc.h	Thu Jun 11 16:48:59 2009	(r194011)
>>> +++ head/sys/sys/proc.h	Thu Jun 11 16:50:49 2009	(r194012)
>>> @@ -235,6 +235,7 @@ struct thread {
>>>  	char		td_name[MAXCOMLEN + 1];	/* (*) Thread name. */
>>>  	struct file	*td_fpop;	/* (k) file referencing cdev under op */
>>>  	int		td_dbgflags;	/* (c) Userland debugger flags */
>>> +	int		td_ng_outbound;	/* (k) Thread entered ng from above. */
>>>  	struct osd	td_osd;		/* (k) Object specific data. */
>>>  #define	td_endzero td_base_pri
> 



More information about the svn-src-all mailing list