On Tue, Sep 09, 2025 at 09:43:25AM -0700, Suren Baghdasaryan wrote: > On Tue, Sep 9, 2025 at 2:37 AM Lorenzo Stoakes > <lorenzo.stoa...@oracle.com> wrote: > > > > On Tue, Sep 09, 2025 at 11:26:21AM +0200, David Hildenbrand wrote: > > > > > > > > > > In particular, the mmap_complete() looks like another candidate for > > > > > letting > > > > > a driver just go crazy on the vma? :) > > > > > > > > Well there's only so much we can do. In an ideal world we'd treat VMAs > > > > as > > > > entirely internal data structures and pass some sort of opaque thing > > > > around, but > > > > we have to keep things real here :) > > > > > > Right, we'd pass something around that cannot be easily abused (like > > > modifying random vma flags in mmap_complete). > > > > > > So I was wondering if most operations that driver would perform during the > > > mmap_complete() could be be abstracted, and only those then be called with > > > whatever opaque thing we return here. > > > > Well there's 2 issues at play: > > > > 1. I might end up having to rewrite _large parts_ of kernel functionality > > all of > > which relies on there being a vma parameter (or might find that to be > > intractable). > > > > 2. There's always the 'odd ones out' :) so there'll be some drivers that > > absolutely do need to have access to this. > > > > But as I was writing this I thought of an idea - why don't we have something > > opaque like this, perhaps with accessor functions, but then _give the > > ability to > > get the VMA if you REALLY have to_. > > > > That way we can handle both problems without too much trouble. > > > > Also Jason suggested generic functions that can just be assigned to > > .mmap_complete for instance, which would obviously eliminate the crazy > > factor a lot too. > > > > I'm going to refactor to try to put ONLY prepopulate logic in > > .mmap_complete where possible which fits with all of this. > > Thinking along these lines, do you have a case when mmap_abort() needs > vm_private_data? I was thinking if VMA mapping failed, why would you > need vm_private_data to unwind prep work? You already have the context > pointer for that, no?
Actually have removed mmap_abort in latest respin :) the new version will be a fairly substantial rewrite based on feedback.
