From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16927C43461 for ; Mon, 14 Sep 2020 04:56:27 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1702A208C7 for ; Mon, 14 Sep 2020 04:56:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E6t5ATL8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1702A208C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BqYwl0w92zDqWp for ; Mon, 14 Sep 2020 14:56:23 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::444; helo=mail-pf1-x444.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=E6t5ATL8; dkim-atps=neutral Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4BqYrX5KDJzDqW0 for ; Mon, 14 Sep 2020 14:52:44 +1000 (AEST) Received: by mail-pf1-x444.google.com with SMTP id c196so11700094pfc.0 for ; Sun, 13 Sep 2020 21:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=PMGQxaBKPbON3ssZWMqrEm63rTUeWUDOhP6COLqPYSc=; b=E6t5ATL8gx3qXPR8MutckEOtFp8N/QqyJhBR7KZvwdtkFuAEyC2lhZ2/emCtjTKBmo B0kb2CydVdVNlaob1xulncfmSHsG5MpRJYpG32az5As5jUlalJv5Z1u24HGgsukfOob0 pStFmcZQbhM6RQl6+oGHRZ/T4R+TM1Eyv8T8Wo3EQa0oEPAufWykBkJADQ737q0p9bQY 2R33AJCLbtCHvjVUHJysl92cDr8E/Gps9+AWbHKehyystd+wcHrhzluGm/ArtKvSmZCu bm9w6OFAfNAC+nOJ6NR0QDHwYy2vZD6WeoHYvXZICjq3HwmMDhUuXmKAzk9mSX/KjWa1 XD6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PMGQxaBKPbON3ssZWMqrEm63rTUeWUDOhP6COLqPYSc=; b=ilLT7hhq6CQWaP6R0b47lq9O3s/fhN3XuQhK+sKRbZa0xpFq8Z8MFwtDnk7Hr2GQ3Z ivdrcOQ4IjfrWW4sE1CvYokI+uxLf52o0ij4Trq/Hx2kIE8ZS3eoFGeWEtuyR1uI9Y10 gzVWrPrpfYTKQd/5I97pgCC7RkQpr67u4lCLUEAjXTrNf9yufuevkzvoqt4pJJa/VYkg FP4U0owYk5+BcorPHdy9pVxAUrtI0Yubf+NC2NQgnCoIV2P3tYa2Pfruh4qS2S956Ykx vLdkitYMMTOQAnXh09Sr6IyxiIfeBoMhvtZmJ2Kxx6st3h76+4Kkmkdx9LkFdjklaL2h egxA== X-Gm-Message-State: AOAM533ri8wY2GHB/AXoB1zQBi6nFOXxZtFX+Jx7b2zK9iP3BIO6Kt2j WtxxFcHdZdYnhP0ZqbcA5rs= X-Google-Smtp-Source: ABdhPJyPI7rDf+d21q9NzzsfoVdINl/UoWB/tNDVu6ib1rFaHHxGEc6qLhJCwAhX5Wm+j4pnSX9vTQ== X-Received: by 2002:a17:902:eec7:b029:d1:c2e4:6b58 with SMTP id h7-20020a170902eec7b02900d1c2e46b58mr4791803plb.4.1600059161060; Sun, 13 Sep 2020 21:52:41 -0700 (PDT) Received: from bobo.ozlabs.ibm.com ([203.185.249.227]) by smtp.gmail.com with ESMTPSA id a13sm6945312pgq.41.2020.09.13.21.52.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Sep 2020 21:52:40 -0700 (PDT) From: Nicholas Piggin To: "linux-mm @ kvack . org" Subject: [PATCH v2 1/4] mm: fix exec activate_mm vs TLB shootdown and lazy tlb switching race Date: Mon, 14 Sep 2020 14:52:16 +1000 Message-Id: <20200914045219.3736466-2-npiggin@gmail.com> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20200914045219.3736466-1-npiggin@gmail.com> References: <20200914045219.3736466-1-npiggin@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Jens Axboe , Peter Zijlstra , "Aneesh Kumar K . V" , linux-kernel@vger.kernel.org, Nicholas Piggin , sparclinux@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S . Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Reading and modifying current->mm and current->active_mm and switching mm should be done with irqs off, to prevent races seeing an intermediate state. This is similar to commit 38cf307c1f20 ("mm: fix kthread_use_mm() vs TLB invalidate"). At exec-time when the new mm is activated, the old one should usually be single-threaded and no longer used, unless something else is holding an mm_users reference (which may be possible). Absent other mm_users, there is also a race with preemption and lazy tlb switching. Consider the kernel_execve case where the current thread is using a lazy tlb active mm: call_usermodehelper() kernel_execve() old_mm = current->mm; active_mm = current->active_mm; *** preempt *** --------------------> schedule() prev->active_mm = NULL; mmdrop(prev active_mm); ... <-------------------- schedule() current->mm = mm; current->active_mm = mm; if (!old_mm) mmdrop(active_mm); If we switch back to the kernel thread from a different mm, there is a double free of the old active_mm, and a missing free of the new one. Closing this race only requires interrupts to be disabled while ->mm and ->active_mm are being switched, but the TLB problem requires also holding interrupts off over activate_mm. Unfortunately not all archs can do that yet, e.g., arm defers the switch if irqs are disabled and expects finish_arch_post_lock_switch() to be called to complete the flush; um takes a blocking lock in activate_mm(). So as a first step, disable interrupts across the mm/active_mm updates to close the lazy tlb preempt race, and provide an arch option to extend that to activate_mm which allows architectures doing IPI based TLB shootdowns to close the second race. This is a bit ugly, but in the interest of fixing the bug and backporting before all architectures are converted this is a compromise. Signed-off-by: Nicholas Piggin --- arch/Kconfig | 7 +++++++ fs/exec.c | 17 +++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index af14a567b493..94821e3f94d1 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -414,6 +414,13 @@ config MMU_GATHER_NO_GATHER bool depends on MMU_GATHER_TABLE_FREE +config ARCH_WANT_IRQS_OFF_ACTIVATE_MM + bool + help + Temporary select until all architectures can be converted to have + irqs disabled over activate_mm. Architectures that do IPI based TLB + shootdowns should enable this. + config ARCH_HAVE_NMI_SAFE_CMPXCHG bool diff --git a/fs/exec.c b/fs/exec.c index a91003e28eaa..d4fb18baf1fb 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1130,11 +1130,24 @@ static int exec_mmap(struct mm_struct *mm) } task_lock(tsk); - active_mm = tsk->active_mm; membarrier_exec_mmap(mm); - tsk->mm = mm; + + local_irq_disable(); + active_mm = tsk->active_mm; tsk->active_mm = mm; + tsk->mm = mm; + /* + * This prevents preemption while active_mm is being loaded and + * it and mm are being updated, which could cause problems for + * lazy tlb mm refcounting when these are updated by context + * switches. Not all architectures can handle irqs off over + * activate_mm yet. + */ + if (!IS_ENABLED(CONFIG_ARCH_WANT_IRQS_OFF_ACTIVATE_MM)) + local_irq_enable(); activate_mm(active_mm, mm); + if (IS_ENABLED(CONFIG_ARCH_WANT_IRQS_OFF_ACTIVATE_MM)) + local_irq_enable(); tsk->mm->vmacache_seqnum = 0; vmacache_flush(tsk); task_unlock(tsk); -- 2.23.0