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 5B277C021AD for ; Thu, 20 Feb 2025 03:37:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E47E14401C2; Wed, 19 Feb 2025 22:37:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF8994401AE; Wed, 19 Feb 2025 22:37:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C98BA4401C2; Wed, 19 Feb 2025 22:37:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A71ED4401AE for ; Wed, 19 Feb 2025 22:37:14 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 48ECCB234A for ; Thu, 20 Feb 2025 03:37:14 +0000 (UTC) X-FDA: 83138912388.14.27F14B3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id D657DA000A for ; Thu, 20 Feb 2025 03:37:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GynZ3oAH; spf=pass (imf25.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=1740022631; a=rsa-sha256; cv=none; b=3yqSgJCcbiga0JKYE09o9mSHS40120A3pDezBIDEnBw4KZNRPy9fecmhfZuavAIA6+TGBv cADmiRlbLd2TW1cVxsfSM42JNDtVvtMbj7b32tmWvAzxKn5D1pYSXvGDXosFZUmJhHlUMf GnAJY8H+z4qYO9MduhDQQ6w5gM5/Lkw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GynZ3oAH; spf=pass (imf25.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=1740022631; 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=3ow4Bas2JrZurs245FgxS4YuHQc9ZSsOuYeCiBScV/U=; b=r/8F4mPQaPM4rdkM0MMJmC37774oal7IXATRsu2mdy3yqZRrYrZXI6o7/h0bY/OQKSaMKO cqVQ8Ll5mDV0a7di6gJTWJpl6sFCv8xh1y/r7lyD1GETH+GpKK7QtXvs0xrUUl+B2Q9e58 IQ1wR9VX9amuFXYWnXTiweBtnU/aiE0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740022631; 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=3ow4Bas2JrZurs245FgxS4YuHQc9ZSsOuYeCiBScV/U=; b=GynZ3oAHfKfJlO1wXqHS9NSKpiP3um9T4oOA/6Ax0ETe0ZoMq9dUZyiddKzTtkPwBTzLBJ nhOLOsh62KmBn2YYMIE2BF3qRWEUxCMa0/EQ5aQ8Fuuz15ieEoiAJ5BV8X4IKABK2x9whf S6QfPBBL2zV0blfrVy88ZB4X02O7+zk= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-198-4-ZGlXrWM5WmsguvfNEQUQ-1; Wed, 19 Feb 2025 22:37:09 -0500 X-MC-Unique: 4-ZGlXrWM5WmsguvfNEQUQ-1 X-Mimecast-MFC-AGG-ID: 4-ZGlXrWM5WmsguvfNEQUQ_1740022627 Received: by mail-oi1-f200.google.com with SMTP id 5614622812f47-3f3a3c8eb5cso164120b6e.1 for ; Wed, 19 Feb 2025 19:37:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740022627; x=1740627427; 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=3ow4Bas2JrZurs245FgxS4YuHQc9ZSsOuYeCiBScV/U=; b=KWaObnvCgnOEWxr7UR3xDwhTAhz0tztk5eaAI2XMcwj/Qv9jm5BNCgb9yX1NahbFr6 X08PHPUyGO2YgFfTzuDnK0bCineYkug34ysa/dHUI+72eabmUBYqIpuH1YSEKky9pgMb FTkDIwA03qzbf2cMUTCmMQAyNFRrpwZVpJf9CRS2x/6lc+FNNzBJEJA3rFVg3uw3GLc6 fozEXuPAyjBmIxuuszyUiAf6suQjzJwxfruLBvD+jwvqfTnvFmJjHFaz/n20a0w0SGSR wtzOpjnluT4/ia4PvSfC/W6rRfDtmH7yE65v01ysmiM+VeaqzCDtNnpfwkn6UfExHT1s RCAw== X-Forwarded-Encrypted: i=1; AJvYcCWX8Qw+O/N+53yIWosRs3RDcHhP9ZUEYxI5pbWHCdcqMG9/G9ylI0yWKmuVo4WZtrddqP+R6/aW7Q==@kvack.org X-Gm-Message-State: AOJu0YzhaS5hHmJTrDmzuP3ksm02D0YoDsRf6yCDZWKve+u7Iv+aocHC TdqGz6l33b+qGYjLbMBf2/a61a8uaTLucQ7h9SVEeBOlEm17dh3ruS+VDdBBGGQV2q4Dy3FcRNz ne7FREPxQcFQ1ky+WdaZr+gC4r8n0kNS1EfIBqW3oPwpFJvLL X-Gm-Gg: ASbGncuxJcLlm2ORc1c6VJJAVbrSd8wq03m8Fo4KFDwLT38fH1f9nQFXS1sA09MxqDq ehF0P+ylMVM4ocYEcukcDAnJq5OK4F+7qLUmZ887awDme/U4QVuhswz1BTKsLTy+5E5YxPNTi62 Ce2uZRDX5wSoJ7GaDniiPByVMxFU3Q5HTERb9m4x/RSMsiGQ0eV5jGBvvEpSeG42VXQviwe2hz5 kHrwM87FQKKH6RiIa/mjaDY0gu9M+dcfOLlsihWE102mQbmWUcK8KJJ/9qJHLg47OFHzohu0x1t QRkAmSrZtXlOXy3wXuAKuXHUgyKu4IXT4xYtoQYdv/HovEl+ X-Received: by 2002:a05:6808:152b:b0:3f4:11b3:fe10 with SMTP id 5614622812f47-3f411b400c4mr4020775b6e.23.1740022626864; Wed, 19 Feb 2025 19:37:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IGtkqiQcRzaHD+Wga6oKqyRvebB42mVXu8FpnN1eMTxKeDPKC2F/l/pMGLPnwDIv/XvwUbczQ== X-Received: by 2002:a05:6808:152b:b0:3f4:11b3:fe10 with SMTP id 5614622812f47-3f411b400c4mr4020762b6e.23.1740022626471; Wed, 19 Feb 2025 19:37:06 -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 006d021491bc7-5fceba25fe7sm1657333eaf.37.2025.02.19.19.37.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2025 19:37:05 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Wed, 19 Feb 2025 22:37:04 -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> In-Reply-To: <20250220115904.051e0cc55a9cb88302582ef4@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: xSibqM3W17FHPUZH5jnGHyneTJKrbsrmdNiI84roWl0_1740022627 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: nmr9rama9wy7hsahn3fjxkrd46rqirro X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D657DA000A X-Rspam-User: X-HE-Tag: 1740022631-268340 X-HE-Meta: U2FsdGVkX1/LB75kNAgR643DHFKVpa+mRKsiEGPluSzcwmKrhsu4lfX4CPq8t4dxkR/6lZ8tHRg5GGbDaP97t6TBZC9VG20/N9z1NyFve0BOHkEz+u6qTcwHz/TzWrvLOAXzmBrvr27ywpmUXzdhLvx/F7+BrMynNJ650+uEO7IoxzT91jCqW3BFFHWT5yLU2pra5TSzBORuiQshUlpsUGmkgy5nPywStIXHXS+mPYM6BkK4DA5yLhwK7DzfjTOcg4eC7klyXqs78ZOna5e6TkOQTekJ82an7WWY4XC9aCF9Xa7PZ4UUgB938WabmRIjYAVyUwtk1smzyvyWPztE519TUNAdCiBvpW20nE3chQ8hepI8hWr3/blJzOhC1pWonWBQIWxs4JUhUZlW9JoU4VFhXJfC8CWoxV3CvXvw0Mocm+8IkU8D3POz+6FQ8++7znSYDNv/wNF6XflJpSO2qblyiirpTwbzK2Vl7D8d03ysEw/r5wYploQdmQPeDlzJE+E+ogsjkVfnv/Y8+/p3LTv8aayUSYYIFmzXxew3O1862VlwhpMBUyQJR+35kKbIBrDykQ6r/lwvtwsIEeYHQOm9PU2F3+Mu2TfvNyIlktNiKY+zwyEP+HJWA8GnpewrT6BrbB0yatEXQCd+7jjoRKi1fmGAVBDUYaHh5X/25ARdo73760CrJTVHgJpm4gCFNDAOg8Ty4FKA+sfBKxrlrfBtF/ayZlfqLs+iGKrLMccidQRtpw+CyEQXM7NeTtW/lbvY6yF+DmtolLzoDGjA6G+EbNE9IXdhknEe7VFXtT+HKsZX8ZoYLk23XskIKIoCm5/0OKlRkjELnMLoX8Mz+zg55Z0kuxy7DDnv9Lw1jm+cOQC43d/QZH1hFWrUcR4JT3UcQ1L8/sTnUDN5zHFSJNDn70VVIA+iCHmMOdfv/vGSUnT70rDWkuALASludaenLd36WvlawKXg1RBDcl6 FjGwqM4l XbjwZlX1jf2ublQlhboNB2xcysKcKJdxFgkb2CmFptmpg4WEk5hzSMaNPilqT/ogIPTbIg1BYzi0rfQK8Kr/hNsmHLDTjpLUzg3+cTO34XLw61RuO4WsJfgAI6ZGVu2ifJprBeJp3uU0hiaKOsqPqn1OjCiSd7lrScFbANTHgJ3+kfpoIM3Lj7isHbRSPyxZbDBH5RDWswTIUOVVV90PN9g3q92yYYDGc1jLkcdELr9OBzskfdhEBjxbAVbq9JfVN0xFVY9GHrQNzT+qslBtECYAtwaL1LoQ5Nq1U3BS1UP07TynvP9tDLuJSfiWJGyMf/2+6LHKN7gPCeu5fFB826Ac80ccRf4pacvlYt0Sm/p22DIL9BBxR99t3aFDwobyotpgbc6eoF97umdkWFC8T2t4RbjBxpWwUyzuczYfZw1ULsyNJrU8/AYRsX1ecDfL3HRqPdnWnmA8Mr1ru3/5wQbRqgwAT9li5DAVSE5/3zFNS7OBBgv/C/Xh++53hq3pc3m2mm/r2664AUGqLRWkwehxcjWb5NXCVeSDG9a/5gPj7bsM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000125, 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 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. Cheers, Longman > > Maybe we can run the hung_task in stop_machine()? > (or introduce common_lock) > > Thank you, >