From patchwork Tue Jul 28 16:00:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mathieu Desnoyers X-Patchwork-Id: 11689469 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8A74014B7 for ; Tue, 28 Jul 2020 16:00:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5711920792 for ; Tue, 28 Jul 2020 16:00:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="C1MPTM42" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5711920792 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=efficios.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 329438D0014; Tue, 28 Jul 2020 12:00:26 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 2DA198D000B; Tue, 28 Jul 2020 12:00:26 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C8AB8D0014; Tue, 28 Jul 2020 12:00:26 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 02D698D000B for ; Tue, 28 Jul 2020 12:00:25 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 47D0C33CD for ; Tue, 28 Jul 2020 16:00:25 +0000 (UTC) X-FDA: 77087946810.08.corn95_4a07c7826f6b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id A38771819E63C for ; Tue, 28 Jul 2020 16:00:19 +0000 (UTC) X-Spam-Summary: 1,0,0,89f76abc7f712e9f,d41d8cd98f00b204,mathieu.desnoyers@efficios.com,,RULES_HIT:41:355:379:541:800:960:967:973:988:989:1260:1261:1345:1437:1535:1542:1711:1730:1747:1777:1792:2198:2199:2393:2525:2553:2559:2563:2682:2685:2693:2731:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4605:5007:6119:6120:6261:6653:7514:7901:7903:8660:8957:9025:10004:11026:11233:11658:11914:12043:12050:12296:12297:12517:12519:12555:12895:13148:13161:13229:13230:13846:14096:14181:14664:14721:14877:21080:21250:21324:21451:21611:21627:21795:21939:30003:30054:30055:30090,0,RBL:167.114.26.124:@efficios.com:.lbl8.mailshell.net-62.14.55.100 64.201.201.201;04yg5yzxza54371pz5gp6dei9bofdop5m3wsydxe999toe779dxtcmkeyugm1xf.pbj53bwjs53zh6zuompwnsci7iiityeayru45niogrscufq1oc4ny9jhznq5gb9.k-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainC ache:0,M X-HE-Tag: corn95_4a07c7826f6b X-Filterd-Recvd-Size: 5074 Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 16:00:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id BC8B129A885; Tue, 28 Jul 2020 12:00:14 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id obXD5Ex2Fd8J; Tue, 28 Jul 2020 12:00:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 68EF029A729; Tue, 28 Jul 2020 12:00:14 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 68EF029A729 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1595952014; bh=EsIILeHJT4NfTbu7fm/u4BIXkEOajS4ZSBPxyFmkiW0=; h=From:To:Date:Message-Id; b=C1MPTM42Z8g6VHgVCF52mmaOC722/ltqP/9Td0PZxGWmxIBqwzPf5rhpWwK+ovU8S RNYUsiIAExsUtnDuRD2kexQx2gsoSdjCoJeGf5+22xrz6IK122fJjhRMKyg26jMIIl +BdBndIZpuZVNE27j6+l9TuZ9F8Wdw2Lw7W5p1bQCLjfFtudEPoQ5DJVFKDM1P+Un+ sGSD1Kdfq1tc1MQBmDFETevVpK/EcDh/0EEaViQvOR13mONOw8Wb9MJvuqxkRS6f/J XawgQ6ejD8LLdi2YQ/rgA/zy49gonxTgYtch690QCl3J3FZ9LaJUxQtTTaVq+ck7vA LidJ6g/fIp3Qg== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nWA6AhyGx8a1; Tue, 28 Jul 2020 12:00:14 -0400 (EDT) Received: from thinkos.etherlink (unknown [192.222.236.144]) by mail.efficios.com (Postfix) with ESMTPSA id 2F97229A724; Tue, 28 Jul 2020 12:00:14 -0400 (EDT) From: Mathieu Desnoyers To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , Will Deacon , "Paul E . McKenney" , Nicholas Piggin , Andy Lutomirski , Thomas Gleixner , Linus Torvalds , Alan Stern , linux-mm@kvack.org Subject: [RFC PATCH 1/2] sched: Fix exit_mm vs membarrier Date: Tue, 28 Jul 2020 12:00:09 -0400 Message-Id: <20200728160010.3314-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.11.0 X-Rspamd-Queue-Id: A38771819E63C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: exit_mm should issue memory barriers after user-space memory accesses, before clearing current->mm, to order user-space memory accesses performed prior to exit_mm before clearing tsk->mm, which has the effect of skipping the membarrier private expedited IPIs. The membarrier system call can be issued concurrently with do_exit if we have thread groups created with CLONE_VM but not CLONE_THREAD. The following comment in exit_mm() seems rather puzzling though: /* more a memory barrier than a real lock */ task_lock(current); So considering that spinlocks are not full memory barriers nowadays, some digging into the origins of this comment led me to 2002, at the earliest commit tracked by Thomas Gleixner's bitkeeper era's history at https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/ At that point, this comment was followed by: + /* more a memory barrier than a real lock */ + task_lock(tsk); + tsk->mm = NULL; + task_unlock(tsk); Which seems to indicate that grabbing the lock is really about acting as a memory barrier, but I wonder if it is meant to be a full barrier or just an acquire. If a full memory barrier happens to be needed even without membarrier, perhaps this fix also corrects other issues ? It unclear from the comment what this memory barrier orders though. Is it the chain exit -> waitpid, or is it related to entering lazy TLB ? Signed-off-by: Mathieu Desnoyers Cc: Peter Zijlstra (Intel) Cc: Will Deacon Cc: Paul E. McKenney Cc: Nicholas Piggin Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Linus Torvalds Cc: Alan Stern Cc: linux-mm@kvack.org --- kernel/exit.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/exit.c b/kernel/exit.c index 727150f28103..ce272ec55cdc 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -474,6 +474,14 @@ static void exit_mm(void) BUG_ON(mm != current->active_mm); /* more a memory barrier than a real lock */ task_lock(current); + /* + * When a thread stops operating on an address space, the loop + * in membarrier_{private,global}_expedited() may not observe + * that tsk->mm, and not issue an IPI. Membarrier requires a + * memory barrier after accessing user-space memory, before + * clearing tsk->mm. + */ + smp_mb(); current->mm = NULL; mmap_read_unlock(mm); enter_lazy_tlb(mm, current);