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=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 A1C33C43457 for ; Tue, 13 Oct 2020 23:48:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CBE221582 for ; Tue, 13 Oct 2020 23:48:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="KdnXX8f1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CBE221582 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C9FD26B0089; Tue, 13 Oct 2020 19:48:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4F756B008A; Tue, 13 Oct 2020 19:48:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8C9B6B008C; Tue, 13 Oct 2020 19:48:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 8CF686B0089 for ; Tue, 13 Oct 2020 19:48:52 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 183371EE6 for ; Tue, 13 Oct 2020 23:48:52 +0000 (UTC) X-FDA: 77368544904.21.box03_170041e27207 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 08808180442C7 for ; Tue, 13 Oct 2020 23:48:52 +0000 (UTC) X-HE-Tag: box03_170041e27207 X-Filterd-Recvd-Size: 3595 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 13 Oct 2020 23:48:51 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9FBCB22200; Tue, 13 Oct 2020 23:48:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602632931; bh=9BuS3tGWmxiV+VoM6tl+rvsPXTd7Br6j53ufCjVaIGQ=; h=Date:From:To:Subject:In-Reply-To:From; b=KdnXX8f1o/i/TPRdeaxbPwJa6wOYiqT94QmJMKZ9Ng9//r1bw/HB0oqPGaTSqzBNw HTW3jBKtFPX17JP3aDjHty7I8aXtatD6knROO7X0BDrcA6pndheCCUJSHHiw57F2hh My+13dCdAaxb49fjfpoDnBvD7VpXIupBCDkPUVZE= Date: Tue, 13 Oct 2020 16:48:50 -0700 From: Andrew Morton To: akpm@linux-foundation.org, cai@lca.pw, catalin.marinas@arm.com, dave@stgolabs.net, dbueso@suse.de, linux-mm@kvack.org, mm-commits@vger.kernel.org, oleg@redhat.com, torvalds@linux-foundation.org Subject: [patch 024/181] mm/kmemleak: rely on rcu for task stack scanning Message-ID: <20201013234850.AsSd7RSbj%akpm@linux-foundation.org> In-Reply-To: <20201013164658.3bfd96cc224d8923e66a9f4e@linux-foundation.org> User-Agent: s-nail v14.8.16 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: From: Davidlohr Bueso Subject: mm/kmemleak: rely on rcu for task stack scanning kmemleak_scan() currently relies on the big tasklist_lock hammer to stabilize iterating through the tasklist. Instead, this patch proposes simply using rcu along with the rcu-safe for_each_process_thread flavor (without changing scan semantics), which doesn't make use of next_thread/p->thread_group and thus cannot race with exit. Furthermore, any races with fork() and not seeing the new child should be benign as it's not running yet and can also be detected by the next scan. Avoiding the tasklist_lock could prove beneficial for performance considering the scan operation is done periodically. I have seen improvements of 30%-ish when doing similar replacements on very pathological microbenchmarks (ie stressing get/setpriority(2)). However my main motivation is that it's one less user of the global lock, something that Linus has long time wanted to see gone eventually (if ever) even if the traditional fairness issues has been dealt with now with qrwlocks. Of course this is a very long ways ahead. This patch also kills another user of the deprecated tsk->thread_group. Link: https://lkml.kernel.org/r/20200820203902.11308-1-dave@stgolabs.net Signed-off-by: Davidlohr Bueso Acked-by: Catalin Marinas Acked-by: Oleg Nesterov Reviewed-by: Qian Cai Signed-off-by: Andrew Morton --- mm/kmemleak.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/mm/kmemleak.c~mm-kmemleak-rely-on-rcu-for-task-stack-scanning +++ a/mm/kmemleak.c @@ -1471,15 +1471,15 @@ static void kmemleak_scan(void) if (kmemleak_stack_scan) { struct task_struct *p, *g; - read_lock(&tasklist_lock); - do_each_thread(g, p) { + rcu_read_lock(); + for_each_process_thread(g, p) { void *stack = try_get_task_stack(p); if (stack) { scan_block(stack, stack + THREAD_SIZE, NULL); put_task_stack(p); } - } while_each_thread(g, p); - read_unlock(&tasklist_lock); + } + rcu_read_unlock(); } /* _