All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gu Bin" <gubin@cmss.chinamobile.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf machine: Fix NULL deref in machine__is_lock_function()
Date: Thu, 05 Nov 2026 06:59:56 +0000	[thread overview]
Message-ID: <sashiko-outbox-198642@kernel.org> (raw)
In-Reply-To: <20261105064958.2134-1-gubin@cmss.chinamobile.com>

> machine__is_lock_function() looks up __sched_text_start and, if found,
> assumes the remaining scheduler/lock text symbols are present too: it
> dereferences sym->start for __sched_text_end, __lock_text_start and
> __lock_text_end without a NULL check, under a "should not fail from
> here" comment.
> 
> That assumption has already been broken in practice: on s390,
> __sched_text_end shared its address with __cpuidle_text_start and
> was dropped by symbols__fixup_duplicate(), causing a SIGSEGV in
> "perf lock contention".
> commit d8d85ce86dc8 ("perf lock contention: Fix core dump related to
> not finding the "__sched_text_end" symbol on s/390") worked around
> that particular case by keeping duplicate symbols via
> symbol_conf.allow_aliases. The symbols can also be absent when the
> kernel image has no lock text, or when the symbol table is otherwise
> incomplete.
> 
> NULL-check each of the four lookups and share the existing failure
> handling through a fail label that records the "failed to get kernel
> symbols" state (machine->sched.text_start = 1), so the initialization
> is only cached as complete when every lookup succeeded and later calls
> bail out early without retrying the symbol lookups.
> 
> Fixes: 0d2997f750d1 ("perf lock: Look up callchain for the contended locks")
> Signed-off-by: Gu Bin <gubin@cmss.chinamobile.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105064958.2134-1-gubin@cmss.chinamobile.com?part=1


  reply	other threads:[~2026-11-05  6:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  6:49 [PATCH] perf machine: Fix NULL deref in machine__is_lock_function() Gu Bin
2026-11-05  6:59 ` sashiko-bot [this message]
2026-11-10  2:52 ` Namhyung Kim

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=sashiko-outbox-198642@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gubin@cmss.chinamobile.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.