Hi, Thank you so much for your comments, there are genuinely useful. On Fri, Nov 24, 2023 at 08:35:47PM +0100, David Hildenbrand wrote: > On 19.11.23 17:56, Alexandru Elisei wrote: > > Introduce arch_prep_new_page(), which will be used by arm64 to reserve tag > > storage for an allocated page. Reserving tag storage can fail, for example, > > if the tag storage page has a short pin on it, so allow prep_new_page() -> > > arch_prep_new_page() to similarly fail. > > But what are the side-effects of this? How does the calling code recover? > > E.g., what if we need to populate a page into user space, but that > particular page we allocated fails to be prepared? So we inject a signal > into that poor process? When the page fails to be prepared, it is put back to the tail of the freelist with __free_one_page(.., FPI_TO_TAIL). If all the allocation paths are exhausted and no page has been found for which tag storage has been reserved, then that's treated like an OOM situation. I have been thinking about this, and I think I can simplify the code by making tag reservation a best effort approach. The page can be allocated even if reserving tag storage fails, but the page is marked as invalid in set_pte_at() (PAGE_NONE + an extra bit to tell arm64 that it needs tag storage) and next time it is accessed, arm64 will reserve tag storage in the fault handling code (the mechanism for that is implemented in patch #19 of the series, "mm: mprotect: Introduce PAGE_FAULT_ON_ACCESS for mprotect(PROT_MTE)"). With this new approach, prep_new_page() stays the way it is, and no further changes are required for the page allocator, as there are already arch callbacks that can be used for that, for example tag_clear_highpage() and arch_alloc_page(). The downside is extra page faults, which might impact performance. What do you think? Thanks, Alex > > -- > Cheers, > > David / dhildenb >
