All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alireza Haghdoost" <haghdoost@uber.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 1/4] perf symbols: Fix broken ELF_C_READ_MMAP fallback guard
Date: Tue, 15 Sep 2026 18:53:16 +0000	[thread overview]
Message-ID: <20260915185318.0573C1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260915-perf-symbol-memory-send-v1-1-1d3360e21f07@uber.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] perf: build failure on systems lacking ELF_C_READ_MMAP enum
--

commit d38dd3de1c465f53af2cb4e7df04744c926b7ed6
Author: Alireza Haghdoost <haghdoost@uber.com>

perf symbols: Fix broken ELF_C_READ_MMAP fallback guard

This patch attempts to make perf mmap ELF files by unconditionally defining
PERF_ELF_C_READ_MMAP to ELF_C_READ_MMAP. It removes the previous guard
because ELF_C_READ_MMAP is an enum rather than a preprocessor macro.

> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -57,15 +57,8 @@ static inline bool is_livepatch_symbol(const char *str)
>  	return strstarts(str, KLP_SYM_PREFIX);
>  }
>  
> -/*
> - * libelf 0.8.x and earlier do not support ELF_C_READ_MMAP;
> - * for newer versions we can use mmap to reduce memory usage:
> - */
> -#ifdef ELF_C_READ_MMAP
> -# define PERF_ELF_C_READ_MMAP ELF_C_READ_MMAP
> -#else
> -# define PERF_ELF_C_READ_MMAP ELF_C_READ
> -#endif
> +/* libelf falls back to internal reads when mmap fails (e.g. non-seekable fd). */
> +#define PERF_ELF_C_READ_MMAP ELF_C_READ_MMAP

[Severity: Low]
Will this cause compilation errors on systems where the libelf.h header lacks
the ELF_C_READ_MMAP enum?

By unconditionally assigning PERF_ELF_C_READ_MMAP to ELF_C_READ_MMAP in
tools/perf/util/symbol.h, this bypasses build feature detection. On systems
with libelf implementations that do not provide ELF_C_READ_MMAP, such as
elftoolchain on FreeBSD and macOS, this triggers an undeclared identifier
compilation error.

The commit message notes that objtool uses an #ifndef guard which works fine,
but since ELF_C_READ_MMAP is an enum in libelf, that #ifndef in objtool
silently evaluates to true and incorrectly downgrades all mmap reads to
standard reads instead of actually using mmap.

Could we restore a proper feature detection mechanism here rather than
relying on an unconditional definition?

>  
>  #ifdef HAVE_LIBELF_SUPPORT
>  Elf_Scn *elf_section_by_name(Elf *elf, GElf_Ehdr *ep,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-perf-symbol-memory-send-v1-0-1d3360e21f07@uber.com?part=1

  reply	other threads:[~2026-09-15 18:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 18:42 [PATCH 0/4] perf script: Bounded and lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-15 18:42 ` [PATCH 1/4] perf symbols: Fix broken ELF_C_READ_MMAP fallback guard Alireza Haghdoost via B4 Relay
2026-09-15 18:53   ` sashiko-bot [this message]
2026-09-15 19:04     ` Alireza Haghdoost
2026-09-17  0:30       ` Namhyung Kim
2026-09-15 18:42 ` [PATCH 2/4] perf script: Add --max-symbol-bytes to bound ELF symbol memory Alireza Haghdoost via B4 Relay
2026-09-15 19:01   ` sashiko-bot
2026-09-16 16:15     ` Alireza Haghdoost
2026-09-17  6:53   ` Namhyung Kim
2026-09-19 18:37     ` Alireza Haghdoost
2026-09-15 18:42 ` [PATCH 3/4] perf script: Add --lazy-load-symbols for lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-15 18:54   ` sashiko-bot
2026-09-16 16:18     ` Alireza Haghdoost
2026-09-17  7:24   ` Namhyung Kim
2026-09-19 23:22     ` Alireza Haghdoost
2026-09-15 18:42 ` [PATCH 4/4] perf script: Document and test --lazy-load-symbols and --max-symbol-bytes Alireza Haghdoost via B4 Relay
2026-09-15 18:50   ` sashiko-bot
2026-09-16 16:21     ` Alireza Haghdoost

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=20260915185318.0573C1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=haghdoost@uber.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.