On Fri, 29 Jun 2018 19:28:15 -0700 Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx> wrote: > > > > we're adding a bunch of code to 32-bit kernels which will never be > > executed. > > > > I'm thinking it would be better to be much more explicit with "#ifdef > > CONFIG_64BIT" in this code, rather than relying upon the above magic. > > > > But I tend to think that the fact that we haven't solved anything on > > locked vmas or on uprobed mappings is a shostopper for the whole > > approach :( > > I agree it is not that perfect. But, it still could improve the most use > cases. Well, those unaddressed usecases will need to be fixed at some point. What's our plan for that? Would one of your earlier designs have addressed all usecases? I expect the dumb unmap-a-little-bit-at-a-time approach would have? > For the locked vmas and hugetlb vmas, unmapping operations need modify > vm_flags. But, I'm wondering we might be able to separate unmap and > vm_flags update. Because we know they will be unmapped right away, the > vm_flags might be able to be updated in write mmap_sem critical section > before the actual unmap is called or after it. This is just off the top > of my head. > > For uprobed mappings, I'm not sure how vital it is to this case. > > Thanks, > Yang > > >
