race condition in obj_space-virt.cpp ?

Chen Tian chen.tian at acm.org
Sat Jan 14 01:37:06 CET 2012


I observed a race condition in Fiasco.OC. My environment is very
complicated, but basically I have multiple threads, and each thread keep
creating kernel object via l4_factory_create_xxxx and map the object to a
new task.

Here is the trace I got:

//printed from obj_space-virt.cpp in function caps_alloc:

Chen: caps_alloc for virt addr 0xf0826000 (index 0x2600), new cap location
0xfeb04000, [virt 0xf0826000-> mem 0xfeb04000] in space 0xfedd7f08
Chen: caps_alloc for virt addr 0xf0826010 (index 0x2601), new cap location
0xfeb05000, [virt 0xf0826000-> mem 0xfeb05000] in space 0xfedd7f08
Chen: v_insert cap 0xfed5a6a0 (index 0x2600 (entry addr 0xfeb04000) in
space 0xfedd7f08
Chen: v_insert cap 0xfeb000b4 (index 0x2601) (entry addr 0xfeb05010) in
space 0xfedd7f08

//printed from map_util
thread 0xfed4c000: v_fabricate is false: (Obj_space) from [0xfedd7ef4/12],
s_phys 0x0: 00002601 size: 00000001 to [0xfedd7e9c/18] recv addr 0x2541

// then I got
KERNEL: Warning: nothing mapped: (Obj_space) from [0xfedd7ef4/12]: 00002602
size: 00000001 to [0xfedd7e9c/18] recv addr 0x2542
 Omnicore Panic: task map failed!

Basically, different object index (2600 and 2601) causes two different page
to be created and mapped to the same cap_table virtual address 0xf0826000.
Although one of the mapping
will fail, but the current logic did not return the correct address.

The fix I put in to solve this problem is to add the following lines after
the switch statement in caps_alloc function:

  if (s != Insert_ok ) {
          Config::PAGE_SIZE, mem);
      mem= alien_lookup(virt & ~(Config::PAGE_SIZE/sizeof(Entry)-1));

Please let me know if this is correct. Thanks.

Even with this fix, I still got another kernel "nothing mapped error" when
I ask each thread not only to create and map kernel objects, but also to
delete objects using l4_task_unmap. If I do not use l4_task_unmap,
everything is fine. I am still investigating why, but I got a feeling that
there may be other race conditions on the cap_table related operations.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20120113/9e0ddf58/attachment.html>

More information about the l4-hackers mailing list