Re: [PATCH V3 5/6] tools/perf: Add powerpc HTM auxtrace event processing support

Athira Rajeev <[email protected]>
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-perf-users
Message-ID <[email protected]>

> On 25 Jul 2026, at 12:51 PM, [email protected] wrote:
> 
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The file `powerpc-htm.c` calls `zalloc()` but fails to include `<linux/zalloc.h>`, resulting in an implicit function declaration.
> - [Low] The file `powerpc-htm.c` embeds `struct auxtrace_queues` and calls its API but fails to directly include `"auxtrace.h"`, relying on brittle implicit inclusion.
> --
> 
> --- Patch [5]: [PATCH V3 5/6] tools/perf: Add powerpc HTM auxtrace event processing support ---
> commit 306ea78646ef6e5fe95dbad9977aff1241d1027a
> Author: Athira Rajeev <[email protected]>
> 
> tools/perf: Add powerpc HTM auxtrace event processing support
> 
> This commit adds the powerpc-htm.c decode stub for powerpc HTM auxtrace.
> It wires the dispatch in perf_event__process_auxtrace_info() to call
> powerpc_htm_process_auxtrace_info().
> 
>> diff --git a/tools/perf/util/powerpc-htm.c b/tools/perf/util/powerpc-htm.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/tools/perf/util/powerpc-htm.c
>> @@ -0,0 +1,116 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <inttypes.h>
>> +#include <fcntl.h>
>> +#include <unistd.h>
>> +#include <string.h>
>> +#include <errno.h>
>> +#include <endian.h>
>> +#include "util/evsel.h"
>> +#include "util/evlist.h"
>> +#include "util/session.h"
>> +#include "color.h"
>> +#include "powerpc-htm.h"
>> +#include "debug.h"
>> +#include "sample.h"
>> +
>> +struct powerpc_htm {
>> + struct auxtrace auxtrace;
>> + struct auxtrace_queues queues;
> 
> [Severity: Low]
> Should this file explicitly include "auxtrace.h"?
> 
> The code embeds struct auxtrace_queues here, and later calls
> auxtrace_queues__init(), both of which are defined in "auxtrace.h". Relying
> on implicit inclusion (for example, through "util/evlist.h") currently works
> but could break the build if intermediate headers are refactored in the
> future.
> 
> [ ... ]
> 
>> +int powerpc_htm_process_auxtrace_info(union perf_event *event,
>> +      struct perf_session *session)
>> +{
>> + struct perf_record_auxtrace_info *auxtrace_info = &event->auxtrace_info;
>> + struct powerpc_htm *htm;
>> + int err;
>> +
>> + if (auxtrace_info->header.size < sizeof(struct perf_record_auxtrace_info) +
>> + HTM_AUXTRACE_PRIV_FIXED)
>> + return -EINVAL;
>> +
>> + htm = zalloc(sizeof(struct powerpc_htm));
> 
> [Severity: High]
> Does this implicit function declaration cause a build failure or pointer
> truncation?
> 
> The function zalloc() is used here, but <linux/zalloc.h> is not included in
> this file. Because the kernel build system uses -Werror, this missing header
> could trigger a build failure.
> 
> If -Werror were disabled, the compiler would assume zalloc() returns a 32-bit
> integer. On 64-bit architectures like PowerPC, this truncates the 64-bit
> pointer. When extended back to 64 bits during assignment, the higher bits are
> lost, which could result in a segmentation fault upon dereference.
> 
> Should <linux/zalloc.h> be included to ensure the return type is properly
> defined?

Sure, V4 will have changes to add zalloc.h and auxtrace.h

Thanks
Athira
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.