On Wed, Jan 24, 2024 at 2:49 PM Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote: > > On Wed, Jan 24, 2024 at 12:06 PM Liam R. Howlett > <Liam.Howlett@xxxxxxxxxx> wrote: > > > > > Considering this is the MAP_FIXED case, and maybe that is not used > > > that often in practice, I think this is acceptable performance-wise, > > > unless you know another solution to help this. > > > > Okay, sure, I haven't been yelled at on the ML for a few weeks. Here > > goes: > > > > do_mmap() will call get_unmapped_area(), which will return an empty area > > (no need to check mseal, I hope - or we have larger issues here) or a > > MAP_FIXED address. > > > > do_mmap() will pass the address along to mmap_region() > > > > mmap_region() will then call do_vmi_munmap() - which will either remove > > the VMA(s) in the way, or do nothing... or error. > > > > mmap_region() will return -ENOMEM in the case of an error returned from > > do_vmi_munmap() today. Change that to return the error code, and let > > do_vmi_munmap() do the mseal check. If mseal check fails then the error > > is propagated the same way -ENOMEM is propagated today. > > > > This relies on the fact that we only really need to check the mseal > > status of existing VMAs and we can only really map over existing VMAs by > > first munmapping them. > > > > It does move your error return to much later in the call stack, but it > > removes duplicate work and less code. Considering this should be a rare > > event, I don't think that's of concern. > > > I think that is a great idea, I will try to implement it and get back > to you on this. > I confirm this works. I will add that in the next version. Thanks for the suggestion. -Jeff
