From patchwork Tue Jun 14 18:54:56 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1643383 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=RDScISSw; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4LMyLC49Wfz9vF7 for ; Wed, 15 Jun 2022 04:55:15 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1o1Bgz-0006Gs-Bt; Tue, 14 Jun 2022 18:55:09 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1o1Bgv-0006Ez-SH for kernel-team@lists.ubuntu.com; Tue, 14 Jun 2022 18:55:05 +0000 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 888683F210 for ; Tue, 14 Jun 2022 18:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1655232905; bh=UXwZTe3QnLsDl4AoRMBkHXPoyF6UoIlyB+bYigmhCs0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=RDScISSwlESaVCn1j+E7jZrBmLaVAyE73QX+v28ndQtQrVVx1j9jOEystGJytP9s+ FjIi7o3Ux3vrKFbTUF3qUEE++/KNE/7Z9IRDTxPAIsFI9RbnfvqpAzOQFqJOyhNqpB 0ZL0BWAtxz2wQsQPUVha6zKjLtxzJvNGwx0TYEeQU6jh0aHxmE8YQw1AOdsDBlmSPF 81WylOk7k8N6kcbb9010qphNUXuvsfQBojjH8ALsxY7HZNfspWY95VnnL2ByYO6DZ6 xXzkHPJF7LwhcMLACDdUHu+iudk2mNSJ2Kc43uEJ6aqNWbw9DIPhSYcUVIcCkTI6RU dSWcn6NPUr5yg== Received: by mail-pl1-f197.google.com with SMTP id p2-20020a170902e74200b00164081f682cso5238877plf.16 for ; Tue, 14 Jun 2022 11:55:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UXwZTe3QnLsDl4AoRMBkHXPoyF6UoIlyB+bYigmhCs0=; b=VBcBphz89mlTO0pTr9zBHliIsL0iy8qoha2fV9Cvh9X4dRQ/B+EjGO6htXpJ1msgT1 7EVY0ykPJJypFuz27jMRB/ZCkcsqCISUWYAVu5pg1RKbZAYGIG4R6ATuCsMiBwZr+OLu UupJVcG8vpdFQbOQzRjhiEWkOWcvPzGGX1n0rX71DcjyuOaYKsg58BVGfK7lZ22krZXr krUtIzHLDAdXQg/R/uujpZ4qkkT/Hdw04Nk2PcCngx9t/M5mJEtJn7LbtFtLW7Mv24h6 8muhVe+4uMAWZZ0H5zNRifQmzuBMHruBSyPxjhKKjpi7i8WOiP/BjKtmyTFmnhF2qYzT mJ3g== X-Gm-Message-State: AOAM532yDSHDxFb+sfBfLd01BMGCuijjWOvUi7VpHu8DNsa+4qZcCQAg mtCQXPaIAsX6urmFnIN5fVxkZJmwyKem8xru7gtvnyZlb+7VSSBEsOTueaE3dgiXBS9aAXo0UUI TIjEpczX6tXDgB83kOYADILJr46oXfPF+ZYLno2BtLw== X-Received: by 2002:a63:3184:0:b0:3fc:5893:c866 with SMTP id x126-20020a633184000000b003fc5893c866mr5675323pgx.56.1655232903708; Tue, 14 Jun 2022 11:55:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJoCWgaE82wSePKVTgl4fB9FHOFKR5LNc4AOj8HxeF5aAMQ1BmSlQ6aeyI825pnnNUdyY5aQ== X-Received: by 2002:a63:3184:0:b0:3fc:5893:c866 with SMTP id x126-20020a633184000000b003fc5893c866mr5675303pgx.56.1655232903386; Tue, 14 Jun 2022 11:55:03 -0700 (PDT) Received: from localhost.localdomain ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id u20-20020a62d454000000b00518285976cdsm7937102pfl.9.2022.06.14.11.55.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jun 2022 11:55:02 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH] mm: rmap: explicitly reset vma->anon_vma in unlink_anon_vmas() Date: Tue, 14 Jun 2022 12:54:56 -0600 Message-Id: <20220614185456.14339-2-tim.gardner@canonical.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220614185456.14339-1-tim.gardner@canonical.com> References: <20220614185456.14339-1-tim.gardner@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Li Xinhai BugLink: https://bugs.launchpad.net/bugs/1978719 In case the vma will continue to be used after unlink its relevant anon_vma, we need to reset the vma->anon_vma pointer to NULL. So, later when fault happen within this vma again, a new anon_vma will be prepared. By this way, the vma will only be checked for reverse mapping of pages which been fault in after the unlink_anon_vmas call. Currently, the mremap with MREMAP_DONTUNMAP scenario will continue use the vma after moved its page table entries to a new vma. For other scenarios, the vma itself will be freed after call unlink_anon_vmas. Link: https://lkml.kernel.org/r/20210119075126.3513154-1-lixinhai.lxh@gmail.com Signed-off-by: Li Xinhai Cc: Andrea Arcangeli Cc: Brian Geffon Cc: Kirill A. Shutemov Cc: Lokesh Gidra Cc: Minchan Kim Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds (cherry picked from commit ee8ab1903e3d912d8f10bedbf96c3b6a1c8cbede) Signed-off-by: Tim Gardner --- mm/rmap.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mm/rmap.c b/mm/rmap.c index 6d80e92688fe..24a9bf234010 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -401,8 +401,15 @@ void unlink_anon_vmas(struct vm_area_struct *vma) list_del(&avc->same_vma); anon_vma_chain_free(avc); } - if (vma->anon_vma) + if (vma->anon_vma) { vma->anon_vma->degree--; + + /* + * vma would still be needed after unlink, and anon_vma will be prepared + * when handle fault. + */ + vma->anon_vma = NULL; + } unlock_anon_vma_root(root); /*