From nobody Tue Apr 7 18:46:40 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1D573D524F for ; Mon, 9 Mar 2026 14:41:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773067263; cv=none; b=G+CAZu0UX+d0uHJdp+3pNDku3WViqGmVBgafgmUKfb5CXwy+lIih0Dx02/FlwSg3WrEsXu2WCb9W+Aq92HGsvKRteekuSmjg944NvGff4qxsD03u2Q9nDtVNsfUFHE6FikLjPQRW2kvLcifwIUd+tSdMxRRHEixK7r8IHSDXrbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773067263; c=relaxed/simple; bh=Vk6d1nLIStrFdGjHMzL2AvymUUgSuSw5umFLRznMPng=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HeqJK1pBOwepRFbGE3g5U0jcPHlPmtMfeIxzBU8E1KCAHqRR8fmVpKbObbF+8pc2eNsqtmbt7wpVkIKPijSCMcrX6ThwU4RMVS+2BFZVs/ymWepdf6i6dz9jWELvcFIK101FlQCpyZniMBLHNz5T7IoE8Mo/R6yx0H3MSKd11io= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=NyaGU3mv; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NyaGU3mv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773067260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=WMybaLJ1g6OpaWYjNvsRlqGDthhuaVaSCXgy/H4L5M8=; b=NyaGU3mvdW1LbbPZtdmfoVP9aBFuTg0nUt1lrxnIf7i0yV61yODLzQg3yE0AS34zeur+sw u2fpTjmaoeQYiLfueht1DFDNR9uer2ufzaYX9N72JErzW894MophJJMkWsU8cbU6hXd7W7 lAjO1K+Ayxky/9833us7C/AbJw6kLiw= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-554-V_CeawzUPCSsTTzOUpp3KA-1; Mon, 09 Mar 2026 10:40:57 -0400 X-MC-Unique: V_CeawzUPCSsTTzOUpp3KA-1 X-Mimecast-MFC-AGG-ID: V_CeawzUPCSsTTzOUpp3KA_1773067256 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 919BE18002C9; Mon, 9 Mar 2026 14:40:55 +0000 (UTC) Received: from vmalik-fedora.redhat.com (unknown [10.45.225.182]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C36D0180035F; Mon, 9 Mar 2026 14:40:50 +0000 (UTC) From: Viktor Malik To: linuxppc-dev@lists.ozlabs.org Cc: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Viktor Malik , Benjamin Herrenschmidt , Paul Mackerras , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Saket Kumar Bhaskar Subject: [PATCH v2] powerpc, perf: Check that current->mm is alive before getting user callchain Date: Mon, 9 Mar 2026 15:40:45 +0100 Message-ID: <20260309144045.169427-1-vmalik@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Content-Type: text/plain; charset="utf-8" It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools): [26215.051935] Kernel attempted to read user page (588) - exploit attem= pt? (uid: 0) [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x000005= 88 [26215.051952] Faulting instruction address: 0xc00000000020fac0 [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1] [...] [26215.052049] Call Trace: [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_use= r_64+0x2d0/0x490 (unreliable) [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_use= r+0x1c/0x30 [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain= +0x100/0x360 [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x= 88/0xf0 [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab= 662f669_do_perf_event+0xf8/0x274 [...] In addition, move storing the top-level stack entry to generic perf_callchain_user to make sure the top-evel entry is always captured, even if current->mm is NULL. Fixes: 20002ded4d93 ("perf_counter: powerpc: Add callchain support") Signed-off-by: Viktor Malik Reviewed-by: Saket Kumar Bhaskar Tested-by: Qiao Zhao Tested-by: Venkat Rao Bagalkote --- Changes in v2: - Move call to perf_callchain_store() for the top-level stack entry to common perf_callchain_user (Saket) arch/powerpc/perf/callchain.c | 5 +++++ arch/powerpc/perf/callchain_32.c | 1 - arch/powerpc/perf/callchain_64.c | 1 - 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c index 26aa26482c9a..992cc5c98214 100644 --- a/arch/powerpc/perf/callchain.c +++ b/arch/powerpc/perf/callchain.c @@ -103,6 +103,11 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx = *entry, struct pt_regs *re void perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs= *regs) { + perf_callchain_store(entry, perf_arch_instruction_pointer(regs)); + + if (!current->mm) + return; + if (!is_32bit_task()) perf_callchain_user_64(entry, regs); else diff --git a/arch/powerpc/perf/callchain_32.c b/arch/powerpc/perf/callchain= _32.c index ddcc2d8aa64a..0de21c5d272c 100644 --- a/arch/powerpc/perf/callchain_32.c +++ b/arch/powerpc/perf/callchain_32.c @@ -142,7 +142,6 @@ void perf_callchain_user_32(struct perf_callchain_entry= _ctx *entry, next_ip =3D perf_arch_instruction_pointer(regs); lr =3D regs->link; sp =3D regs->gpr[1]; - perf_callchain_store(entry, next_ip); =20 while (entry->nr < entry->max_stack) { fp =3D (unsigned int __user *) (unsigned long) sp; diff --git a/arch/powerpc/perf/callchain_64.c b/arch/powerpc/perf/callchain= _64.c index 115d1c105e8a..30fb61c5f0cb 100644 --- a/arch/powerpc/perf/callchain_64.c +++ b/arch/powerpc/perf/callchain_64.c @@ -77,7 +77,6 @@ void perf_callchain_user_64(struct perf_callchain_entry_c= tx *entry, next_ip =3D perf_arch_instruction_pointer(regs); lr =3D regs->link; sp =3D regs->gpr[1]; - perf_callchain_store(entry, next_ip); =20 while (entry->nr < entry->max_stack) { fp =3D (unsigned long __user *) sp; --=20 2.53.0