From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE7123783AF for ; Thu, 30 Jul 2026 02:50:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785379836; cv=none; b=qcuZNVDNCIu3OwQ4KIa7P2AF/DB0QtsaBrgVaXWqgPCFLUZw/IStqoLj6mDIz2gXpCITI1vKbuV2H29ZGBu1138I0Q4ON+X+lVHZp+bS3g0NdReVvIBBrqsXTPVv26Y6oeT0+NMf/AsaYio9TWxUk/wq751Gtw1Ufvtf/7HVStY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785379836; c=relaxed/simple; bh=9J9OFdXdPOzqRg46v9c6LLx/wmCHcO1mBidBFDn7LOA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=F6J/FQxYko4tvo5G9SkyroMsmDgnCBUDsukw0JpL6ChZuYIvLAmXKEkV1bacj6T/yDXv+qoVdAeXc7/CK8a2kRhpLcVmgFn3YjOhK0GPudImy6/OUaoORsznBpuZr4uAhsge0Z7ZctcgeXzrqQwqJF8QqWa4AqzrAZbu4OscCNk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=M4q5kHh8; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M4q5kHh8" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-495757ccbc1so14182265e9.2 for ; Wed, 29 Jul 2026 19:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785379833; x=1785984633; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Y0Z2dn9fAv9gkJzeyjQZG7zv4uXVocGs2xKCzgJLZsk=; b=M4q5kHh8gk5HA+HMQ4hI/f4IJLjRti19vSWnmMDxDb+3TxpQNkReA8/gA/bK1d3gfR eVMF2oJqD+SO1eY1BRFq+CX8XmnrZylItv2Q81iNO0xooCccsoPjAEHFE748l6Z25WRA 1Hjku3QQOitDz2L/tTR5ZbtMcfbhfOemeOM+MuFU3Z8YB8gdI4Nrn7E3swKUIbsS8eA+ KSdssysxVYRUHqS25l7TDacmPKe6H7AOETcZ9hcYRhrJb1Xnpl1oZQiHmDuMO3u2Rzrp CqG/HWG7IE0BQjHTqmnxjZJnX86g5k149yeCdcAFh1Q8e0OGDqHQCqv2dZyZcUFnhsCX UFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785379833; x=1785984633; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Y0Z2dn9fAv9gkJzeyjQZG7zv4uXVocGs2xKCzgJLZsk=; b=i9sokvXHDuwMUdFhA4UPezb11o08YE+gJYhTuc1zAvLCCeN0oB+fHf6oRysG9jTG6c u7So4zmy2TVf1KZy5+11ctM1rCHGAN0czKDpAisG9aCDo7bohyyrCfcrG1CmNNARk2hp ugUrguEUBGG+Vc0PUIOgK05A1QwpqN6Qo8q8nf5ACwYGGbCoZYeV3ijKc65c6IZh5ITf q0zwCRc95J6n/Fbu3KHYjyIiKX6qZyewlJe6BzdrpleSjtV89cL8+CYm144R5/iHQ2dI g38pKyUSsgkJQdPe8epBTOYw9iz4gIIQiuLxSPH70siOSq7EsxQX95I3m/CC/YW3o4dh Jpgg== X-Forwarded-Encrypted: i=1; AHgh+Rqt/Px77/qWPb1TDULRL//n03yxDkKGCedJZISxV0Dg1CsiiTVAO/FWnCc2QqXVJnJo5NlFE7/8nGlGe/A=@vger.kernel.org X-Gm-Message-State: AOJu0Yxz7hJHvj3bNctNMWFerel09O+WRM3rWYHpnZxgk83ig5rBNlkx iD5kp6Ia5TkGXTdvLRTWHaNKK57xBNJaCXvacePF+2OU0hPRwft6PHG2 X-Gm-Gg: AR+sD104veawkz2pigwmCwKC3BsDNWdbnxS6AyIhH+lWCF1hDiqFpBrO4yCmsUtJtyO r80CudPXkz3V31wvJ1YlFhn6uTDbnAfuRgS6xksELPyvmU4Q2zvzKxjGP+a/3mRtbUnhP0QgeTE rQhyeEiqsahOMFI8ivujJ0wYxapMlwXFGotjJZlo9SJhKVwlmrxGDEvA9y1Yv6uhJzMI2F5Ni9V 2bLKdJg9yPBTcYDUa3s5bWnWQWUN3KKUXP1Pksw1kCeTzHu5Hi00ohQjdmv0K9ABPRueSTGNFr8 Jq1t3+FtYLKSuFqwPA6fQJt9CGiKvDq4kv/1ejq3MQJtiZtEvA6mrwO9DbxFfTsY4LFdc0dzVGf Y9yZvfpfuLugT5XSVcL/L9nKwUKMFU2k3uenZFsc/hXSQfiehITEAL45Ax2YUuGuuu4JCUN+LM7 xE0S/hdekZCPnVRDXJ5PhuL+2vrhiJSjvJOrd56SOEfbwG1IXhu/350x4cuGJ0XFht6FwzRGu9 X-Received: by 2002:a05:600c:4ece:b0:496:c379:b2a1 with SMTP id 5b1f17b1804b1-49800e6d4d9mr8223365e9.2.1785379833057; Wed, 29 Jul 2026 19:50:33 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49801215764sm18030335e9.14.2026.07.29.19.50.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 19:50:31 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: ruipengqi3@gmail.com, akpm@linux-foundation.org, peterz@infradead.org, bigeasy@linutronix.de Cc: lance.yang@linux.dev, mhiramat@kernel.org, pmladek@suse.com, mingo@redhat.com, will@kernel.org, boqun@kernel.org, longman@redhat.com, clrkwllms@kernel.org, rostedt@goodmis.org, zhouyuhang@kylinos.cn, arnd@arndb.de, colin.i.king@gmail.com, ebiggers@kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Zhan Xusheng Subject: Re: [PATCH 1/2] hung_task: show the blocker task if the task is hung on rtmutex Date: Thu, 30 Jul 2026 10:50:18 +0800 Message-ID: <20260730024448.418327-1-zhanxusheng1024@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <4dd13bdf76de6ce1e4d825af9f393a5dd59f25e8.1785376929.git.ruipengqi3@gmail.com> References: <4dd13bdf76de6ce1e4d825af9f393a5dd59f25e8.1785376929.git.ruipengqi3@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Zhan Xusheng =0D Hi Ruipeng,=0D =0D Nice extension. I traced the set/clear pairing and it looks sound: the=0D blocker is set/cleared alongside every task->pi_blocked_on assignment (all= =0D three pi_blocked_on =3D NULL sites clear it), so there is no stale blocker= =0D left behind. Gating the mutex/rwsem cases in debug_show_blocker() under=0D !CONFIG_PREEMPT_RT also matches that their setters (and mutex_get_owner()/= =0D rwsem_owner()) only exist on !RT, while BLOCKER_TYPE_SEM is correctly kept= =0D since semaphores stay counting on RT. A few comments:=0D =0D > +extern void debug_trace_blocker(struct task_struct *task,=0D > + unsigned long timeout, bool iter);=0D [...]=0D > +static inline void debug_trace_blocker(struct task_struct *task,=0D > + unsigned long timeout, bool iter)=0D > +{=0D > +}=0D =0D debug_trace_blocker() seems to be only declared (and stubbed) here - I=0D can't find any definition or caller in the series or in-tree. Is it a=0D leftover from a larger WIP that should be dropped?=0D =0D > +#ifdef CONFIG_64BIT=0D > +#define BLOCKER_TYPE_RTMUTEX 0x04UL=0D > +#define BLOCKER_TYPE_MASK 0x07UL=0D > +#else=0D > #define BLOCKER_TYPE_MASK 0x03UL=0D > +#endif=0D =0D Since the 3rd bit is only available on 64-bit, rtmutex blocker tracking is= =0D effectively 64-bit only (on 32-bit the two low bits are already taken by=0D mutex/sem/rwsem-r/w). Could the changelog state that explicitly? Also,=0D on PREEMPT_RT spinlock_t/rwlock_t/mutex/rwsem are all rtmutex-based, so=0D this effectively reports every rtmutex-based sleeping-lock wait, not only=0D rt_mutex_lock() - a word about that would keep the "blocked on a rtmutex"=0D line from being surprising for what was a mutex/spinlock at the source=0D level.=0D =0D > +#if defined(CONFIG_64BIT)=0D > + hung_task_set_blocker(task, lock, BLOCKER_TYPE_RTMUTEX);=0D > +#endif=0D =0D (and the three matching clear sites)=0D =0D Would it be cleaner to hide the CONFIG_64BIT-ness inside the hung_task=0D helpers - e.g. a no-op rtmutex set/clear on 32-bit - so rtmutex.c doesn't=0D need the scattered #if at each call site?=0D =0D Thanks,=0D Zhan Xusheng=0D