All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tip-bot2 for Sebastian Andrzej Siewior" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Marco Elver <elver@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: perf/core] perf: Split __perf_pending_irq() out of perf_pending_irq()
Date: Tue, 09 Jul 2024 11:41:57 -0000	[thread overview]
Message-ID: <172052531713.2215.12959971034104257463.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20240704170424.1466941-8-bigeasy@linutronix.de>

The following commit has been merged into the perf/core branch of tip:

Commit-ID:     2b84def990d388bed4afe4f21ae383a01991046c
Gitweb:        https://git.kernel.org/tip/2b84def990d388bed4afe4f21ae383a01991046c
Author:        Sebastian Andrzej Siewior <bigeasy@linutronix.de>
AuthorDate:    Thu, 04 Jul 2024 19:03:41 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 09 Jul 2024 13:26:37 +02:00

perf: Split __perf_pending_irq() out of perf_pending_irq()

perf_pending_irq() invokes perf_event_wakeup() and __perf_pending_irq().
The former is in charge of waking any tasks which waits to be woken up
while the latter disables perf-events.

The irq_work perf_pending_irq(), while this an irq_work, the callback
is invoked in thread context on PREEMPT_RT. This is needed because all
the waking functions (wake_up_all(), kill_fasync()) acquire sleep locks
which must not be used with disabled interrupts.
Disabling events, as done by __perf_pending_irq(), expects a hardirq
context and disabled interrupts. This requirement is not fulfilled on
PREEMPT_RT.

Split functionality based on perf_event::pending_disable into irq_work
named `pending_disable_irq' and invoke it in hardirq context on
PREEMPT_RT. Rename the split out callback to perf_pending_disable().

Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Marco Elver <elver@google.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/r/20240704170424.1466941-8-bigeasy@linutronix.de
---
 include/linux/perf_event.h |  1 +
 kernel/events/core.c       | 29 ++++++++++++++++++++++-------
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 99a7ea1..65ece0d 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -783,6 +783,7 @@ struct perf_event {
 	unsigned int			pending_disable;
 	unsigned long			pending_addr;	/* SIGTRAP */
 	struct irq_work			pending_irq;
+	struct irq_work			pending_disable_irq;
 	struct callback_head		pending_task;
 	unsigned int			pending_work;
 	struct rcuwait			pending_work_wait;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 96e03d6..f64c30e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2451,7 +2451,7 @@ static void __perf_event_disable(struct perf_event *event,
  * hold the top-level event's child_mutex, so any descendant that
  * goes to exit will block in perf_event_exit_event().
  *
- * When called from perf_pending_irq it's OK because event->ctx
+ * When called from perf_pending_disable it's OK because event->ctx
  * is the current context on this CPU and preemption is disabled,
  * hence we can't get into perf_event_task_sched_out for this context.
  */
@@ -2491,7 +2491,7 @@ EXPORT_SYMBOL_GPL(perf_event_disable);
 void perf_event_disable_inatomic(struct perf_event *event)
 {
 	event->pending_disable = 1;
-	irq_work_queue(&event->pending_irq);
+	irq_work_queue(&event->pending_disable_irq);
 }
 
 #define MAX_INTERRUPTS (~0ULL)
@@ -5218,6 +5218,7 @@ static void perf_pending_task_sync(struct perf_event *event)
 static void _free_event(struct perf_event *event)
 {
 	irq_work_sync(&event->pending_irq);
+	irq_work_sync(&event->pending_disable_irq);
 	perf_pending_task_sync(event);
 
 	unaccount_event(event);
@@ -6749,7 +6750,7 @@ static void perf_sigtrap(struct perf_event *event)
 /*
  * Deliver the pending work in-event-context or follow the context.
  */
-static void __perf_pending_irq(struct perf_event *event)
+static void __perf_pending_disable(struct perf_event *event)
 {
 	int cpu = READ_ONCE(event->oncpu);
 
@@ -6787,11 +6788,26 @@ static void __perf_pending_irq(struct perf_event *event)
 	 *				  irq_work_queue(); // FAILS
 	 *
 	 *  irq_work_run()
-	 *    perf_pending_irq()
+	 *    perf_pending_disable()
 	 *
 	 * But the event runs on CPU-B and wants disabling there.
 	 */
-	irq_work_queue_on(&event->pending_irq, cpu);
+	irq_work_queue_on(&event->pending_disable_irq, cpu);
+}
+
+static void perf_pending_disable(struct irq_work *entry)
+{
+	struct perf_event *event = container_of(entry, struct perf_event, pending_disable_irq);
+	int rctx;
+
+	/*
+	 * If we 'fail' here, that's OK, it means recursion is already disabled
+	 * and we won't recurse 'further'.
+	 */
+	rctx = perf_swevent_get_recursion_context();
+	__perf_pending_disable(event);
+	if (rctx >= 0)
+		perf_swevent_put_recursion_context(rctx);
 }
 
 static void perf_pending_irq(struct irq_work *entry)
@@ -6814,8 +6830,6 @@ static void perf_pending_irq(struct irq_work *entry)
 		perf_event_wakeup(event);
 	}
 
-	__perf_pending_irq(event);
-
 	if (rctx >= 0)
 		perf_swevent_put_recursion_context(rctx);
 }
@@ -11956,6 +11970,7 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
 
 	init_waitqueue_head(&event->waitq);
 	init_irq_work(&event->pending_irq, perf_pending_irq);
+	event->pending_disable_irq = IRQ_WORK_INIT_HARD(perf_pending_disable);
 	init_task_work(&event->pending_task, perf_pending_task);
 	rcuwait_init(&event->pending_work_wait);
 

  reply	other threads:[~2024-07-09 11:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-04 17:03 [PATCH v5 0/6] perf: Make SIGTRAP and __perf_pending_irq() work on RT Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 1/7] perf: Move irq_work_queue() where the event is prepared Sebastian Andrzej Siewior
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 2/7] task_work: Add TWA_NMI_CURRENT as an additional notify mode Sebastian Andrzej Siewior
2024-07-05 14:00   ` Sebastian Andrzej Siewior
2024-07-05 14:58     ` Peter Zijlstra
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 3/7] perf: Enqueue SIGTRAP always via task_work Sebastian Andrzej Siewior
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 4/7] perf: Shrink the size of the recursion counter Sebastian Andrzej Siewior
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 5/7] perf: Move swevent_htable::recursion into task_struct Sebastian Andrzej Siewior
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 6/7] perf: Don't disable preemption in perf_pending_task() Sebastian Andrzej Siewior
2024-07-09 11:41   ` [tip: perf/core] " tip-bot2 for Sebastian Andrzej Siewior
2024-07-04 17:03 ` [PATCH v5 7/7] perf: Split __perf_pending_irq() out of perf_pending_irq() Sebastian Andrzej Siewior
2024-07-09 11:41   ` tip-bot2 for Sebastian Andrzej Siewior [this message]
2024-07-04 19:45 ` [PATCH v5 0/6] perf: Make SIGTRAP and __perf_pending_irq() work on RT Arnaldo Carvalho de Melo
2024-07-04 19:46   ` Arnaldo Carvalho de Melo
2024-07-05  6:16   ` Sebastian Andrzej Siewior
2024-07-05  7:55 ` Peter Zijlstra
2024-07-05  7:58   ` Sebastian Andrzej Siewior

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=172052531713.2215.12959971034104257463.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=acme@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=elver@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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.