simulating wireless device (if_alloc panic, VirtualBox, VIMAGE)

Wed Feb 2 16:42:32 UTC 2011

On 2/2/11 7:06 AM, Monthadar Al Jaberi wrote:
> 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=0xc3f95870
> curthread->td_vnet=0xc3170e00
> curthread->td_ucred=0xc3185d00
> TD_TO_VNET=0
> CRED_TO_VNET=0
>
>
> And same printf in wtap_ioctl which is called from a user space
> program (I am root):
> curthread=0xc3f952d0
> curthread->td_vnet=0
> curthread->td_ucred=0xc3185d00
> TD_TO_VNET=0
> CRED_TO_VNET=0
>
>
> 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

that depends on where in your code you did the print..

have you read this file?

http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt&REV=18
use the 'download' button to get a more readable version.

it goes into some of the details of this. especially the 
initialization or vimage modules.

> I still get a panic...
>
> br,
>
> On Tue, Feb 1, 2011 at 8:37 PM, Julian Elischer<julian at freebsd.org>  wrote:
>> ok here's how it works..
>>
>> any place you access a V_xxx variable you need to have the current vnet set.
>> 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  .   I think that's
>> right, it's been a while...
>> 3/ I believe though I may be wrong  (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 the
>> 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 at freebsd.org>
>>>   wrote:
>>>> 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  was 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.
>>>>
>>>>         CURVNET_SET(CRED_TO_VNET(cred));
>>>>         /* find any existing device, or allocate new unit number */
>>>>         i = clone_create(&tunclones,&tun_cdevsw,&u, dev, 0);
>>>>         [blah]
>>>>         if_clone_create(name, namelen, NULL);
>>>>         CURVNET_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 = 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+0x25
>>>>> witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe
>>>>> trap(c2fc9abc) at trap+0x195
>>>>> calltrap() at calltrap+0x6
>>>>> --- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c ---
>>>>> 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+0x36
>>>>> devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at
>>>>> devfs_ioctl_f+0x10b
>>>>> kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d
>>>>> 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 = 0x28181203, esp =
>>>>> 0xbfbfec3c, ebp = 0xbfbfec58 ---
>>>>>
>>>>>
>>>>> Fatal trap 12: page fault while in kernel mode
>>>>> cpuid = 0; apic id = 00
>>>>> fault virtual address   = 0x18
>>>>> fault code              = supervisor read, page not present
>>>>> instruction pointer     = 0x20:0xc0970999
>>>>> stack pointer           = 0x28:0xc2fc9afc
>>>>> frame pointer           = 0x28:0xc2fc9b1c
>>>>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>>>>                         = DPL 0, pres 1, def32 1, gran 1
>>>>> processor eflags        = interrupt enabled, resume, IOPL = 0
>>>>> current process         = 1203 (ioctl)
>>>>> panic: from debugger
>>>>> cpuid = 0
>>>>> Uptime: 21s
>>>>> Physical memory: 495 MB
>>>>> Dumping 55 MB: 40 24 8
>>>>>
>>>
>>
>
>