Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1903646pxk; Sun, 13 Sep 2020 21:54:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVwB1jvtTAvVn1h5kVoNTG9RY29uOG+VTCYPZzVakPeg5jY7X0JnH9oKDsuASTX1xk4KgU X-Received: by 2002:a05:6402:176e:: with SMTP id da14mr15598198edb.349.1600059249517; Sun, 13 Sep 2020 21:54:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600059249; cv=none; d=google.com; s=arc-20160816; b=cc3wMjNg0+vTFhvg/fjKpqM9izFeQ+5QQ6ILBBgtQUlOEsz16dKODRb6JZvajl99Rv ipg5THvJnG3RxJRHrZuEcdY0iVbGNiFQYucZfLSSQcB/SQUO0LeKkTbaZSq7kXKMvdEf IkHycPGvM00M3mEM4LP2vc4CkU3CAin6W64jYs4M0aM7XcMD7kyB+0iyjENvSf0Mwe+w 7slTjbB+tG6aluPMgKzHr8rQCEugw1I6CJq/x4jVFMr4XzSntR9jO8Vr4xYnRtuIglbM UJ409Sh7TzBnSRG7KDTmby+AtE8hqHlzzsfxJ53sDgzb7+E5YeLzlpOooH18Acz2H7pO Nm8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=PMGQxaBKPbON3ssZWMqrEm63rTUeWUDOhP6COLqPYSc=; b=JM9EsickIuac5uF2OELnysHcqDQrEqKrOVYHa+Lg6Trm386eGP7AF43UXlLm0pjInf dc+xlHdqmn4GK6UAvK72/7sOFQ842fHxOdRB8eUIOAxChH+VBizp7eM4tnRtrygKYev/ vw1KmjsMMUwz39krSsmaWqJVuQDBED0NLmwkKmElzvkAoveOB2s50ApbD3zU4LDh4U+B vDFFhTK3UQPVya7oCzyMnrycX621BSCps00QyUMBN+TMazPpeeHkw/6ON3J3M0pi/D1z z2TJgc7IAvYe66OlHWFtkGWZfNnqkDjz3MRbujMOkaB4FzMzhRYNTy+5EZMzdjSYbDvN 8VDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E6t5ATL8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x11si6425984edr.460.2020.09.13.21.53.47; Sun, 13 Sep 2020 21:54:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E6t5ATL8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726043AbgINEw4 (ORCPT + 99 others); Mon, 14 Sep 2020 00:52:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbgINEwq (ORCPT ); Mon, 14 Sep 2020 00:52:46 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AF2EC06174A; Sun, 13 Sep 2020 21:52:46 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id k15so11532592pfc.12; Sun, 13 Sep 2020 21:52:46 -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=tlX4wD4UCzzNIEjzglGRZoYOeAMXUDWzkf4/ffz4Nc1XPPULZDqWi9+XZgd0pXgafI AtGb6L6QCiKQ6MZZ1T0XZg30jKTrF4CrEV4wzeYzgunIR6WNrMv5Y01S5u5W8UntrW8E /vZlCZ+S7ZJYXQZE+AP2pVwaMUQZqKj0F6MULLdI4404N9VPisj5eHFgL0wxFdmCNbhv rt550wQuM8mPqxPbzR/pl1SR4BUnbIrcaAYTxCih3se4vUEvskunfg6DMXhXboq6cG8p 5y1lbm9FXXc5MLc1iNJxG7Py9QKE6hFVS4VthbDpWAlVAvxUAz0nBwM0nsSPwIWkzpfy MQgQ== X-Gm-Message-State: AOAM530hEZS6KSyDETWBRhChJkzF+ygVHYsPwv75t7bvXKGGfOIBv1TK 6tMeYsKoXJcYm0lgMImuH3A= 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" Cc: Nicholas Piggin , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org, "Aneesh Kumar K . V" , Andrew Morton , Jens Axboe , Peter Zijlstra , "David S . Miller" 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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