dummynet and vnet kernel panic
julian at elischer.org
Fri Apr 9 19:07:11 UTC 2010
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
>>>> 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.
>>>> 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.
> 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
>> 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 ?
More information about the freebsd-virtualization