Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753715AbdHKUuK (ORCPT ); Fri, 11 Aug 2017 16:50:10 -0400 Received: from mail-oi0-f52.google.com ([209.85.218.52]:33541 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753256AbdHKUuI (ORCPT ); Fri, 11 Aug 2017 16:50:08 -0400 MIME-Version: 1.0 In-Reply-To: <1502483265.6577.52.camel@redhat.com> References: <20170811191942.17487-1-riel@redhat.com> <20170811191942.17487-3-riel@redhat.com> <1502483265.6577.52.camel@redhat.com> From: Linus Torvalds Date: Fri, 11 Aug 2017 13:50:07 -0700 X-Google-Sender-Auth: TgGlq7y1BDFKdrpmnrdL8QmyY6w Message-ID: Subject: Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK To: Rik van Riel Cc: Linux Kernel Mailing List , Michal Hocko , Mike Kravetz , linux-mm , Florian Weimer , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , Andrew Morton , Kees Cook , Andy Lutomirski , Will Drewry , Ingo Molnar , "Kirill A. Shutemov" , Dave Hansen , Linux API , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 33 On Fri, Aug 11, 2017 at 1:27 PM, Rik van Riel wrote: >> >> Yes, you don't do the page table copies. Fine. But you leave vma with >> the the anon_vma pointer - doesn't that mean that it's still >> connected >> to the original anonvma chain, and we might end up swapping something >> in? > > Swapping something in would require there to be a swap entry in > the page table entries, which we are not copying, so this should > not be a correctness issue. Yeah, I thought the rmap code just used the offset from the start to avoid even doing swap entries, but I guess we don't actually ever populate the page tables without the swap entry being there. > There is another test in copy_page_range already which ends up > skipping the page table copy when it should not be done. Well, the VM_DONTCOPY test is in dup_mmap(), and I think I'd rather match up the VM_WIPEONFORK logic with VM_DONTCOPY than with the copy_page_range() tests. Because I assume you are talking about the "if it's a shared mapping, we don't need to copy the page tables and can just do it at page fault time instead" part? That's a rather different thing, which isn't so much about semantics, as about just a trade-off about when to touch the page tables. But yes, that one *might* make sense in dup_mmap() too. I just don't think it's really analogous to the WIPEONFORK and DONTCOPY tests. Linus