On Sun, 24 Aug 2025, Lance Yang wrote:
The blocker tracking mechanism operates on pointers to higher-level locks (like struct mutex), as that is what is stored in the task_struct->blocker field. It does not operate on the lower-level arch_spinlock_t inside it.
Perhaps you are aware that the minimum alignment of the struct is at least the minimum alignment of the first member. I believe that the reason why the lock is always the first member is that misaligned accesses would harm performance.
I really don't know why you want to argue about fixing this.
While we could track the internal arch_spinlock_t, that would break encapsulation.
Would it.
The hung task detector should remain generic and not depend on lock-specific implementation details ;)
OK, like a new class derived from bitfield and pointer? Is that what you mean by "generic" and "encapsulated"?