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 69A98C021B2 for ; Thu, 20 Feb 2025 13:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0AE82802E6; Thu, 20 Feb 2025 08:28:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EBB082802E2; Thu, 20 Feb 2025 08:28:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5BCA2802E6; Thu, 20 Feb 2025 08:28:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B6B5B2802E2 for ; Thu, 20 Feb 2025 08:28:37 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6257BA3525 for ; Thu, 20 Feb 2025 13:28:37 +0000 (UTC) X-FDA: 83140402674.15.DC888E5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf20.hostedemail.com (Postfix) with ESMTP id D3C6A1C0010 for ; Thu, 20 Feb 2025 13:28:34 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AX99E1yU; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740058115; a=rsa-sha256; cv=none; b=E6gca/hly/oFvY6e/2OgvbTvwek/iXYq9ZwQ3hG98e3Q5hUaQW6ZLjXGeyk4yhfZTUrq+t roSknYnTNR7/IgysAjeH6ACs4mqZObSBRyk7CR3hoHbSdUvMMSIknwYtx6++U3NWRJOW0l IB7kFQ5UP115/T83vSbHvJh5/3WAUks= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AX99E1yU; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf20.hostedemail.com: domain of llong@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=llong@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740058115; 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=UEfE+oQZ6m0RLdfUPRWERlu8bLJ41aEcuNufBb3jHao=; b=WgUtNAY/Pm09q0rleZYQzpyLEeBXpXtNUGm8e4KvlmCZxNMXKLTuDbSqSzzVRaQ5gfdmR2 OxTjDFOhmk8bKWxibY0K9L6/+xLCEL3plUzTYISOQ3VeeLh5pbZKtUIfVTz9e9fFFPJedX eiffOZraKvkHTktCm2fojHaLyLiuvQI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740058114; 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=UEfE+oQZ6m0RLdfUPRWERlu8bLJ41aEcuNufBb3jHao=; b=AX99E1yU+1/dZPbjmy+z4V7yKazk8GNPvVaou2KMJTYRt5WNjZ+Pb48AV5cZ7+Mv+PemDj ZqL2e5HM8+c7mzB5y1rp27T6gGX6afOcEjaCA+2NaYc6ho1xtAEzmOWr/D5tAvaZPbIxsu RALCWkwcFoOWC1rlnaAXB+mS8IOvbl8= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-618-ENzuii3WNSSLuPQA6L6eyQ-1; Thu, 20 Feb 2025 08:28:33 -0500 X-MC-Unique: ENzuii3WNSSLuPQA6L6eyQ-1 X-Mimecast-MFC-AGG-ID: ENzuii3WNSSLuPQA6L6eyQ_1740058113 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6e66c406bb4so18014356d6.0 for ; Thu, 20 Feb 2025 05:28:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740058112; x=1740662912; 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=UEfE+oQZ6m0RLdfUPRWERlu8bLJ41aEcuNufBb3jHao=; b=mIyUZKVgrPXLbE3U1PgrNkoJFWreFX3V2dGwTHz+4jy/kEAxHBSP0zTGg16oDp7Rtj xZNuFIt5IOpKKYF4Y6BjnbsMRh69gD6NgWPtkg8QwnTrLddA22n9LLYqB2E1Fx/wNJuA bL+EBkcZbLU51FHway0WXHI1xTC+Zr/hdHkaHI5EGfcZe07uF3JNylIOQqr7b05YXhQf /B9vzz28KGoVg3zH5PiElbY0Fa2kE1fqQ957YxNhPQPLsnaCy/NPNoX9iy/wawDlW/kE bDdoBFIOkElEGFqpASzDLx0guPFLt+pyZDcz9bSfw7QD/KOKOsqxXnmu8k7kp9jJEufh eYBQ== X-Forwarded-Encrypted: i=1; AJvYcCUxrDDlq/Amu4Mbru3vCZ2mh1eNCEd4/dacx2ZRLHAUo3JhAwUHYyLfzkTecILqmOoX3VC4Cis81A==@kvack.org X-Gm-Message-State: AOJu0YxQ5/hdSv1WL++ku3nqPdBEhrUiLWUcn6nRBb063p8osQZb6VG7 yrEsmBLIaINr7lHWMpSTp0Y6qtfVWgcRRQApMNZgWyGvirocsb0PB21iP+YXRTKFLBwMOBuKCwH CJ/fI3QINaTETtNluSzA4iE7C5cws9oda/Nt3k89EIH1fPH7I X-Gm-Gg: ASbGncstl6KlLvIh4YGfvnjnyq/IMsRfbt+vVL4HdUBV63SBibc2Y7AbaQYHfS1PpFx PGRH83mYcjIrAcnteVAi+azL0wpVW0dlTmEL2vLhB4NY8mSOa1Sv5boW9YgheGWL0tg1f3ZK/Iw PibCIbMbDhwMPgzdl0h1P17l6GQ660XqVk2g7okkfZeRZIBkdaGi/k5LkFddMSqt7wXzcrksg+A R3F/CNbVRwY35WOcEei3prmFSXQdplLPY00z/SYWccr4gxSaxUu4JuPKqgjMpUr46XOX6E0MLwA pxNnhPvirBZcyHMKe/CWyx0HmV67EA2OGhVJSrOVWLbmNr4+ X-Received: by 2002:ad4:5949:0:b0:6e4:5a38:dd0f with SMTP id 6a1803df08f44-6e6a257b2edmr51384806d6.4.1740058112744; Thu, 20 Feb 2025 05:28:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IH6L/J150VyhZE8qpddA7Ggp+4U/MflpgbPfOEplCKpjVPjN9XqDo0bGw1rmUPzHRESSRb5Dg== X-Received: by 2002:ad4:5949:0:b0:6e4:5a38:dd0f with SMTP id 6a1803df08f44-6e6a257b2edmr51384266d6.4.1740058112355; Thu, 20 Feb 2025 05:28:32 -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 6a1803df08f44-6e6acb6d6b4sm637146d6.121.2025.02.20.05.28.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Feb 2025 05:28:31 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <5b91faa4-f346-4a61-a3a6-e47648af0fb5@redhat.com> Date: Thu, 20 Feb 2025 08:28:30 -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: "Masami Hiramatsu (Google)" , Waiman Long Cc: Steven Rostedt , 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> <9f9150b4-1cf5-4380-b431-419f70775a7d@redhat.com> <20250220115904.051e0cc55a9cb88302582ef4@kernel.org> <20250220182927.258e394c6ba5d76d4c57324b@kernel.org> In-Reply-To: <20250220182927.258e394c6ba5d76d4c57324b@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zz5IQ216si_NVfSMCdcyfAVzuV0mhPHLuTfgk9_NShk_1740058113 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: D3C6A1C0010 X-Rspamd-Server: rspam12 X-Stat-Signature: iza6edchoekkh18pttboh1y8ug53dtbk X-HE-Tag: 1740058114-18124 X-HE-Meta: U2FsdGVkX18y4iA3iB3tfYQyO4+Z9oBDWESBRgE7sb0Esrx69KU7vj+yJ3zDuC6yB4rDD4Z0bdR178G6hEi5a7GGTKQcmLyn5Tfw9qBNjJGfhE9Ld+9k3dtkqtcbP76Mm2l/BugiRYvs+v7jEk8a7trSwJFauKkKpAK+3a2q/OUx4f2aZxLxmpnO1L0ww4pivp8KnKejY0ELo4CBxFGux1WtfytydESaS0yr3rEHq90Ay39DvuW/w7NSjeEIkr7pjv8+VFB+rPppihYP1it/R1dTEsqw6knN68o/gLa0l4nVQYL3ejD0PGp+PQizcw7mxnEu47I+y6h67cBjKZQSeskFkROP01y7wsIdS3WkEDJWHaalFaWYhCYqxweXGME2SNwo4uaL230RdMLzwE/ruzHOX6QhB7fJYTTogX/7iOci2D9+g8wCoM0osUKFlhC8QsoXnX9IcrLwooL/9FMm2GMHuk5VRYoyPGFeHuuRPab/oFNKeE/zU2mm9FTHnFpBpIgstExqaKJZNGEsL5bVMobx1W93ERH8PieTk7XxAkQEN3BB8S20Qvu1fy1P4WDatLHrq/ZfoBMGc2c+DnHc0F0LT1MCzCR0FtAEgZvdheXW9+t0FNdcsnxxDk2b5l1rczdV2s1avzlzqcjw65Z+j9vmbuaq5evUMNW5VaXNxM81a57OjnriyWpPgqOMgnKFPvFaSY6wFpQ0F2ekERXXMRWiTu/Dc7MQZ+m5wFAEZdM9pk+V0ukY3BGOT5pRq82V6l8HR1kvSkAVKmX8wc73TuHb7Knfa8QMDvprysIlO+NCHxu+Uzv+mqwA0JWRWozzn1dA/oaaxf4QM0j+yiTDNLWbqMXaqOMCAtToSWF5uUlnr3yzH5Cav/zYzghJT8dGBfmLTpspgVwFI2iTFqTfHpvacWA5zikouDivvsUJSLqRqEJFxW2kSMhb3IOPa7CmT/JMhLAEzEteSSlAZy0 ufFBYTof AeuFzGkugBT3szZB1iBalCOfxTHc3Rrp1ETbAajteirapeU2OsUD1TJ/QyQHTwBD3L24MQNMWnjdCk4oOttUkaxYbJ5ItdxVSujVxUxGFQsGWJ1CTpHTT5iV99ZKO6IC6MTs5UihzV+yDuEYOJhcJ/IQlUHUu+CqIh8ObjtaNXfLSvYvAwUGIGKSkyqOyiHZo2kXZycpFFpjiXiHyqQFH3+NcmxEAC6qpUwZgWX2VIEHESXzlTXVjWud6cO9Gud9wJwQrWErVupi8ZbOr3AIKeG5oonLTYMv9i+IoA74hDtXM+Y9NKMEQFXoTNdpJl32Rhwu+05HTOqMpefS4/JWxxG/J8tpcpRf7C6bsCNqUL6e/R20urY3exH9ZMuZpg7XorbYlvAn3/aONRQpizodhO/8vRWWzw+HbpDfOYxYos8kjC6N/1rvnvHqf9GaLjoJAvManL6ooF1Ph/KK2FLJJSrh1Usy7JsTThNpK32lPTFlGCGM3DvkuKxbM2T/hBReOp7Q1S6a2NCj9isVhwFmWct2u7tMTawa+LnSiL0LDsF7l0sQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002067, 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/20/25 4:29 AM, Masami Hiramatsu (Google) wrote: > On Wed, 19 Feb 2025 22:37:04 -0500 > Waiman Long wrote: > >> On 2/19/25 9:59 PM, Masami Hiramatsu (Google) wrote: >>> 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. >> That could only happen if the reader can get interrupted/preempted for a >> long time. In that case, we may need to reread the lock again to be sure >> that they are stable. > Hm, actually read side should run under rcu read locked, so only interrupt > matters. So I think this rarely happens. > > BTW, we don't need the lock address itself, but we need to know who is the > owner. Maybe we can point the address of atomic_long_t? > > struct task_struct { > atomic_long_t *blocked_on_owner; > }; Yes, we can use a pointer to the owner field. However, the way that owner field is encoded varies depends on the lock type. So we still need to know what lock it is. As mentioned in the other thread, we can encode the lock type into the lowest 2 bits of the pointer. > > The problem is that mutex and rwsem are OK, but rt_mutex uses task_struct *. > Maybe we can use atomic_long_t in rt_mutex too if the new Kconfig is enabled. It shouldn't be a problem to use atomic_long_t for the owner. Cheers, Longman