All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: lirongqing <lirongqing@baidu.com>
Cc: olsajiri@gmail.com, peterz@infradead.org, mingo@redhat.com,
	acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com,
	alexander.shishkin@linux.intel.com, irogers@google.com,
	adrian.hunter@intel.com, kan.liang@linux.intel.com,
	tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][next] perf/x86/intel/bts: check if bts_ctx is allocated when call bts functions
Date: Thu, 6 Mar 2025 14:08:38 +0100	[thread overview]
Message-ID: <Z8meVrqd-F7tf44j@krava> (raw)
In-Reply-To: <20250306051102.2642-1-lirongqing@baidu.com>

On Thu, Mar 06, 2025 at 01:11:02PM +0800, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
> 
> bts_ctx maybe not allocated, for example if the cpu has X86_FEATURE_PTI,
> but intel_bts_disable/enable_local and intel_bts_interrupt are called
> unconditionally from intel_pmu_handle_irq and exploding on accessing
> bts_ctx
> 
> so check if bts_ctx is allocated when call bts functions
> 
> Fixes: 3acfcefa795c "(perf/x86/intel/bts: Allocate bts_ctx only if necessary)"
> Reported-by: Jiri Olsa <olsajiri@gmail.com>

Tested-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka


> Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
> Suggested-by: Dave Hansen <dave.hansen@intel.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
>  arch/x86/events/intel/bts.c | 25 ++++++++++++++++++++-----
>  1 file changed, 20 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
> index 8e09319..e8b3e7b 100644
> --- a/arch/x86/events/intel/bts.c
> +++ b/arch/x86/events/intel/bts.c
> @@ -338,9 +338,14 @@ static void bts_event_stop(struct perf_event *event, int flags)
>  
>  void intel_bts_enable_local(void)
>  {
> -	struct bts_ctx *bts = this_cpu_ptr(bts_ctx);
> -	int state = READ_ONCE(bts->state);
> +	struct bts_ctx *bts;
> +	int state;
>  
> +	if (!bts_ctx)
> +		return;
> +
> +	bts = this_cpu_ptr(bts_ctx);
> +	state = READ_ONCE(bts->state);
>  	/*
>  	 * Here we transition from INACTIVE to ACTIVE;
>  	 * if we instead are STOPPED from the interrupt handler,
> @@ -358,7 +363,12 @@ void intel_bts_enable_local(void)
>  
>  void intel_bts_disable_local(void)
>  {
> -	struct bts_ctx *bts = this_cpu_ptr(bts_ctx);
> +	struct bts_ctx *bts;
> +
> +	if (!bts_ctx)
> +		return;
> +
> +	bts = this_cpu_ptr(bts_ctx);
>  
>  	/*
>  	 * Here we transition from ACTIVE to INACTIVE;
> @@ -450,12 +460,17 @@ bts_buffer_reset(struct bts_buffer *buf, struct perf_output_handle *handle)
>  int intel_bts_interrupt(void)
>  {
>  	struct debug_store *ds = this_cpu_ptr(&cpu_hw_events)->ds;
> -	struct bts_ctx *bts = this_cpu_ptr(bts_ctx);
> -	struct perf_event *event = bts->handle.event;
> +	struct bts_ctx *bts;
> +	struct perf_event *event;
>  	struct bts_buffer *buf;
>  	s64 old_head;
>  	int err = -ENOSPC, handled = 0;
>  
> +	if (!bts_ctx)
> +		return 0;
> +
> +	bts = this_cpu_ptr(bts_ctx);
> +	event = bts->handle.event;
>  	/*
>  	 * The only surefire way of knowing if this NMI is ours is by checking
>  	 * the write ptr against the PMI threshold.
> -- 
> 2.9.4
> 

  reply	other threads:[~2025-03-06 13:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06  5:11 [PATCH][next] perf/x86/intel/bts: check if bts_ctx is allocated when call bts functions lirongqing
2025-03-06 13:08 ` Jiri Olsa [this message]
2025-03-06 21:54 ` [tip: perf/core] perf/x86/intel/bts: Check if bts_ctx is allocated when calling BTS functions tip-bot2 for Li RongQing

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=Z8meVrqd-F7tf44j@krava \
    --to=olsajiri@gmail.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=irogers@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.