dummynet and vnet kernel panic

[Julian Elischer]

On 4/9/10 7:17 AM, Luigi Rizzo wrote:
> On Wed, Apr 07, 2010 at 01:56:31PM -0700, Julian Elischer wrote:
>> On 4/7/10 1:38 PM, Luigi Rizzo wrote:
>>> On Wed, Apr 07, 2010 at 09:58:38PM +0200, Anders Hagman wrote:

Note: different To: list

>>>> Hi
>>>>
>>>> When using dummynet inside a vnet node with a simple pipe the kernel
>>>> panic on the first packet.
>>>>
>>>> I use 8.0-STABLE cvsuped at 7 Apr 15:28
>>>> The ipfw code with dummynet is largely changed and the patch in the url
>>>> below will not work.
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=143621
>>>>
>>>> Is there a fix in the near future?
>>>
>>> haven't tried it myself, but adapting the patch seems
>>> reasonably trivial. I'll see what i can do.
>>>
>>> Are there any vnet experts who can comment ?
>>
>> the change itself looks as if it makes sense
>> but I have not really tested it or gone to great length.
>>
>> -----------
>>
>> the following URL gives you the change that was made to make the OLD
>> version of dummynet Vimage compatible.
>>
>> http://p4db.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/src/sys/netinet/ipfw/ip_dummynet.c
>
> Question:
> the change in PR 143621 just makes sure that curvnet
> points to something sensible while a packet is reinjected
> by dummynet_send();
> the code in P4 does something completely different, as it
> remaps the global variables to the per-vimage ones, and does
> not seem to touch dummynet_send() at all.
> So how does the code in P4 make sure that curvnet is set properly ?

I can't say becasue I didn't do it. But I believe after that change,
dummynet was virtualized, but as I didn't do it I can't say what was 
tested.

>
>> does this still apply to 8.x? or did you redo the dummynet in 8?
>> if you didn't it may be worth looking to see if these changes apply to
>> 8.x real soon before it's frozen.
>
> former global variables are now mostly in a single struct, dn_cfg.
> There are however 150 lines where the global variable is used, so
> I am bit scared at renaming all of these occurrences from dn_cfg
> to V_dn_cfg. I'd rather follow a different approach, i.e


it woudl work but we avoided that way because we specifically wantet 
to be able to see at a glance whether virtualization is involved 
somewhere.  The change of name is just a single vi command..

>
>      VNET_DEFINE(struct dn_cfg, _base_dn_cfg);
>      #define dn_cfg		VNET(_base_dn_cfg)
>
> would this make sense to you ?
>
> 	cheers
> 	luigi