On Wed, Nov 13, 2024 at 7:29 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * Suren Baghdasaryan <surenb@xxxxxxxxxx> [241113 10:25]: > > On Wed, Nov 13, 2024 at 7:23 AM 'Liam R. Howlett' via kernel-team > > <kernel-team@xxxxxxxxxxx> wrote: > > > > > > * Matthew Wilcox <willy@xxxxxxxxxxxxx> [241113 08:57]: > > > > On Wed, Nov 13, 2024 at 07:38:02AM -0500, Liam R. Howlett wrote: > > > > > > Hi, I was wondering if we actually need the detached flag. Couldn't > > > > > > "detached" simply mean vma->vm_mm == NULL and we save 4 bytes? Do we ever > > > > > > need a vma that's detached but still has a mm pointer? I'd hope the places > > > > > > that set detached to false have the mm pointer around so it's not inconvenient. > > > > > > > > > > I think the gate vmas ruin this plan. > > > > > > > > But the gate VMAs aren't to be found in the VMA tree. Used to be that > > > > was because the VMA tree was the injective RB tree and so VMAs could > > > > only be in one tree at a time. We could change that now! > > > > > > \o/ > > > > > > > > > > > Anyway, we could use (void *)1 instead of NULL to indicate a "detached" > > > > VMA if we need to distinguish between a detached VMA and a gate VMA. > > > > > > I was thinking a pointer to itself vma->vm_mm = vma, then a check for > > > this, instead of null like we do today. > > > > The motivation for having a separate detached flag was that vma->vm_mm > > is used when read/write locking the vma, so it has to stay valid even > > when vma gets detached. Maybe we can be more cautious in > > vma_start_read()/vma_start_write() about it but I don't recall if > > those were the only places that was an issue. > > We have the mm form the callers though, so it could be passed in? Let me try and see if something else blows up. When I was implementing per-vma locks I thought about using vma->vm_mm to indicate detached state but there were some issues that caused me reconsider. > > > > > > > > > Either way, we should make it a function so it's easier to reuse for > > > whatever we need in the future, wdyt? > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. > > >
