On Wed, Aug 27, 2014 at 04:12:43PM -0700, Hugh Dickins wrote: > > > > > > Weak argument to me. > > Yes. However rarely it's modified, we don't want any chance of it > corrupting another flag. > > VM_SOFTDIRTY is special in the sense that it's maintained in a very > different way from the other VM_flags. If we had a little alignment > padding space somewhere in struct vm_area_struct, I think I'd jump at > Kirill's suggestion to move it out of vm_flags and into a new field: > that would remove some other special casing, like the vma merge issue. > > But I don't think we have such padding space, and we'd prefer not to > bloat struct vm_area_struct for it; so maybe it should stay for now. > Besides, with Peter's patch, we're also talking about the locking on > modifications to vm_page_prot, aren't we? I think so. > > > What about walk through vmas twice: first with down_write() to modify > > > vm_flags and vm_page_prot, then downgrade_write() and do > > > walk_page_range() on every vma? > > > > I still it's undeeded, > > Yes, so long as nothing else is doing the same. > No bug yet, that we can see, but a bug in waiting. :-) > > > but for sure using write-lock/downgrade won't hurt, > > so no argues from my side. > > Yes, Kirill's two-stage suggestion seems the best: > > down_write > quickly scan vmas clearing VM_SOFT_DIRTY and updating vm_page_prot > downgrade_write (or up_write, down_read?) > slowly walk page tables write protecting and clearing soft-dirty on ptes > up_read > > But please don't mistake me for someone who has a good grasp of > soft-dirty: I don't. Thanks for sharing opinion, Hugh! (And thanks for second email about vma-flags) So lets move it to Kirill's way, otherwise indeed one day it might end up in a bug which for sure will not be easy to catch. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>