On 17/08/2023 11:21, Amit Daniel Kachhap wrote:
+ ret = do_vmi_align_munmap(vmi, vma, mm, start, end, uf, downgrade); +#ifdef CONFIG_CHERI_PURECAP_UABI + if (!reserve_ignore && ret >= 0) + reserv_mt_delete_range(&mm->reserv_mt, start, len);
Reservations are immutable - they are never expanded or shrunk, only destroyed. The complete set of rules can be found in the "Reservations" section of the PCuABI spec [1].
In this RFC version, reservation layer stores each mappings along with their root reservation and also does VMA type split operation here if required. Hopefully I can simplify these things and merge the reservation interface inside the VMA.
Fair enough, I have to admit I hadn't looked at patch 2 closely. I now understand the logic better. However, I think there is another fundamental issue with that design. When creating a new reservation, we need to find an appropriate location. I mentioned earlier that this range needs to have representable bounds. There is however an even more important requirement: this range must not overlap with any other reservation. get_unmapped_area() therefore needs to consider existing *reservations* to find a hole, and mappings become irrelevant. (Similarly, MAP_FIXED with a null-derived capability must fail if the new reservation would overlap with an existing one.)
With the current data structure, finding a "reservation hole" is rather awkward, since we cannot directly iterate over reservations. If we move to a model where we directly tag each VMA with its reservation, I think the issue remains the same: we do not have direct access to the reservations.
This is the reason why I initially assumed that the data structure represented *reservation* ranges, not mapping ranges, because the former is what really matters to us. Each reservation could then have a list of mappings associated to it, but that may not even be required - when unmapping, we could simply query the VMAs for the corresponding reservation range and see if there's any left. Maybe I'm missing something though?
Kevin