Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Feb 2011 16:06:52 +0100
From:      Monthadar Al Jaberi <monthadar@gmail.com>
To:        Julian Elischer <julian@freebsd.org>
Cc:        freebsd-virtualization@freebsd.org
Subject:   Re: simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)
Message-ID:  <AANLkTi=mk2vfyXJBaK5mV2sBWEj0-RDZneLs%2BXq_c7sb@mail.gmail.com>
In-Reply-To: <4D486108.5060805@freebsd.org>
References:  <AANLkTik8D_bLwcUKZdBT-kpkJdDXtPTLvAqfUe0cLoSz@mail.gmail.com> <4D484213.6050100@freebsd.org> <AANLkTikJKZLQVA5X2PQs0oT4iFsZYBw7K07kjQTc9iGD@mail.gmail.com> <4D486108.5060805@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanx makes more sense, but I have noticed something weired if you can
shade some light on.

I added printfs one when the module is first loaded (static int
event_handler(module_t module, int event, void *arg)):
curthread=3D0xc3f95870
curthread->td_vnet=3D0xc3170e00
curthread->td_ucred=3D0xc3185d00
TD_TO_VNET=3D0
CRED_TO_VNET=3D0


And same printf in wtap_ioctl which is called from a user space
program (I am root):
curthread=3D0xc3f952d0
curthread->td_vnet=3D0
curthread->td_ucred=3D0xc3185d00
TD_TO_VNET=3D0
CRED_TO_VNET=3D0


In both cases TD_TO_VNET/CRED_TO_VNET return NULL... shouldn't they
return a pointer same as curthread->td_vnet? Another thing is that in
wtap_ioctl curthread->td_vnet is NULL

I still get a panic...

br,

On Tue, Feb 1, 2011 at 8:37 PM, Julian Elischer <julian@freebsd.org> wrote:
> ok here's how it works..
>
> any place you access a V_xxx variable you need to have the current vnet s=
et.
> so somewhere in your code path to get to that point you have to have done
> CURVNET_SET() and after you have finised on the way out you should do
> CURVNET_RESTORE().
>
> you can get the vnet from several places:
>
> 1/ as shown below, you can get it from any thread's cred if teh running
> thread is part of a
> process in the jail in question.
> 2/ if you have an ifp pointer, you can use ifp->vnet =A0. =A0 I think tha=
t's
> right, it's been a while...
> 3/ I believe though I may be wrong =A0(I may be thinking of multi FIBS)
> that it maybe in the socket structure too but don't trust me on that one.=
.
> check it.
>
> if, like in a timer thread you have access to NONE of those, you have
> several choices..
> 1/ the caller of the timer may have given you indirect access to it in th=
e
> arg.
> 2/ maybe you juaast have to interate through all the vimages.. to do
> whatever it is that you do
> (that happens in some protocols)
>
>
> On 2/1/11 11:04 AM, Monthadar Al Jaberi wrote:
>>
>> On Tue, Feb 1, 2011 at 6:25 PM, Julian Elischer<julian@freebsd.org>
>> =A0wrote:
>>>
>>> On 2/1/11 8:40 AM, Monthadar Al Jaberi wrote:
>>>>
>>>> Hi,
>>>>
>>>> I hope I am on the write place, second try...
>>>>
>>>> I have written a module that loads fake wifi devices (wtap?) and
>>>> distributes packets between them. For now I use route command to route
>>>> packets between them from upper layers (TCP,...).
>>>> I want to take it to next step and create jails with VNET. I started
>>>> reading Julian Elischer's "Vimage: what is it?" and he says that if I
>>>> am writing hardware drivers I dont need to make any changes when I
>>>> enable VIMAGE option on the kernel, because each one will have their
>>>> own stack.
>>>>
>>>> I can give a more detailed explanation on how my module works. But for
>>>> now I get a panic when calling if_alloc() when using option VIMAGE.
>>>>
>>>> Thank you,
>>>
>>> while this =A0was true to some extent it i snot 100% true now.
>>> during allocation we now try to have separate interface indexes per
>>> vimage
>>> which means that the setup routines do need to know the current vnet.
>>
>> so I cant call if_alloc directly?
>>
>>> it looks like wtap_ioctl or wtap_attach should have the following:
>>> (copied from the tun driver)
>>>
>>> this should not be needed from real hardware based drivers as far as I
>>> can
>>> tell.
>>>
>>> =A0 =A0 =A0 =A0CURVNET_SET(CRED_TO_VNET(cred));
>>> =A0 =A0 =A0 =A0/* find any existing device, or allocate new unit number=
 */
>>> =A0 =A0 =A0 =A0i =3D clone_create(&tunclones,&tun_cdevsw,&u, dev, 0);
>>> =A0 =A0 =A0 =A0[blah]
>>> =A0 =A0 =A0 =A0if_clone_create(name, namelen, NULL);
>>> =A0 =A0 =A0 =A0CURVNET_RESTORE();
>>
>> My wtap is based on ath driver code (if_ath.c) which should look like
>> a real device right?
>> if_ath.c is not using VNET, as far as I can tell....
>>
>> Currently my module creates a couple of wtaps, which I then create a
>> corresponding wlan. These wtaps are interconnected together, so no out
>> world yet... so I dont have struct cdev *dev....
>>
>> Basic idea is my module have a main queue (simulating air) and each
>> wtap have a rx_task which sends packets up to higher layers, plus
>> callout timer for generation beacons...
>>
>> I will try to use CURVET_SET(...) tomo
>>
>>
>>>> My setup:
>>>> FreeBSD Current 201010 guest on VirtualBox on Ubuntu 10.04.
>>>>
>>>> Kernel page fault with the following non-sleepable locks held:
>>>> exclusive rw ifnet_rw (ifnet_rw) r =3D 0 (0xc0fc8284) locked @
>>>> /usr/src/sys/net/if.c:414
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at
>>>> db_trace_self_wrapper+0x26
>>>> kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at
>>>> kdb_backtrace+0x2a
>>>> _witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x=
25
>>>> witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe
>>>> trap(c2fc9abc) at trap+0x195
>>>> calltrap() at calltrap+0x6
>>>> --- trap 0xc, eip =3D 0xc0970999, esp =3D 0xc2fc9afc, ebp =3D 0xc2fc9b=
1c ---
>>>> ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at
>>>> ifindex_alloc_locked+0x19
>>>> if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85
>>>> wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29
>>>> new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b
>>>> wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x=
36
>>>> devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at
>>>> devfs_ioctl_f+0x10b
>>>> kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20=
d
>>>> ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134
>>>> syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263
>>>> syscall(c2fc9d28) at syscall+0x34
>>>> Xint0x80_syscall() at Xint0x80_syscall+0x21
>>>> --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x28181203, esp =3D
>>>> 0xbfbfec3c, ebp =3D 0xbfbfec58 ---
>>>>
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid =3D 0; apic id =3D 00
>>>> fault virtual address =A0 =3D 0x18
>>>> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read, page not pr=
esent
>>>> instruction pointer =A0 =A0 =3D 0x20:0xc0970999
>>>> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc2fc9afc
>>>> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xc2fc9b1c
>>>> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type =
0x1b
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, def3=
2 1, gran 1
>>>> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =
=3D 0
>>>> current process =A0 =A0 =A0 =A0 =3D 1203 (ioctl)
>>>> panic: from debugger
>>>> cpuid =3D 0
>>>> Uptime: 21s
>>>> Physical memory: 495 MB
>>>> Dumping 55 MB: 40 24 8
>>>>
>>>
>>
>>
>
>



--=20
//Monthadar Al Jaberi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=mk2vfyXJBaK5mV2sBWEj0-RDZneLs%2BXq_c7sb>