Re: [patch 2/6] mm: fix vma_is_anonymous() false-positives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 21, 2018 at 12:48 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> So I'm not going to apply this. Instead, I'll do the "let's introduce
> a vma_alloc()/vma_free()". Initially doing *only* the allocation, then
> we can start moving things into it (the vm_ops initialization, the
> INIT_LIST_HEAD etc).

Ok, I'm pushing that out, so that we can try the "vm_ops model
defaults to dummy_vm_ops" model instead of people having to set it
explicitly.

Even if that doesn't turn out to be a good idea (ie Kirill might have
some reason I'm missing for why he really wants to have an explicit
"anon_vm_ops"), the patches to not have people use the vm_area_cachep
directly seem to be valid cleanups.

But I basically think that with those patches in place, we can:

 - make vm_area_alloc() just default vm_ops to &dummy_vm_ops

 - just take the part of Kirill's patch that does

                vma->vm_ops = &anon_vm_ops;

   and instead of '&anon_vm_ops', set it to NULL.

End result: vma_is_anonymous() continues to work as-is, and we don't
have any false positives because the anon vma's are now _explicitly_
initialized that way.

I'll just do a quick set of extra build and boot tests, and push that
baseline out (but without that final part that would introduce the
dummy_vm_ops).

             Linus



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux