From: Wang Yaxin <wang.yaxin@zte.com.cn>

- Convert per-field delay members in struct task_info to an array indexed
  by enum delay_type, eliminating offsetof() pointer arithmetic.

- Add __kernel_old_time_t typedef to tools/include/uapi/linux/time_types.h
  per Thomas's suggestion for backward compatibility with pre-v5.5
  UAPI headers.

- Factor out a common format_timespec() implementation shared by getdelays
  and delaytop, using strftime for cleaner timestamp formatting.

- Replace the complex sizeof/ULL/shift Y2038 guard with a direct narrowing
  truncation check ((long long)time_sec != ts->tv_sec).

Change Log
==========
v4->v5:
https://lore.kernel.org/all/20260824081329-eb7ca513-7418-4895-9fdb-dfe53fb3a0e6@linutronix.de/
As suggested by Thomas, add "typedef __kernel_long_t __kernel_old_time_t;"
to tools/include/uapi/linux/time_types.h to provide backward compatibility
with pre-v5.5 UAPI headers.

v3->v4:
update patch 2/3 and 3/3 according to the suggestion:
https://sashiko.dev/#/patchset/20260718133420538UvsJFurowueTqxAaZ1cRP@zte.com.cn

1. add #ifndef __kernel_old_timeval guard to
tools/include/uapi/linux/time_types.h to match the kernel header and avoid
redefinition on sparc64.
2. update commit message to document the nla_len < NLA_HDRLEN sanity checks
added to netlink attribute parsing in getdelays.c and delaytop.c.


v2->v3:
update patch 2/3 and 3/3 according to the suggestion:
https://sashiko.dev/#/patchset/20260715124740929HC7tDDb2SK3kRxbuPruHd@zte.com.cn

1. tools/include/uapi/linux/time_types.h: use __kernel_long_t instead of
long to fix ABI mismatch on x32
2. tools/accounting: add nla_len < NLA_HDRLEN checks in netlink attribute
parsing loops to prevent infinite loop on malformed messages

v1->v2:
Only update patch 2/3 according to the suggestion:
https://sashiko.dev/#/patchset/20260711173112482SCQEM08VED2PT1pxUYOXk@zte.com.cn

1. tools/include/uapi/linux/time_types.h: expand stub to full set of
  6 structs from kernel UAPI to avoid shadowing system header
2. tools/accounting/Makefile: add $(LDFLAGS), $(LDLIBS), $(CPPFLAGS)
  to restore compatibility with standard build variables

Wang Yaxin (4):
  delaytop: refactor repetitive delay fields into array with enum
  tools/include/uapi: Add time_types.h with direct type definitions
  tools/accounting: factor out shared format_timespec() implementation
  tools/accounting: simplify 32-bit time_t overflow check in
    format_timespec()


 tools/accounting/Makefile             |  12 +-
 tools/accounting/delaytop.c           | 265 ++++++++++----------------
 tools/accounting/format_timespec.c    |  37 ++++
 tools/accounting/format_timespec.h    |   9 +
 tools/accounting/getdelays.c          |  36 +---
 tools/include/uapi/linux/time_types.h |  76 ++++++++
 6 files changed, 235 insertions(+), 200 deletions(-)
 create mode 100644 tools/accounting/format_timespec.c
 create mode 100644 tools/accounting/format_timespec.h
 create mode 100644 tools/include/uapi/linux/time_types.h

-- 
2.25.1

On Sat, 29 Aug 2026 17:12:38 +0800 (CST) <wang.yaxin@zte.com.cn> wrote:

> - Convert per-field delay members in struct task_info to an array indexed
>   by enum delay_type, eliminating offsetof() pointer arithmetic.
> 
> - Add __kernel_old_time_t typedef to tools/include/uapi/linux/time_types.h
>   per Thomas's suggestion for backward compatibility with pre-v5.5
>   UAPI headers.
> 
> - Factor out a common format_timespec() implementation shared by getdelays
>   and delaytop, using strftime for cleaner timestamp formatting.
> 
> - Replace the complex sizeof/ULL/shift Y2038 guard with a direct narrowing
>   truncation check ((long long)time_sec != ts->tv_sec).

Thanks.  I can't figure out how to apply this, and neither can Sashiko:
	https://sashiko.dev/#/patchset/20260829171238191s9SIXoZPTlZSmA2Px30hn@zte.com.cn

Seems there's a dependency on your "delaytop: add delay max, timestamp
and sorting for top latency analysis" series which didn't get applied
for reasons which I don't recall.

>> - Convert per-field delay members in struct task_info to an array indexed
>>   by enum delay_type, eliminating offsetof() pointer arithmetic.
>> 
>> - Add __kernel_old_time_t typedef to tools/include/uapi/linux/time_types.h
>>   per Thomas's suggestion for backward compatibility with pre-v5.5
>>   UAPI headers.
>> 
>> - Factor out a common format_timespec() implementation shared by getdelays
>>   and delaytop, using strftime for cleaner timestamp formatting.
>> 
>> - Replace the complex sizeof/ULL/shift Y2038 guard with a direct narrowing
>>   truncation check ((long long)time_sec != ts->tv_sec).
>
>Thanks.  I can't figure out how to apply this, and neither can Sashiko:
>	https://sashiko.dev/#/patchset/20260829171238191s9SIXoZPTlZSmA2Px30hn@zte.com.cn
>
>Seems there's a dependency on your "delaytop: add delay max, timestamp
>and sorting for top latency analysis" series which didn't get applied
>for reasons which I don't recall.

Hi Andrew,

Thanks for your reply!

You're right — this patch is part of a larger refactoring effort for
delaytop, so it does depend on the precursor series "delaytop: add
delay max, timestamp and sorting for top latency analysis".

I have read the discussion at the link below to figure out why the
precursor patch was reverted:
https://lore.kernel.org/all/20260804031240.D97F81F00A3E@smtp.kernel.org/

From that thread, I understand that commit [1] ("delaytop: fix a bunch
of docs build problems") was reverted due to issues it introduced.
Consequently, this patch [2] ("delaytop: sort by max delay to highlight
top latency processes") was also reverted because it depended on the
documentation changes from [1].

If I resubmit patch [2] as-is, running make htmldocs will again
produce warnings in Documentation/accounting/delay-accounting.rst.
Those warnings (e.g., indentation and formatting issues in the rst
table) were originally fixed by [1], but since [1] is gone, they would
reappear.

My proposed solution is to update the next version of patch [2] to
include the necessary rst formatting fixes directly in that same patch.
This way, patch [2] no longer depends on [1] and can be applied
independently. The documentation fix would be part of this patch
rather than a separate precursor.

Thanks
Yaxin