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 25BB8C021AA for ; Thu, 20 Feb 2025 02:59:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA4C28028F; Wed, 19 Feb 2025 21:59:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 79A6A28028C; Wed, 19 Feb 2025 21:59:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 661B228028F; Wed, 19 Feb 2025 21:59:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 44C3528028C for ; Wed, 19 Feb 2025 21:59:11 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E64AE1C7F4E for ; Thu, 20 Feb 2025 02:59:10 +0000 (UTC) X-FDA: 83138816460.05.CF9C44C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 1B5324000E for ; Thu, 20 Feb 2025 02:59:08 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Me2JUzDA; spf=pass (imf07.hostedemail.com: domain of mhiramat@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740020349; 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=GhP1yDDrph/JuWwY80W4XLeXdIo8yjmUcgGtNxCmE/I=; b=DRorkjj5OiZbfhAdNsFPiF0ZuvRDbKiaAceTuVB4HPIBnz14bQBf5UwNowVeYnEOibdrTg DNUErpa+3SodoEMxT/4yp4xTrVqzMNCs5MHmEZPyPysDtMfBHaVjJvm4Zx7R3Fzlk8JaXt G3X1BwkSDIUEBP/MPpvNbcvoQSsY6mk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Me2JUzDA; spf=pass (imf07.hostedemail.com: domain of mhiramat@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mhiramat@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740020349; a=rsa-sha256; cv=none; b=Uo7vKFOxpN38r7L7d+3G9+s+jCVX9AsceGP7Fc+D0xQRSDx0P6K9NMDK8o/h8hxdno6r19 FPWIj+WwdEMBYaBxJQAw9JG0AN+9GpNwpn4pMnecJSmc/ckE7WQH/AzSncwQ2Qs0BEb89c MDLpMCPpHYvAxgsDNi1MgkUtq+oLa1U= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0F6B95C5D2A; Thu, 20 Feb 2025 02:58:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9C23C4CED6; Thu, 20 Feb 2025 02:59:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740020347; bh=qxlbp61yjI+I+JkQgUjpC/7VWQfvXJER9+L9movOxlQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Me2JUzDAOt/HClU/4uOTUfde1glc+kjNA5t75Td9QdOPFGckmA/r7gjWW0hZY62YJ oDe/F5GYJvja6SBzgtnm54x05v3FhBKLuXcn9JAWLmU8dgbPxYw8wNjoQBGGZtwA30 96upBtyFPOBIlEYiAzbR6Q35relfVnDyWT05DdqVQ/khLdicst2UNGRtu1DogSN5kd YOePfDdAZfTAIyv0i8c7ike3iroNqH2Y4HtmhK3xVKXKBAuKYbODdmElR/HxQmH86N txswjAS4sJiWeJUD0PBzIYGQQXxyLLY8yaWVq7xodmgtDsZqfyUDjKqfnsFOleize7 ntMrKkmYXGTig== Date: Thu, 20 Feb 2025 11:59:04 +0900 From: Masami Hiramatsu (Google) To: Waiman Long Cc: Steven Rostedt , "Masami Hiramatsu (Google)" , Peter Zijlstra , Ingo Molnar , Will Deacon , Andrew Morton , Boqun Feng , Joel Granados , Anna Schumaker , Lance Yang , Kent Overstreet , Yongliang Gao , Tomasz Figa , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Linux Memory Management List Subject: Re: [PATCH 1/2] hung_task: Show the blocker task if the task is hung on mutex Message-Id: <20250220115904.051e0cc55a9cb88302582ef4@kernel.org> In-Reply-To: <9f9150b4-1cf5-4380-b431-419f70775a7d@redhat.com> References: <173997003868.2137198.9462617208992136056.stgit@mhiramat.tok.corp.google.com> <173997004932.2137198.7959507113210521328.stgit@mhiramat.tok.corp.google.com> <20250219112308.5d905680@gandalf.local.home> <0fa9dd8e-2d83-487e-bfb1-1f5d20cd9fe6@redhat.com> <20250219152435.35077ac3@gandalf.local.home> <20250220075639.298616eb494248d390417977@kernel.org> <20250219204153.65ed1f5e@gandalf.local.home> <9f9150b4-1cf5-4380-b431-419f70775a7d@redhat.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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 1B5324000E X-Stat-Signature: 93tahxtehtx14xgcku3gfbjyutpjnaqb X-Rspamd-Server: rspam03 X-HE-Tag: 1740020348-132257 X-HE-Meta: U2FsdGVkX1+AGDHkGakzGhJ/iJ9NaP+NOBYXNZ3vPZsZsXjVr6ipaTa6CbWtv1ZJCaooa9AJE02L8hNDMlN7w8GZNeelih385GXzcZPF0NqUOSGmclzetOmJkmgJapX9iEw43fmOB8G47ExGup6ZPnkYLt7R0Zhh11Ag4466E7B5PBW6m/SkqgteTtR+CHaqyyoG+sjbZSbsIepcPxrTsTps3y7UyUXExd3RsN481X6CxmLJ7VXR71li4H2jQMuk8fT/U0iP40cyKWd/lmg9N/rl2UO+UkD+9C5mxFFUTeUxG279opfTugUtbsibEuyvPa7rsST+8myRibj4uLdBhqo4Bc+YW95Pmyrd1v7+xmRnp6DLcVN1RxP3Alp4WirRAapoGPrZZv3X4BhANee99XeFKhUBXy5lPA2F8AyfdCeiP3w5adNMigqV3wXX7Lthnyk78AQyXLManYhAZ2YVdVTTtlIPGWE87MSORiBl6frAV5B3WHv6SZMoFcUmw3ZFM8HUZUVtRcAU7i5sMa7L+RlJS2rjhpbhZk29H8MIdjMLNRY2pCJELDKgOFC814Tj37WO6CDjnR/ViN/ZLWdDQsUHhzdZ73sz2ZQVhzy+udZRaCKnDCqAAAxfOIjHTCD2w8e5nY+9ioATSR62mk9F1zYA8FkaExg1GaCwSjAHMJKhYRN7FxPsIuN//HeC7r1Ov4AzfUcgfa9DI8HFCxt5OVhic1Qz3mFAqGNLL0TCZvR2ATpNNz5Df4cRmwvvwaavyeMP7IVrP3gCOPlTb/qDTcuRPv3UtHgUwaCn5BezzTOfjPDzYVvE6nMf6x1vhNvh0iAZ6a8aF4shmbIvudNw22m1Y7qKwnCuikeXNYDgvvwcOuWqLc7GHy0t0Nq9oUjMpP5ehGimAxKDqkOKJYgSXPB3jUMT4JEWJWg5XSXmQtAX4NcOYAr+Fvqj+qDl8KxNe3f/7hMfSu0bB/ikkxp ADjGzpC7 RjR8DFk+EruzwFN5Tsi5MFzRrtxXzZebl/pesoVgtDUcW5NjJsPcyJbzYjlzxbKbIfXqhNtJI6gZBTb9PJT4MLepqzcfY0kZGTVb+DTsKu/hdkGgvc5ukVLuRwAgY6Kjm+mhQatoTCDiMO8Tm+GBl17Jyl8dFuqWaDoX2EtHdfejM7/ow1AYeRyxpRvKfph2UEhEkGhjXuJ41tpzkKb9mZEJTMRFMpOR0/lGkjIcn8ncX6p98/FaA2r6eicdbySzBE5rNKkeMJ17Oxxn3fIp6haUjpkDVfaGR5TowYyPUnuxQ3kW24GoROhNXV21hrViGXmCMi9lDFUnC6g9Gr4oj/ZC63WNMjZ5Cn2LL5CjhV2CVlS0NIYh6LXhxx65bxUDCxQAeXjA0nHTOoJHtzXR6an6N4CornyxYcVS6bu8vnx/Zvql/tV2YU5aVdQ== 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 Wed, 19 Feb 2025 21:15:08 -0500 Waiman Long wrote: > > On 2/19/25 8:41 PM, Steven Rostedt wrote: > > On Wed, 19 Feb 2025 20:36:13 -0500 > > Waiman Long wrote: > > > > > >>>>>> this field, we don't need to take lock, though taking the wait_lock may > >>>>>> still be needed to examine other information inside the mutex. > >>> Do we need to take it just for accessing owner, which is in an atomic? > >> Right. I forgot it is an atomic_long_t. In that case, no lock should be > >> needed. > > Now if we have a two fields to read: > > > > block_flags (for the type of lock) and blocked_on (for the lock) > > > > We need a way to synchronize the two. What happens if we read the type, and > > the task wakes up and and then blocks on a different type of lock? > > > > Then the lock read from blocked_on could be a different type of lock than > > what is expected. > > That is different from reading the owner. In this case, we need to use > smp_rmb()/wmb() to sequence the read and write operations unless it is > guaranteed that they are in the same cacheline. One possible way is as > follows: > > Writer - setting them: > >     WRITE_ONCE(lock) >     smp_wmb() >     WRITE_ONCE(type) > > Clearing them: > >     WRITE_ONCE(type, 0) >     smp_wmb() >     WRITE_ONCE(lock, NULL) > > Reader: > >     READ_ONCE(type) > again: >     smp_rmb() >     READ_ONCE(lock) >     smp_rmb() >     if (READ_ONCE(type) != type) >         goto again What about mutex-rwsem-mutex case? mutex_lock(&lock1); down_read(&lock2); mutex_lock(&lock3); The worst scenario is; WRITE_ONCE(lock, &lock1) smp_wmb() WRITE_ONCE(type, MUTEX) READ_ONCE(type) -> MUTEX WRITE_ONCE(type, 0) smp_wmb() WRITE_ONCE(lock, NULL) WRITE_ONCE(lock, &lock2) READ_ONCE(lock) -> &lock2 smp_wmb() WRITE_ONCE(type, RWSEM) WRITE_ONCE(type, 0) smp_wmb() WRITE_ONCE(lock, NULL) WRITE_ONCE(lock, &lock3) smp_wmb() WRITE_ONCE(type, MUTEX) READ_ONCE(type) -> MUTEX == MUTEX WRITE_ONCE(type, 0) smp_wmb() WRITE_ONCE(lock, NULL) "OK, lock2 is a MUTEX!" So unless stopping the blocker task, we can not ensure this works. But unless decode the lock, we don't know the blocker task. Maybe we can run the hung_task in stop_machine()? (or introduce common_lock) Thank you, -- Masami Hiramatsu (Google)