physical addresses stored in addr_t in sUserMutexTable

[pulkomandy]

We are looking at sUserMutexTable in src/system/kernel/locks/user_mutex.cpp

This has come under attention while debugging locking issues in the GHC compiler, although it isn't clear yet if the issue comes from here or not.

This code was written in 2010 and uses addr_t for physical addresses. On 32bit systems with PAE, this means the addresses can be truncated. phys_addr_t should be used instead to avoid truncation.

I guess we didn't notice because it is a bit unlikely that two entries in the table have physical addresses that are a multiple of 4GB apart?

Another question was the use of physical addresses in this code to identify objects, as the physical addresses can change if the object is mapped out of memory and back in. But if I understand the code correctly, it uses vm_wire_page/vm_unwire_page to lock things in physical memory for the duration of the locking, and so, that shouldn't be a problem.

[waddlesplash]

Yes, we use wiring to lock pages in physical memory, indeed.

[waddlesplash]

Fixed in hrev57067.

[pulkomandy]

Yes, we use wiring to lock pages in physical memory, indeed.

We do, but I didn't check carefully if the code always removes things from the hashmap before unwiring them (it seems so at a quick glance but it sounds worth checking in more detail).

If you checked that during your code review and didn't find anything suspicious, it's fine.