From: Zhan Xusheng <zhanxusheng1024@gmail.com>
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 <zhanxusheng1024@gmail.com>
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 [thread overview]
Message-ID: <20260730024448.418327-1-zhanxusheng1024@gmail.com> (raw)
In-Reply-To: <4dd13bdf76de6ce1e4d825af9f393a5dd59f25e8.1785376929.git.ruipengqi3@gmail.com>
From: Zhan Xusheng <zhanxusheng1024@gmail.com>
Hi Ruipeng,
Nice extension. I traced the set/clear pairing and it looks sound: the
blocker is set/cleared alongside every task->pi_blocked_on assignment (all
three pi_blocked_on = NULL sites clear it), so there is no stale blocker
left behind. Gating the mutex/rwsem cases in debug_show_blocker() under
!CONFIG_PREEMPT_RT also matches that their setters (and mutex_get_owner()/
rwsem_owner()) only exist on !RT, while BLOCKER_TYPE_SEM is correctly kept
since semaphores stay counting on RT. A few comments:
> +extern void debug_trace_blocker(struct task_struct *task,
> + unsigned long timeout, bool iter);
[...]
> +static inline void debug_trace_blocker(struct task_struct *task,
> + unsigned long timeout, bool iter)
> +{
> +}
debug_trace_blocker() seems to be only declared (and stubbed) here - I
can't find any definition or caller in the series or in-tree. Is it a
leftover from a larger WIP that should be dropped?
> +#ifdef CONFIG_64BIT
> +#define BLOCKER_TYPE_RTMUTEX 0x04UL
> +#define BLOCKER_TYPE_MASK 0x07UL
> +#else
> #define BLOCKER_TYPE_MASK 0x03UL
> +#endif
Since the 3rd bit is only available on 64-bit, rtmutex blocker tracking is
effectively 64-bit only (on 32-bit the two low bits are already taken by
mutex/sem/rwsem-r/w). Could the changelog state that explicitly? Also,
on PREEMPT_RT spinlock_t/rwlock_t/mutex/rwsem are all rtmutex-based, so
this effectively reports every rtmutex-based sleeping-lock wait, not only
rt_mutex_lock() - a word about that would keep the "blocked on a rtmutex"
line from being surprising for what was a mutex/spinlock at the source
level.
> +#if defined(CONFIG_64BIT)
> + hung_task_set_blocker(task, lock, BLOCKER_TYPE_RTMUTEX);
> +#endif
(and the three matching clear sites)
Would it be cleaner to hide the CONFIG_64BIT-ness inside the hung_task
helpers - e.g. a no-op rtmutex set/clear on 32-bit - so rtmutex.c doesn't
need the scattered #if at each call site?
Thanks,
Zhan Xusheng
parent reply other threads:[~2026-07-30 2:50 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <4dd13bdf76de6ce1e4d825af9f393a5dd59f25e8.1785376929.git.ruipengqi3@gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260730024448.418327-1-zhanxusheng1024@gmail.com \
--to=zhanxusheng1024@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=boqun@kernel.org \
--cc=clrkwllms@kernel.org \
--cc=colin.i.king@gmail.com \
--cc=ebiggers@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=ruipengqi3@gmail.com \
--cc=will@kernel.org \
--cc=zhouyuhang@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®