Fix detection of kernel memory overlap

[leandro.lupori_gmail.com]

Summary

Function moea64_early_bootstrap was not detecting overlaps
between available and kernel memory regions when the
available region was entirely contained in kernel region.

This would result in kernel memory being considered as
available for other purposes, corrupting kernel memory
usage.

The fix consists in adding an additional check and exclude
memory regions inside [kernelstart, kernelend] range.

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

705 ↗

(On Diff #41592)

Style nit: return values should be wrapped in ()'s (yes, we violate that in a few spots here, but it's style). Won't penalize for it, though.

788 ↗

(On Diff #41592)

Do you need the cast here? I think it's redundant, but may be wrong.

[leandro.lupori_gmail.com]

sys/powerpc/aim/mmu_oea64.c

705 ↗

(On Diff #41592)

Ok.

788 ↗

(On Diff #41592)

Without the cast it's harder to be sure that it will be correct for every platform.

If phys_avail type will always be uint64_t [] in this code, than it should be safe to use either ~0UL or ~0ULL.

But if it may be uint32_t, than using 0U and (possibly) widening it to vm_paddr_t before negating it would be better.

~0ULL should also work for uint32_t, as ~0ULL will probably be truncated to 32 bits in this case. But the compiler may produce a warning about narrowing the value.

What do you think?

[jhibbits]

sys/powerpc/aim/mmu_oea64.c

788 ↗

(On Diff #41592)

~0 should suffice. We use that in other places to represent all-one values, such as in bus_alloc_resource_any. C rules will automagically return the correct value.

[leandro.lupori_gmail.com]

• Addressing review's comments

[jhibbits]

Great work!

[leandro.lupori_gmail.com]

Thanks @jhibbits! Can you commit the change for me?

[swills]

Booted r331763 with this change and it fixed the problem for me.