In ram_alloc_remote, there is a hack that before we obtain the ram_alloc_lock and do the actual transport, we first check if cs->space == 1: if yes, we do a pair of dummy slot_alloc and slot_free to help the slot_allocator grow itself. But since slot_alloc may involve another ram_alloc call, we need to reset the affinity to the default (0, 0) before slot_alloc and restore the affinity after slot_free.<div>
<br></div><div>I found this bug when I repeatly do: set affinity to (0x80000000-0xc0000000) (shared memory on SCC), allocate a 4K frame use frame_alloc, set the affinity back to (0, 0). After a certain number of iterations, all the slot in slot_allocator are consumed and trigger the dummy slot_alloc/slot_free operation. Then the slot_alloc failed since at the moment, the affinity is not the default (0, 0) but (0x80000000,0xc0000000). So the new frame is allocated on a non-expected physical memory region and somehow a page fault is triggered, which cause the system to crash.<br>
<div><br></div><div>Here is the fix patch, FYI.</div><div><br></div><div><div>diff -r ba0440b6d59d lib/barrelfish/ram_alloc.c</div><div>--- a/lib/barrelfish/ram_alloc.c<span class="Apple-tab-span" style="white-space:pre"> </span>Wed Aug 01 20:17:53 2012 +0800</div>
<div>+++ b/lib/barrelfish/ram_alloc.c<span class="Apple-tab-span" style="white-space:pre"> </span>Wed Aug 01 20:18:31 2012 +0800</div><div>@@ -35,6 +35,7 @@</div><div> struct slot_alloc_state *sas = get_slot_alloc_state();</div>
<div> struct slot_allocator *ca = (struct slot_allocator*)(&sas->defca);</div><div> if (ca->space == 1) {</div><div>+ ram_set_affinity(0, 0);</div><div> struct capref cap;</div><div> err = slot_alloc(&cap);</div>
<div> if (err_is_fail(err)) {</div><div>@@ -44,6 +45,7 @@</div><div> if (err_is_fail(err)) {</div><div> return err_push(err, LIB_ERR_SLOT_FREE);</div><div> }</div><div>+ ram_set_affinity(minbase, maxlimit);</div>
<div> }</div><div> </div><div> assert(ret != NULL);</div></div><div><br></div></div><div><br></div><div>Thanks,</div><div>Jinghao</div>