Hi Kevin,
On 8/28/23 13:25, Kevin Brodsky wrote:
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.
Agree.
(Similarly, MAP_FIXED with a null-derived capability must fail if the new reservation would overlap with an existing one.)
Ok.
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.
I had a look at the unmapped_area_topdown() implementation. The good thing is that there already exists retry implementation. We can use reservation start/end limits directly from vma structure in vm_start_gap()/vm_end_gap() function.
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?
Agree that searching based on reservation range is the optimal method here but managing the multiple mapping range within the reservation will again need a new maple tree or something. I think most of the time searching from vma range does the job. We can revisit this later if required.
Amit Daniel
Kevin