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 98797C021B1 for ; Thu, 20 Feb 2025 13:13:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00BAE2802E3; Thu, 20 Feb 2025 08:13:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EFED72802E2; Thu, 20 Feb 2025 08:13:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D77542802E3; Thu, 20 Feb 2025 08:13:39 -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 BB0412802E2 for ; Thu, 20 Feb 2025 08:13:39 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4953EB72DA for ; Thu, 20 Feb 2025 13:13:39 +0000 (UTC) X-FDA: 83140364958.14.03B518F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id B707E16000A for ; Thu, 20 Feb 2025 13:13:36 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="dinCZ/DN"; spf=pass (imf08.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740057217; 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=KRwMu7e0ceR1Dgr7qaos9+En2kyirds7dYdEYKFuAug=; b=yN9Y0k0K0QvfFmJYjeIMU83XzPdAm/PxOXkpRfhkkxyGEQrOAuR6vRnggtXSkznKB6JGY+ Mly+s6WxKRMrkfZi7BflLui258YdCYJXLkvZ/0Z8oLYLO4aWLaXssH09/iTMxHBwix09kO z8O1IVFnIVEXYOGMrPTQ1yv4gMTVPdA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="dinCZ/DN"; spf=pass (imf08.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740057217; a=rsa-sha256; cv=none; b=09+N5qdNdiZcaQltJCFklvmxPTK7DWbToRdZq7T2MHU6YQckZn7sEH23gFs8VJZlJOJ1mg 7/Ku0Q6JKDZG7ORyxt/x+Aln4mJplTOEOb9r0kZL5fOissyAZmJ22ArnFwvLjOdxtcwWpx qZTAyUHcitQSeYzkEpCbhfjNHDeaKo0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740057216; h=from:from: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; bh=KRwMu7e0ceR1Dgr7qaos9+En2kyirds7dYdEYKFuAug=; b=dinCZ/DNoZOwMhqdj397N63/EtptU8sIBLAi79ZAyAmYpdjxmy33B4el7FobMrBSLNBdOG PXj2zEScq+U4kRNSmfwUBGU4qDMiwj7Nwq/6/vHSFfQlkcoPkYAY9Y95o/UN7GVJQYjKeW B5D4qt3+gYnT2oYHGuKmScoqY5f5eHo= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-504-P5ssSHqvNFi_aaWQjHY5qw-1; Thu, 20 Feb 2025 08:13:34 -0500 X-MC-Unique: P5ssSHqvNFi_aaWQjHY5qw-1 X-Mimecast-MFC-AGG-ID: P5ssSHqvNFi_aaWQjHY5qw_1740057214 Received: by mail-qt1-f199.google.com with SMTP id d75a77b69052e-47202b65720so18296131cf.3 for ; Thu, 20 Feb 2025 05:13:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740057214; x=1740662014; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KRwMu7e0ceR1Dgr7qaos9+En2kyirds7dYdEYKFuAug=; b=fTxCNUoObtooNtnCRKuxSECbsc56bwSkX0aZutTmRylv1bVxt2DOQVAoH0cBe+P42C doqMk3/OZTe3dXICe7K1cws5/Md9cOKkg3iIUYeL7Oe+mtJOQ3k/+i2+q7glCfpbdXwJ n4AVAW4x4ly9LsX8f+flp1N65dhyTgi8EMfEbVzeBs0wMRv8NCRyjwza6Pk0pu82hCOV VkOync4rLpYx4fV3EC1yHHdjI34la7Yif8f4YaQNJSr1slVx5bWRCIRFMVHvxbI39upA 9Do/KkbreKaVCzk+szuwAXD/ZaKBfOKqkXBekVTcIwmEf7oG/MuEBsgeBCPQVliG09N5 JTqA== X-Forwarded-Encrypted: i=1; AJvYcCUjEATr+1Mh/sAxm1H0ij3u6I9Ga+qc4NMuv4UIkBpDw4rfKMeAccOvv3aSttmS7lrfW/5wo9VDyg==@kvack.org X-Gm-Message-State: AOJu0YzDeVk7ZTk2rLj4g/tu7s0L4YyKpq8Syxc3bLAdnoERsB9LbyCB WOOk/oPLbSPS7QPic8ajl50orOXJJYMq9D9WzVbNAM2J2a3KI53VBiUSI7S23XZU/23Wk9MxYar xB1OygXhPjdm05QmEJB7aAPF/4eTSlPVd00xe+ToklkJGpRnD X-Gm-Gg: ASbGnct3hqtHU/avUbi3XZphWDXx85qiLPker+il5pPG4tjXlonxd9cKrY2j3tyizI9 dXLEvGqc1LJnqVoittVWhuxiDnmSCbcIhLhqbswVHLZYTfFBMkTDsAVu/tZH4x6GIzadLayfMNp 3c8YyRvNifWbdTlHiDOnnryExDYBk8deykkH/V1NmzNyvy3U0O4LDgM+vHsJGj52I/pDZyBvRpZ aILt+diTag79jAJXgVsNeClPeELyolsd+KetdIdsfRlQyTKHSVTKWENDHSpALuHuU4R8oXcgIuF HEh96ClBi0Fjj4H/zE1ROGUqcEZR0v1bVmkca3WsO+8yqIMS X-Received: by 2002:ac8:5f96:0:b0:471:c78d:8d84 with SMTP id d75a77b69052e-472082d520emr103517521cf.43.1740057214426; Thu, 20 Feb 2025 05:13:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IGD+qphUNuAPQf2oT13JuhFqAIdVj2mI/geMANnLSv7BrPqLTILeTL4glZCJoafX/ZnUZWiPQ== X-Received: by 2002:ac8:5f96:0:b0:471:c78d:8d84 with SMTP id d75a77b69052e-472082d520emr103516631cf.43.1740057213554; Thu, 20 Feb 2025 05:13:33 -0800 (PST) Received: from ?IPV6:2601:188:c100:5710:627d:9ff:fe85:9ade? ([2601:188:c100:5710:627d:9ff:fe85:9ade]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-472056e87c6sm24826551cf.12.2025.02.20.05.13.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Feb 2025 05:13:32 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <3c09df17-79b2-40d4-a560-f6b1ddbbb73e@redhat.com> Date: Thu, 20 Feb 2025 08:13:31 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] hung_task: Show the blocker task if the task is hung on mutex To: Steven Rostedt , "Masami Hiramatsu (Google)" Cc: Waiman Long , 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 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> <20250220114036.e22e388402a00f7809a81dee@kernel.org> <20250219221141.09f9fe48@gandalf.local.home> In-Reply-To: <20250219221141.09f9fe48@gandalf.local.home> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: QoPyPRq511ClNcIe4bQfGeI6iv3jtKpJYVXAlz_2kV4_1740057214 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 68ghx6czrxzuekhp11xd3bnx6pdobmhf X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B707E16000A X-HE-Tag: 1740057216-458935 X-HE-Meta: U2FsdGVkX1+fQ+u0gUUMPmtwKFwEbZSYfQAd0JXZ89LMMS9yKrKm32rRZOkTJRRxjJfaiNvP/NQniNkowfKRFHqwA+EfpEVtNCZjBGIwIGChPwl0g3NB8pB/4MHccTISEYq/pTnnsUmO2upqcvVmooBLK+pIDxwDHW15NnSfyqgF0aO62P4zrz6n0lPbKaU3QT/nLziyyKkm8YlslF/M0Vtpx0Qr7/HKTRNTI1ALfs6Tvi0zyL5HBe9o8RXHFgX0Qgni9tzRY0g2JUQ6NB02739elG4mhmZMpvloorJa+j38k9ZlLz1h42OXt81BvV0+9R0g240ErWWfla/ng44oIRu/eYtNLsArBIEOqBSlstU5xMq52Z5CawigjZjUcu1Ngvmw4CaaN41lgKYNGVl7FN+aC5fD4fsDQ2Svzr/ut5ShleWUE+cDkXKguft6BbjPEo/9yZI49wo3LTxKl9XrUomAGUqm4DXIhUNai7bfI9aIGTcuvt2+9rIUrSpHIHMgFe2th5vKhfhdEo4RyYlaTQ+r+dgn3fDM7xlOlQY+2bgTe8gOSD04cCVAc7bVjreRW7vlAEopt9TcMRTMb8g9Blt8PKDuIVO5mQjGeVAPqfCY4T7ZYH2QEg//5ZGSnH+Cypt/3QbGuezz9Hh1Mh8MQ8lMq9TQiesM1uvYschdSbnQrLf9qtLBAj6ewlY900SjBciRc6plgs+/xx2Ks7EQD8SoC+qEUf+0lqWWM2gKtRaHldw/9ZAcm4u8wY/K/lFsswpyWEY1UbOREnHLt7hp5sy1Xr3iDXFCTjoNairrARz7O7i9QfixmU84PkWglMRfA9ypJHDkOgC9BqG8A44CZ+dmIXqpkTTR6+QrXDuQEAku6nlP/HBib49JA9Muwu7oeZfEh6eFEAWGL5bOZeg5kl+unbWB8H/7TpXWXFO57aElH/yUpBV57wT4uKFqCfnKqVZ8U853eX/77IXZEyN e+oGctew z/y3i6T8oSaW1I2zdDEKJV7QSKl6aIVAliPKJxv3skR65wWNNqsoPb4N2NHag+yrV+MzW6oPzwyHUS36H0a00gBdPHaGiQuGB9iTMXBs/idAV78BW3bTN3o1XzELvCo+Mg4PvRkFSSlw/pV4j+J+Z/Q8uqg0gM7sxcuUsLz0505NBVzfjjDpQ0z1g1Vm/AY9gmKQeTidi1LejpYN4LEw8ePUz9oamXdl4V8Kz63D88Sf2TeIXFk3ZUl5E+3Og9o8hRIAR+WavubhH0oddo4jO+EfWcF+KKXPEyClos7zyMD1zCek1u6eMmK6I5c7MRz+8NaVt4YbuUnY4gGfNKPQOlXxcWzPDXOHCTGDYO3IPXzweSq4kAU2cN0+6BVfwMsaQYQpgicE85/Y4mEqqScrhk12C5pMGd8XlvbGukCSKAfQQDfZNGbEKejW7RZeCWmXQp89/ciXY532S/vo/Lq9fDKFwT9TOKXFEuVv/IASUKcq55M8JbRkiBCxUrOGcoKA/XjvYM+LPxyQK/u1kMzSFXR9xZRsVyNXPtIjRdGQNmHrcOzXedE32SLZfFA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.117399, 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 2/19/25 10:11 PM, Steven Rostedt wrote: > On Thu, 20 Feb 2025 11:40:36 +0900 > Masami Hiramatsu (Google) wrote: > >> Hmm, right. >> Since the blocked_on must be NULL before setting flag, if we can ensure >> the writing order so that blocked_flags is always updated before >> blocked_on, may it be safe? >> >> Or, (this may introduce more memory overhead) don't use union but >> use different blocked_on_mutex, blocked_on_rwsem, etc. >> >> Another idea is to make the owner offset same, like introducing >> >> struct common_lock { >> atomic_long_t owner; >> }; >> >> But the problem is that rt_mutex does not use atomic for storing >> the owner. (we can make it atomic using wrapper) > Either that, or add to the task_struct: > > struct mutex *blocked_on_mutex; > struct rwsem *blocked_on_rwsem; > struct rtlock *blocked_on_rtlock; > > And just have each type assign to its own type. Then you only need to look > at each one. But yeah, this adds even more bloat to task_struct. > > :-/ Another alternative is to encode the locking type into the lowest 2 bits of the address and combined them into a single atomic_long_t data item. Of course, we can only support 4 different types with this scheme. Cheers, Longman > > -- Steve >