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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AC3FC27C79 for ; Thu, 20 Jun 2024 20:20:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 295468D00DD; Thu, 20 Jun 2024 16:20:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 245D38D00DB; Thu, 20 Jun 2024 16:20:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E69A8D00DD; Thu, 20 Jun 2024 16:20:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E3F308D00DB for ; Thu, 20 Jun 2024 16:20:16 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8FB3C1C1244 for ; Thu, 20 Jun 2024 20:20:16 +0000 (UTC) X-FDA: 82252384032.13.AF339EF Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 5B3201C0006 for ; Thu, 20 Jun 2024 20:20:13 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=QbA0ZBkv; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718914809; a=rsa-sha256; cv=none; b=rTCNpKsLUWLshW8Vv1wOihMysxnnDQivENw3tcw3A/YoGlsCkkF3bUXZ7OkNhCyz/Xl1Ir yPLwC7xseV2/8xEmuWQ6FhZ6KPOooWq0CB3kbYR5oiuvjWUyHcT0c7PuBWHeUMkFSkBAQD 3Hj2KOgs8E+VuvjGBLGSXrxqRjY2GHQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=QbA0ZBkv; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718914809; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D6tagPsl0RjxtMxj4/Yv87TuBvSncEPlgwc/RMrZMik=; b=2Kc76dXaEr9MhfkQKtrMZT6TKsbfrMt7XBkBr/Qv52T8jEl5ihq07D61PzwPRG6t4I6HiF mRXBvlh1SztsaB50t58XUl4pzbSav64f6FCt06jQUJ3MCYlsXd+Y/DrX+TYCxJH4yuuhMe Pv8c+i3bjTo21Dcnv/pDlQ6yertpRNQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 0AD1DCE28EB; Thu, 20 Jun 2024 20:20:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2DFCC4AF09; Thu, 20 Jun 2024 20:20:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1718914810; bh=PtxNTecXGccGW5GNzW6Jx+zQBTKFKysFM00Tb72eOWg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QbA0ZBkv3vOJ4F6l5i8kroD30/BnBfE+660CSwKPvAulAu/jcGt4hodf1cfAJqbxU 1QeMrUyahNbj2As8zNDgDUn+PCRBMYJ0WTvHjeza1Xrm+FiGHC3befdMwTpkJ9CUB9 LV7hoUEWqdwXmjwhYi5xAttpyHaSgMvQpbsdO20w= Date: Thu, 20 Jun 2024 13:20:09 -0700 From: Andrew Morton To: alexjlzheng@gmail.com Cc: brauner@kernel.org, axboe@kernel.dk, oleg@redhat.com, tandersen@netflix.com, willy@infradead.org, mjguzik@gmail.com, alexjlzheng@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: optimize the redundant loop of mm_update_owner_next() Message-Id: <20240620132009.d354aadd6e79999f2d61dd14@linux-foundation.org> In-Reply-To: <20240620122123.3877432-1-alexjlzheng@tencent.com> References: <20240620122123.3877432-1-alexjlzheng@tencent.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: jxdyk7cbhott14xx1dz9h4c78ef1tntm X-Rspamd-Queue-Id: 5B3201C0006 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1718914813-988528 X-HE-Meta: U2FsdGVkX19r2aXFnpwVy0XLgpEqIO7mwM1NPimWVVnouEKxgIyn4Zf29S4dg69BmJp5S36MUXzJsH5HmhlhNr8KsaddUnU+8OgsaWwOj7A4fGoQcuTFk/mrc+S9RMqvQ1KZRTpMLiTucDaLVkNlluawQbxdEXSBTSX+6EHOaiYYn3zkp2KNBni6MBlzKZ7fBh+MzlbBzC4PD85hzJ4tjc8NTsZX7yLORhDIx7fjh5MnOtMYawmhGtSs1ufwigFGgajgI/EBe+gMZjMmvSQ+hvq+0JvHZre/nCji5ptIK7S/PS5pSGgk+MIy6IZoMKhyyaKpbz09Slmg6y54ECVo7JSiMaaZ7Kzq8gKePvfH+iqS6n3pEfNUz2mik79CyYhOzOHopClNVbMMV4EKovvu1rYtfz/t6nO3v5FQX1386sKmp1LTQkXKueAenTcJGwEPUHK46iubX8TjP4ZeAhwGhsNgBMcFQbv+BqW/ES5P0T7+3ONEXRC2QyWJ6nQEXTnklYriLGM9jqMqwN360p33Oz4belLhZM5cLG5FXzzpbpqOUNoReh7oj6nGm5BKJKwBwNUDDv5BfzXuikjwujsozPiA8Z2gGGsvhcS4lzcFm6Z4vFaZrU7xdJYgSiymstpDtkAFoax3fmgDVsARHb6w0NLGdHkB5gf/8f/B+u6ZMQGV3uqUTJ2Z7UXJYAY9rUh2eFtSUk3jPdC5eQLD2ZGQ79RUM6i+9MSkXHTjhNqLqxIRRbuihzXWDxcXOLdvRYccE7rzsDh88vf49rAN4xEiv75dam6R3avIf2KBEMhJePoT1J1TH1DiiCx899/q0d15+PRkCN+LAuzU0C0R1rKWJB/NmxsUs9tdX+sdpljArkp2reTls8Q4o/AOO+7BaoaLigSVrqZdTQmpgeN+gfsHRRzuetcRclvrcpPYiMOaXBZwksQrMu+XezaBikA1sk9nu3R7xE+EQAe+8NmLfvy HnNQ1Ye3 JfmCTvjltHUF48iBd4XIygwlTb0mgeyy0PAXdK1Wgd1JLhjpA3CsiYGeAuk6LDDciGowCDx6p8l5JTBLy4FvXr7NtzYMzZYloT3OcyTMScFgJ7QQjSiyQr3mLogBAtx40sHIZQ1uZuTRASDeIovDxFyDKBGNnd2mm2aQFF/al2qyFwPIa6s4HyDp7X3dlgjUrDB6oHz3Ilz4aBm5JMjWqaKXLIGs7HjXu/VtZ4NFPInNPJvj4+o3iWP+RDQKWOI1fj5KJofWDsAApTht/Pu5A7eOJAy0gqskMBbXGTj6YsMjBPMjvGrLlwFbGZngEnpuegarYZv58OLby5/XxE+FULULRw0lHJak/P4Vx 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: List-Subscribe: List-Unsubscribe: On Thu, 20 Jun 2024 20:21:24 +0800 alexjlzheng@gmail.com wrote: > From: Jinliang Zheng > > When mm_update_owner_next() is racing with swapoff (try_to_unuse()) or /proc or > ptrace or page migration (get_task_mm()), it is impossible to find an > appropriate task_struct in the loop whose mm_struct is the same as the target > mm_struct. > > If the above race condition is combined with the stress-ng-zombie and > stress-ng-dup tests, such a long loop can easily cause a Hard Lockup in > write_lock_irq() for tasklist_lock. This is not an optimization! Userspace-triggerable hard lockup is a serious bug. > Recognize this situation in advance and exit early. > > Signed-off-by: Jinliang Zheng > --- > kernel/exit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/exit.c b/kernel/exit.c > index f95a2c1338a8..81fcee45d630 100644 > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -484,6 +484,8 @@ void mm_update_next_owner(struct mm_struct *mm) > * Search through everything else, we should not get here often. > */ > for_each_process(g) { > + if (atomic_read(&mm->mm_users) <= 1) > + break; > if (g->flags & PF_KTHREAD) > continue; > for_each_thread(g, c) { I agree that the patch is an optimization in some cases. But does it really fix the issue? Isn't the problem simply that this search is too lengthy? Isn't it still possible for this search to have taken too much time even before the new test triggers? I wonder if this loop really does anything useful. "we should not get here often". Well, under what circumstances *do* we get here? What goes wrong if we simply remove the entire loop?