On Wed, Apr 30, 2025 at 11:29:46PM +0200, Jann Horn wrote: > On Wed, Apr 30, 2025 at 9:59 PM Lorenzo Stoakes > <lorenzo.stoakes@xxxxxxxxxx> wrote: > > A driver can specify either .mmap_proto(), .mmap() or both. This provides > > maximum flexibility. > > Just to check I understand the intent correctly: The idea here is that > .mmap_proto() is, at least for now, only for drivers who want to > trigger merging, right? If a driver doesn't need merging, the normal > .mmap() handler can still do all the things it was able to do before > (like changing the ->vm_file pointer through vma_set_file(), or > changing VMA flags in allowed ways)? No, the intent is that this form the basis of an entirely new set of callbacks to use _instead_ of .mmap(). The vma_set_file() semantics would need to be changed actually, I will update logic to do this implicitly when the user sets vma_proto (or whatever this gets renamed to :P)->file - we can do this automagically. However the first use is indeed to be able to remove this merge retry. I have gone through .mmap() callbacks and identified the only one that seems meaningfully to care, so it's a great first use. Two birds with one stone, and forming the foundatio for future work to prevent drivers from having carte blache to do whatever on .mmap() wrt vma's.
