race condition in obj_space-virt.cpp ?

[Chen Tian]

Hello,

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 ) {
      Mapped_allocator::allocator()->q_unaligned_free(ram_quota(),
          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.

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