On Thu, Apr 24, 2025 at 11:22:26PM +0200, David Hildenbrand wrote: > On 24.04.25 23:15, Lorenzo Stoakes wrote: > > Right now these are performed in kernel/fork.c which is odd and a violation > > of separation of concerns, as well as preventing us from integrating this > > and related logic into userland VMA testing going forward, and perhaps more > > importantly - enabling us to, in a subsequent commit, make VMA > > allocation/freeing a purely internal mm operation. > > > > There is a fly in the ointment - nommu - mmap.c is not compiled if > > CONFIG_MMU is not set, and there is no sensible place to put these outside > > of that, so we are put in the position of having to duplication some logic > > here. > > > > This isn't ideal, but since nommu is a niche use-case, already duplicates a > > great deal of mmu logic by its nature and we can eliminate code that is not > > applicable to nommu, it seems a worthwhile trade-off. > > > > The intent is to move all this logic to vma.c in a subsequent commit, > > rendering VMA allocation, freeing and duplication mm-internal-only and > > userland testable. > > I'm pretty sure you tried it, but what's the big blocker to have patch #3 > first, so we can avoid the temporary move of the code to mmap.c ? You know, I didn't :P it was late etc. ;) But you're right, will rejig accordingly! > > -- > Cheers, > > David / dhildenb >
