All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT pull] locking/urgent for v5.12-rc3
@ 2021-03-14 15:39 Thomas Gleixner
  2021-03-14 15:39 ` [GIT pull] objtool/urgent " Thomas Gleixner
                   ` (5 more replies)
  0 siblings, 6 replies; 20+ messages in thread
From: Thomas Gleixner @ 2021-03-14 15:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, x86

Linus,

please pull the latest locking/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-2021-03-14

up to:  4817a52b3061: seqlock,lockdep: Fix seqcount_latch_init()


A couple of locking fixes:
 
 - A fix for the static_call mechanism so it handles unaligned
   addresses correctly.

 - Make u64_stats_init() a macro so every instance gets a seperate lockdep
   key.

 - Make seqcount_latch_init() a macro as well to preserve the static
   variable which is used for the lockdep key.

Thanks,

	tglx

------------------>
Peter Zijlstra (3):
      static_call: Fix the module key fixup
      u64_stats,lockdep: Fix u64_stats_init() vs lockdep
      seqlock,lockdep: Fix seqcount_latch_init()


 include/linux/seqlock.h        | 5 +----
 include/linux/u64_stats_sync.h | 7 ++++---
 kernel/static_call.c           | 7 ++++---
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 2f7bb92b4c9e..f61e34fbaaea 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -664,10 +664,7 @@ typedef struct {
  * seqcount_latch_init() - runtime initializer for seqcount_latch_t
  * @s: Pointer to the seqcount_latch_t instance
  */
-static inline void seqcount_latch_init(seqcount_latch_t *s)
-{
-	seqcount_init(&s->seqcount);
-}
+#define seqcount_latch_init(s) seqcount_init(&(s)->seqcount)
 
 /**
  * raw_read_seqcount_latch() - pick even/odd latch data copy
diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
index c6abb79501b3..e81856c0ba13 100644
--- a/include/linux/u64_stats_sync.h
+++ b/include/linux/u64_stats_sync.h
@@ -115,12 +115,13 @@ static inline void u64_stats_inc(u64_stats_t *p)
 }
 #endif
 
+#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
+#define u64_stats_init(syncp)	seqcount_init(&(syncp)->seq)
+#else
 static inline void u64_stats_init(struct u64_stats_sync *syncp)
 {
-#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
-	seqcount_init(&syncp->seq);
-#endif
 }
+#endif
 
 static inline void u64_stats_update_begin(struct u64_stats_sync *syncp)
 {
diff --git a/kernel/static_call.c b/kernel/static_call.c
index 6906c6ec4c97..ae825295cf68 100644
--- a/kernel/static_call.c
+++ b/kernel/static_call.c
@@ -349,7 +349,8 @@ static int static_call_add_module(struct module *mod)
 	struct static_call_site *site;
 
 	for (site = start; site != stop; site++) {
-		unsigned long addr = (unsigned long)static_call_key(site);
+		unsigned long s_key = (long)site->key + (long)&site->key;
+		unsigned long addr = s_key & ~STATIC_CALL_SITE_FLAGS;
 		unsigned long key;
 
 		/*
@@ -373,8 +374,8 @@ static int static_call_add_module(struct module *mod)
 			return -EINVAL;
 		}
 
-		site->key = (key - (long)&site->key) |
-			    (site->key & STATIC_CALL_SITE_FLAGS);
+		key |= s_key & STATIC_CALL_SITE_FLAGS;
+		site->key = key - (long)&site->key;
 	}
 
 	return __static_call_init(mod, start, stop);


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [GIT pull] objtool/urgent for v5.12-rc3
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
@ 2021-03-14 15:39 ` Thomas Gleixner
  2021-03-14 20:38   ` pr-tracker-bot
  2021-03-14 15:39 ` [GIT pull] sched/urgent " Thomas Gleixner
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 20+ messages in thread
From: Thomas Gleixner @ 2021-03-14 15:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, x86

Linus,

please pull the latest objtool/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git objtool-urgent-2021-03-14

up to:  ba08abca66d4: objtool,x86: Fix uaccess PUSHF/POPF validation


A single objtool fix to handle the PUSHF/POPF validation correctly for the
paravirt changes which modified arch_local_irq_restore not to use popf.

Thanks,

	tglx

------------------>
Peter Zijlstra (1):
      objtool,x86: Fix uaccess PUSHF/POPF validation


 arch/x86/include/asm/smap.h | 10 ++++------
 tools/objtool/check.c       |  3 +++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h
index 8b58d6975d5d..0bc9b0895f33 100644
--- a/arch/x86/include/asm/smap.h
+++ b/arch/x86/include/asm/smap.h
@@ -58,9 +58,8 @@ static __always_inline unsigned long smap_save(void)
 	unsigned long flags;
 
 	asm volatile ("# smap_save\n\t"
-		      ALTERNATIVE("jmp 1f", "", X86_FEATURE_SMAP)
-		      "pushf; pop %0; " __ASM_CLAC "\n\t"
-		      "1:"
+		      ALTERNATIVE("", "pushf; pop %0; " __ASM_CLAC "\n\t",
+				  X86_FEATURE_SMAP)
 		      : "=rm" (flags) : : "memory", "cc");
 
 	return flags;
@@ -69,9 +68,8 @@ static __always_inline unsigned long smap_save(void)
 static __always_inline void smap_restore(unsigned long flags)
 {
 	asm volatile ("# smap_restore\n\t"
-		      ALTERNATIVE("jmp 1f", "", X86_FEATURE_SMAP)
-		      "push %0; popf\n\t"
-		      "1:"
+		      ALTERNATIVE("", "push %0; popf\n\t",
+				  X86_FEATURE_SMAP)
 		      : : "g" (flags) : "memory", "cc");
 }
 
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 068cdb41f76f..5e5388a38e2a 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2442,6 +2442,9 @@ static int handle_insn_ops(struct instruction *insn, struct insn_state *state)
 		if (update_cfi_state(insn, &state->cfi, op))
 			return 1;
 
+		if (!insn->alt_group)
+			continue;
+
 		if (op->dest.type == OP_DEST_PUSHF) {
 			if (!state->uaccess_stack) {
 				state->uaccess_stack = 1;


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [GIT pull] sched/urgent for v5.12-rc3
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
  2021-03-14 15:39 ` [GIT pull] objtool/urgent " Thomas Gleixner
@ 2021-03-14 15:39 ` Thomas Gleixner
  2021-03-14 20:38   ` pr-tracker-bot
  2021-03-14 15:40 ` [GIT pull] timers/urgent " Thomas Gleixner
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 20+ messages in thread
From: Thomas Gleixner @ 2021-03-14 15:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, x86

Linus,

please pull the latest sched/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-2021-03-14

up to:  ce29ddc47b91: sched/membarrier: fix missing local execution of ipi_sync_rq_state()


A set of scheduler updates:

  - Prevent a NULL pointer dereference in the migration_stop_cpu()
    mechanims

  - Prevent self concurrency of affine_move_task()

  - Small fixes and cleanups related to task migration/affinity setting

  - Ensure that sync_runqueues_membarrier_state() is invoked on the current
    CPU when it is in the cpu mask


Thanks,

	tglx

------------------>
Mathieu Desnoyers (1):
      sched/membarrier: fix missing local execution of ipi_sync_rq_state()

Peter Zijlstra (6):
      sched: Fix migration_cpu_stop() requeueing
      sched: Simplify migration_cpu_stop()
      sched: Collate affine_move_task() stoppers
      sched: Optimize migration_cpu_stop()
      sched: Fix affine_move_task() self-concurrency
      sched: Simplify set_affinity_pending refcounts


 kernel/sched/core.c       | 126 +++++++++++++++++++++++-----------------------
 kernel/sched/membarrier.c |   4 +-
 2 files changed, 63 insertions(+), 67 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ca2bb629595f..98191218d891 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1862,8 +1862,13 @@ struct migration_arg {
 	struct set_affinity_pending	*pending;
 };
 
+/*
+ * @refs: number of wait_for_completion()
+ * @stop_pending: is @stop_work in use
+ */
 struct set_affinity_pending {
 	refcount_t		refs;
+	unsigned int		stop_pending;
 	struct completion	done;
 	struct cpu_stop_work	stop_work;
 	struct migration_arg	arg;
@@ -1898,8 +1903,8 @@ static struct rq *__migrate_task(struct rq *rq, struct rq_flags *rf,
  */
 static int migration_cpu_stop(void *data)
 {
-	struct set_affinity_pending *pending;
 	struct migration_arg *arg = data;
+	struct set_affinity_pending *pending = arg->pending;
 	struct task_struct *p = arg->task;
 	int dest_cpu = arg->dest_cpu;
 	struct rq *rq = this_rq();
@@ -1921,7 +1926,6 @@ static int migration_cpu_stop(void *data)
 	raw_spin_lock(&p->pi_lock);
 	rq_lock(rq, &rf);
 
-	pending = p->migration_pending;
 	/*
 	 * If task_rq(p) != rq, it cannot be migrated here, because we're
 	 * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
@@ -1932,21 +1936,14 @@ static int migration_cpu_stop(void *data)
 			goto out;
 
 		if (pending) {
-			p->migration_pending = NULL;
+			if (p->migration_pending == pending)
+				p->migration_pending = NULL;
 			complete = true;
 		}
 
-		/* migrate_enable() --  we must not race against SCA */
 		if (dest_cpu < 0) {
-			/*
-			 * When this was migrate_enable() but we no longer
-			 * have a @pending, a concurrent SCA 'fixed' things
-			 * and we should be valid again. Nothing to do.
-			 */
-			if (!pending) {
-				WARN_ON_ONCE(!cpumask_test_cpu(task_cpu(p), &p->cpus_mask));
+			if (cpumask_test_cpu(task_cpu(p), &p->cpus_mask))
 				goto out;
-			}
 
 			dest_cpu = cpumask_any_distribute(&p->cpus_mask);
 		}
@@ -1956,7 +1953,14 @@ static int migration_cpu_stop(void *data)
 		else
 			p->wake_cpu = dest_cpu;
 
-	} else if (dest_cpu < 0 || pending) {
+		/*
+		 * XXX __migrate_task() can fail, at which point we might end
+		 * up running on a dodgy CPU, AFAICT this can only happen
+		 * during CPU hotplug, at which point we'll get pushed out
+		 * anyway, so it's probably not a big deal.
+		 */
+
+	} else if (pending) {
 		/*
 		 * This happens when we get migrated between migrate_enable()'s
 		 * preempt_enable() and scheduling the stopper task. At that
@@ -1971,43 +1975,32 @@ static int migration_cpu_stop(void *data)
 		 * ->pi_lock, so the allowed mask is stable - if it got
 		 * somewhere allowed, we're done.
 		 */
-		if (pending && cpumask_test_cpu(task_cpu(p), p->cpus_ptr)) {
-			p->migration_pending = NULL;
+		if (cpumask_test_cpu(task_cpu(p), p->cpus_ptr)) {
+			if (p->migration_pending == pending)
+				p->migration_pending = NULL;
 			complete = true;
 			goto out;
 		}
 
-		/*
-		 * When this was migrate_enable() but we no longer have an
-		 * @pending, a concurrent SCA 'fixed' things and we should be
-		 * valid again. Nothing to do.
-		 */
-		if (!pending) {
-			WARN_ON_ONCE(!cpumask_test_cpu(task_cpu(p), &p->cpus_mask));
-			goto out;
-		}
-
 		/*
 		 * When migrate_enable() hits a rq mis-match we can't reliably
 		 * determine is_migration_disabled() and so have to chase after
 		 * it.
 		 */
+		WARN_ON_ONCE(!pending->stop_pending);
 		task_rq_unlock(rq, p, &rf);
 		stop_one_cpu_nowait(task_cpu(p), migration_cpu_stop,
 				    &pending->arg, &pending->stop_work);
 		return 0;
 	}
 out:
+	if (pending)
+		pending->stop_pending = false;
 	task_rq_unlock(rq, p, &rf);
 
 	if (complete)
 		complete_all(&pending->done);
 
-	/* For pending->{arg,stop_work} */
-	pending = arg->pending;
-	if (pending && refcount_dec_and_test(&pending->refs))
-		wake_up_var(&pending->refs);
-
 	return 0;
 }
 
@@ -2194,11 +2187,7 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 			    int dest_cpu, unsigned int flags)
 {
 	struct set_affinity_pending my_pending = { }, *pending = NULL;
-	struct migration_arg arg = {
-		.task = p,
-		.dest_cpu = dest_cpu,
-	};
-	bool complete = false;
+	bool stop_pending, complete = false;
 
 	/* Can the task run on the task's current CPU? If so, we're done */
 	if (cpumask_test_cpu(task_cpu(p), &p->cpus_mask)) {
@@ -2210,12 +2199,16 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 			push_task = get_task_struct(p);
 		}
 
+		/*
+		 * If there are pending waiters, but no pending stop_work,
+		 * then complete now.
+		 */
 		pending = p->migration_pending;
-		if (pending) {
-			refcount_inc(&pending->refs);
+		if (pending && !pending->stop_pending) {
 			p->migration_pending = NULL;
 			complete = true;
 		}
+
 		task_rq_unlock(rq, p, rf);
 
 		if (push_task) {
@@ -2224,7 +2217,7 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 		}
 
 		if (complete)
-			goto do_complete;
+			complete_all(&pending->done);
 
 		return 0;
 	}
@@ -2235,6 +2228,12 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 			/* Install the request */
 			refcount_set(&my_pending.refs, 1);
 			init_completion(&my_pending.done);
+			my_pending.arg = (struct migration_arg) {
+				.task = p,
+				.dest_cpu = -1,		/* any */
+				.pending = &my_pending,
+			};
+
 			p->migration_pending = &my_pending;
 		} else {
 			pending = p->migration_pending;
@@ -2259,45 +2258,41 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 		return -EINVAL;
 	}
 
-	if (flags & SCA_MIGRATE_ENABLE) {
-
-		refcount_inc(&pending->refs); /* pending->{arg,stop_work} */
-		p->migration_flags &= ~MDF_PUSH;
-		task_rq_unlock(rq, p, rf);
-
-		pending->arg = (struct migration_arg) {
-			.task = p,
-			.dest_cpu = -1,
-			.pending = pending,
-		};
-
-		stop_one_cpu_nowait(cpu_of(rq), migration_cpu_stop,
-				    &pending->arg, &pending->stop_work);
-
-		return 0;
-	}
-
 	if (task_running(rq, p) || p->state == TASK_WAKING) {
 		/*
-		 * Lessen races (and headaches) by delegating
-		 * is_migration_disabled(p) checks to the stopper, which will
-		 * run on the same CPU as said p.
+		 * MIGRATE_ENABLE gets here because 'p == current', but for
+		 * anything else we cannot do is_migration_disabled(), punt
+		 * and have the stopper function handle it all race-free.
 		 */
+		stop_pending = pending->stop_pending;
+		if (!stop_pending)
+			pending->stop_pending = true;
+
+		if (flags & SCA_MIGRATE_ENABLE)
+			p->migration_flags &= ~MDF_PUSH;
+
 		task_rq_unlock(rq, p, rf);
-		stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
 
+		if (!stop_pending) {
+			stop_one_cpu_nowait(cpu_of(rq), migration_cpu_stop,
+					    &pending->arg, &pending->stop_work);
+		}
+
+		if (flags & SCA_MIGRATE_ENABLE)
+			return 0;
 	} else {
 
 		if (!is_migration_disabled(p)) {
 			if (task_on_rq_queued(p))
 				rq = move_queued_task(rq, rf, p, dest_cpu);
 
-			p->migration_pending = NULL;
-			complete = true;
+			if (!pending->stop_pending) {
+				p->migration_pending = NULL;
+				complete = true;
+			}
 		}
 		task_rq_unlock(rq, p, rf);
 
-do_complete:
 		if (complete)
 			complete_all(&pending->done);
 	}
@@ -2305,7 +2300,7 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 	wait_for_completion(&pending->done);
 
 	if (refcount_dec_and_test(&pending->refs))
-		wake_up_var(&pending->refs);
+		wake_up_var(&pending->refs); /* No UaF, just an address */
 
 	/*
 	 * Block the original owner of &pending until all subsequent callers
@@ -2313,6 +2308,9 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
 	 */
 	wait_var_event(&my_pending.refs, !refcount_read(&my_pending.refs));
 
+	/* ARGH */
+	WARN_ON_ONCE(my_pending.stop_pending);
+
 	return 0;
 }
 
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index acdae625c636..b5add64d9698 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -471,9 +471,7 @@ static int sync_runqueues_membarrier_state(struct mm_struct *mm)
 	}
 	rcu_read_unlock();
 
-	preempt_disable();
-	smp_call_function_many(tmpmask, ipi_sync_rq_state, mm, 1);
-	preempt_enable();
+	on_each_cpu_mask(tmpmask, ipi_sync_rq_state, mm, true);
 
 	free_cpumask_var(tmpmask);
 	cpus_read_unlock();


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [GIT pull] timers/urgent for v5.12-rc3
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
  2021-03-14 15:39 ` [GIT pull] objtool/urgent " Thomas Gleixner
  2021-03-14 15:39 ` [GIT pull] sched/urgent " Thomas Gleixner
@ 2021-03-14 15:40 ` Thomas Gleixner
  2021-03-14 20:38   ` pr-tracker-bot
  2021-03-14 15:40 ` [GIT pull] irq/urgent for v5.12-rc2 Thomas Gleixner
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 20+ messages in thread
From: Thomas Gleixner @ 2021-03-14 15:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, x86

Linus,

please pull the latest timers/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-2021-03-14

up to:  46eb1701c046: hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event()


A single fix in for hrtimers to prevent an interrupt storm caused by the
lack of reevaluation of the timers which expire in softirq context under
certain circumstances, e.g. when the clock was set.

Thanks,

	tglx

------------------>
Anna-Maria Behnsen (1):
      hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event()


 kernel/time/hrtimer.c | 60 +++++++++++++++++++++++++++++++++------------------
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 743c852e10f2..788b9d137de4 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -546,8 +546,11 @@ static ktime_t __hrtimer_next_event_base(struct hrtimer_cpu_base *cpu_base,
 }
 
 /*
- * Recomputes cpu_base::*next_timer and returns the earliest expires_next but
- * does not set cpu_base::*expires_next, that is done by hrtimer_reprogram.
+ * Recomputes cpu_base::*next_timer and returns the earliest expires_next
+ * but does not set cpu_base::*expires_next, that is done by
+ * hrtimer[_force]_reprogram and hrtimer_interrupt only. When updating
+ * cpu_base::*expires_next right away, reprogramming logic would no longer
+ * work.
  *
  * When a softirq is pending, we can ignore the HRTIMER_ACTIVE_SOFT bases,
  * those timers will get run whenever the softirq gets handled, at the end of
@@ -588,6 +591,37 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base *cpu_base, unsigned int active_
 	return expires_next;
 }
 
+static ktime_t hrtimer_update_next_event(struct hrtimer_cpu_base *cpu_base)
+{
+	ktime_t expires_next, soft = KTIME_MAX;
+
+	/*
+	 * If the soft interrupt has already been activated, ignore the
+	 * soft bases. They will be handled in the already raised soft
+	 * interrupt.
+	 */
+	if (!cpu_base->softirq_activated) {
+		soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT);
+		/*
+		 * Update the soft expiry time. clock_settime() might have
+		 * affected it.
+		 */
+		cpu_base->softirq_expires_next = soft;
+	}
+
+	expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD);
+	/*
+	 * If a softirq timer is expiring first, update cpu_base->next_timer
+	 * and program the hardware with the soft expiry time.
+	 */
+	if (expires_next > soft) {
+		cpu_base->next_timer = cpu_base->softirq_next_timer;
+		expires_next = soft;
+	}
+
+	return expires_next;
+}
+
 static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base)
 {
 	ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset;
@@ -628,23 +662,7 @@ hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal)
 {
 	ktime_t expires_next;
 
-	/*
-	 * Find the current next expiration time.
-	 */
-	expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
-
-	if (cpu_base->next_timer && cpu_base->next_timer->is_soft) {
-		/*
-		 * When the softirq is activated, hrtimer has to be
-		 * programmed with the first hard hrtimer because soft
-		 * timer interrupt could occur too late.
-		 */
-		if (cpu_base->softirq_activated)
-			expires_next = __hrtimer_get_next_event(cpu_base,
-								HRTIMER_ACTIVE_HARD);
-		else
-			cpu_base->softirq_expires_next = expires_next;
-	}
+	expires_next = hrtimer_update_next_event(cpu_base);
 
 	if (skip_equal && expires_next == cpu_base->expires_next)
 		return;
@@ -1644,8 +1662,8 @@ void hrtimer_interrupt(struct clock_event_device *dev)
 
 	__hrtimer_run_queues(cpu_base, now, flags, HRTIMER_ACTIVE_HARD);
 
-	/* Reevaluate the clock bases for the next expiry */
-	expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL);
+	/* Reevaluate the clock bases for the [soft] next expiry */
+	expires_next = hrtimer_update_next_event(cpu_base);
 	/*
 	 * Store the new expiry value so the migration code can verify
 	 * against it.


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* [GIT pull] irq/urgent for v5.12-rc2
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
                   ` (2 preceding siblings ...)
  2021-03-14 15:40 ` [GIT pull] timers/urgent " Thomas Gleixner
@ 2021-03-14 15:40 ` Thomas Gleixner
  2021-03-14 20:38   ` pr-tracker-bot
  2021-03-14 20:15 ` [GIT pull] locking/urgent for v5.12-rc3 Linus Torvalds
  2021-03-14 20:38 ` pr-tracker-bot
  5 siblings, 1 reply; 20+ messages in thread
From: Thomas Gleixner @ 2021-03-14 15:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, x86

Linus,

please pull the latest irq/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-2021-03-14

up to:  b470ebc9e0e5: Merge tag 'irqchip-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent


A set of irqchip updates:

  - Make the GENERIC_IRQ_MULTI_HANDLER configuration correct

  - Add a missing DT compatible string fir tge Ingenic driver

  - Remove the pointless debugfs_file pointer from struct irqdomain

Thanks,

	tglx

------------------>
Greg Kroah-Hartman (1):
      irqdomain: Remove debugfs_file from struct irq_domain

Marc Zyngier (2):
      ARM: ep93xx: Select GENERIC_IRQ_MULTI_HANDLER directly
      irqchip: Do not blindly select CONFIG_GENERIC_IRQ_MULTI_HANDLER

Paul Cercueil (2):
      dt-bindings/irq: Add compatible string for the JZ4760B
      irqchip/ingenic: Add support for the JZ4760


 .../devicetree/bindings/interrupt-controller/ingenic,intc.yaml   | 1 +
 arch/arm/Kconfig                                                 | 1 +
 drivers/irqchip/Kconfig                                          | 9 ---------
 drivers/irqchip/irq-ingenic-tcu.c                                | 1 +
 drivers/irqchip/irq-ingenic.c                                    | 1 +
 include/linux/irqdomain.h                                        | 4 ----
 kernel/irq/irqdomain.c                                           | 9 ++++-----
 7 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
index 0a046be8d1cd..0358a7739c8e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml
@@ -23,6 +23,7 @@ properties:
           - enum:
               - ingenic,jz4775-intc
               - ingenic,jz4770-intc
+              - ingenic,jz4760b-intc
           - const: ingenic,jz4760-intc
       - items:
           - const: ingenic,x1000-intc
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 853aab5ab327..5da96f5df48f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -348,6 +348,7 @@ config ARCH_EP93XX
 	select ARM_AMBA
 	imply ARM_PATCH_PHYS_VIRT
 	select ARM_VIC
+	select GENERIC_IRQ_MULTI_HANDLER
 	select AUTO_ZRELADDR
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e74fa206240a..15536e321df5 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -8,7 +8,6 @@ config IRQCHIP
 config ARM_GIC
 	bool
 	select IRQ_DOMAIN_HIERARCHY
-	select GENERIC_IRQ_MULTI_HANDLER
 	select GENERIC_IRQ_EFFECTIVE_AFF_MASK
 
 config ARM_GIC_PM
@@ -33,7 +32,6 @@ config GIC_NON_BANKED
 
 config ARM_GIC_V3
 	bool
-	select GENERIC_IRQ_MULTI_HANDLER
 	select IRQ_DOMAIN_HIERARCHY
 	select PARTITION_PERCPU
 	select GENERIC_IRQ_EFFECTIVE_AFF_MASK
@@ -64,7 +62,6 @@ config ARM_NVIC
 config ARM_VIC
 	bool
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 
 config ARM_VIC_NR
 	int
@@ -99,14 +96,12 @@ config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 	select SPARSE_IRQ
 
 config ATMEL_AIC5_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 	select SPARSE_IRQ
 
 config I8259
@@ -153,7 +148,6 @@ config DW_APB_ICTL
 config FARADAY_FTINTC010
 	bool
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 	select SPARSE_IRQ
 
 config HISILICON_IRQ_MBIGEN
@@ -169,7 +163,6 @@ config IMGPDC_IRQ
 config IXP4XX_IRQ
 	bool
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 	select SPARSE_IRQ
 
 config MADERA_IRQ
@@ -186,7 +179,6 @@ config CLPS711X_IRQCHIP
 	bool
 	depends on ARCH_CLPS711X
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 	select SPARSE_IRQ
 	default y
 
@@ -205,7 +197,6 @@ config OMAP_IRQCHIP
 config ORION_IRQCHIP
 	bool
 	select IRQ_DOMAIN
-	select GENERIC_IRQ_MULTI_HANDLER
 
 config PIC32_EVIC
 	bool
diff --git a/drivers/irqchip/irq-ingenic-tcu.c b/drivers/irqchip/irq-ingenic-tcu.c
index 7a7222d4c19c..b938d1d04d96 100644
--- a/drivers/irqchip/irq-ingenic-tcu.c
+++ b/drivers/irqchip/irq-ingenic-tcu.c
@@ -179,5 +179,6 @@ static int __init ingenic_tcu_irq_init(struct device_node *np,
 }
 IRQCHIP_DECLARE(jz4740_tcu_irq, "ingenic,jz4740-tcu", ingenic_tcu_irq_init);
 IRQCHIP_DECLARE(jz4725b_tcu_irq, "ingenic,jz4725b-tcu", ingenic_tcu_irq_init);
+IRQCHIP_DECLARE(jz4760_tcu_irq, "ingenic,jz4760-tcu", ingenic_tcu_irq_init);
 IRQCHIP_DECLARE(jz4770_tcu_irq, "ingenic,jz4770-tcu", ingenic_tcu_irq_init);
 IRQCHIP_DECLARE(x1000_tcu_irq, "ingenic,x1000-tcu", ingenic_tcu_irq_init);
diff --git a/drivers/irqchip/irq-ingenic.c b/drivers/irqchip/irq-ingenic.c
index b61a8901ef72..ea36bb00be80 100644
--- a/drivers/irqchip/irq-ingenic.c
+++ b/drivers/irqchip/irq-ingenic.c
@@ -155,6 +155,7 @@ static int __init intc_2chip_of_init(struct device_node *node,
 {
 	return ingenic_intc_of_init(node, 2);
 }
+IRQCHIP_DECLARE(jz4760_intc, "ingenic,jz4760-intc", intc_2chip_of_init);
 IRQCHIP_DECLARE(jz4770_intc, "ingenic,jz4770-intc", intc_2chip_of_init);
 IRQCHIP_DECLARE(jz4775_intc, "ingenic,jz4775-intc", intc_2chip_of_init);
 IRQCHIP_DECLARE(jz4780_intc, "ingenic,jz4780-intc", intc_2chip_of_init);
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 42d196805f58..33cacc8af26d 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -150,7 +150,6 @@ struct irq_domain_chip_generic;
  *      setting up one or more generic chips for interrupt controllers
  *      drivers using the generic chip library which uses this pointer.
  * @parent: Pointer to parent irq_domain to support hierarchy irq_domains
- * @debugfs_file: dentry for the domain debugfs file
  *
  * Revmap data, used internally by irq_domain
  * @revmap_direct_max_irq: The largest hwirq that can be set for controllers that
@@ -174,9 +173,6 @@ struct irq_domain {
 #ifdef	CONFIG_IRQ_DOMAIN_HIERARCHY
 	struct irq_domain *parent;
 #endif
-#ifdef CONFIG_GENERIC_IRQ_DEBUGFS
-	struct dentry		*debugfs_file;
-#endif
 
 	/* reverse map data. The linear map gets appended to the irq_domain */
 	irq_hw_number_t hwirq_max;
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 288151393a06..d10ab1d689d5 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1898,16 +1898,15 @@ DEFINE_SHOW_ATTRIBUTE(irq_domain_debug);
 
 static void debugfs_add_domain_dir(struct irq_domain *d)
 {
-	if (!d->name || !domain_dir || d->debugfs_file)
+	if (!d->name || !domain_dir)
 		return;
-	d->debugfs_file = debugfs_create_file(d->name, 0444, domain_dir, d,
-					      &irq_domain_debug_fops);
+	debugfs_create_file(d->name, 0444, domain_dir, d,
+			    &irq_domain_debug_fops);
 }
 
 static void debugfs_remove_domain_dir(struct irq_domain *d)
 {
-	debugfs_remove(d->debugfs_file);
-	d->debugfs_file = NULL;
+	debugfs_remove(debugfs_lookup(d->name, domain_dir));
 }
 
 void __init irq_domain_debugfs_init(struct dentry *root)


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
                   ` (3 preceding siblings ...)
  2021-03-14 15:40 ` [GIT pull] irq/urgent for v5.12-rc2 Thomas Gleixner
@ 2021-03-14 20:15 ` Linus Torvalds
  2021-03-15  8:33   ` Peter Zijlstra
  2021-03-14 20:38 ` pr-tracker-bot
  5 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2021-03-14 20:15 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux Kernel Mailing List, the arch/x86 maintainers

On Sun, Mar 14, 2021 at 8:40 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
>  - A fix for the static_call mechanism so it handles unaligned
>    addresses correctly.

I'm not disputing the fix in any way, but why weren't the relocation
info and function start addresses mutually aligned?

Are we perhaps missing some .align directive somewhere?

Or am I missing something?

             Linus

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] irq/urgent for v5.12-rc2
  2021-03-14 15:40 ` [GIT pull] irq/urgent for v5.12-rc2 Thomas Gleixner
@ 2021-03-14 20:38   ` pr-tracker-bot
  0 siblings, 0 replies; 20+ messages in thread
From: pr-tracker-bot @ 2021-03-14 20:38 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86

The pull request you sent on Sun, 14 Mar 2021 15:40:01 -0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-2021-03-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70404fe3030ec2dcf339a9730bc03bf0e1f2acf5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] objtool/urgent for v5.12-rc3
  2021-03-14 15:39 ` [GIT pull] objtool/urgent " Thomas Gleixner
@ 2021-03-14 20:38   ` pr-tracker-bot
  0 siblings, 0 replies; 20+ messages in thread
From: pr-tracker-bot @ 2021-03-14 20:38 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86

The pull request you sent on Sun, 14 Mar 2021 15:39:57 -0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git objtool-urgent-2021-03-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/19469d2adab9a94e3c1713b7a12a67f9c59c1161

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] sched/urgent for v5.12-rc3
  2021-03-14 15:39 ` [GIT pull] sched/urgent " Thomas Gleixner
@ 2021-03-14 20:38   ` pr-tracker-bot
  0 siblings, 0 replies; 20+ messages in thread
From: pr-tracker-bot @ 2021-03-14 20:38 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86

The pull request you sent on Sun, 14 Mar 2021 15:39:59 -0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-2021-03-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c72cbc936141eac737b24f43e742cefaab35edd6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
                   ` (4 preceding siblings ...)
  2021-03-14 20:15 ` [GIT pull] locking/urgent for v5.12-rc3 Linus Torvalds
@ 2021-03-14 20:38 ` pr-tracker-bot
  5 siblings, 0 replies; 20+ messages in thread
From: pr-tracker-bot @ 2021-03-14 20:38 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86

The pull request you sent on Sun, 14 Mar 2021 15:39:56 -0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-2021-03-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fa509ff879f816ce50800d20fc87564b69f53962

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] timers/urgent for v5.12-rc3
  2021-03-14 15:40 ` [GIT pull] timers/urgent " Thomas Gleixner
@ 2021-03-14 20:38   ` pr-tracker-bot
  0 siblings, 0 replies; 20+ messages in thread
From: pr-tracker-bot @ 2021-03-14 20:38 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linus Torvalds, linux-kernel, x86

The pull request you sent on Sun, 14 Mar 2021 15:40:00 -0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-urgent-2021-03-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/802b31c0dd7f44c9ab44d39c6c4af22d958ad803

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-14 20:15 ` [GIT pull] locking/urgent for v5.12-rc3 Linus Torvalds
@ 2021-03-15  8:33   ` Peter Zijlstra
  2021-03-15 11:10     ` Peter Zijlstra
  0 siblings, 1 reply; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15  8:33 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Linux Kernel Mailing List, the arch/x86 maintainers

On Sun, Mar 14, 2021 at 01:15:25PM -0700, Linus Torvalds wrote:
> On Sun, Mar 14, 2021 at 8:40 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> >  - A fix for the static_call mechanism so it handles unaligned
> >    addresses correctly.
> 
> I'm not disputing the fix in any way, but why weren't the relocation
> info and function start addresses mutually aligned?
> 
> Are we perhaps missing some .align directive somewhere?
> 
> Or am I missing something?

So I considered looking into that, but since carrying the flag on the
absolute address is always correct I figured it was the more robust fix.

I suppose I can try and figure out where alignment went wobbly.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15  8:33   ` Peter Zijlstra
@ 2021-03-15 11:10     ` Peter Zijlstra
  2021-03-15 11:26       ` Peter Zijlstra
  0 siblings, 1 reply; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15 11:10 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Linux Kernel Mailing List, the arch/x86 maintainers

On Mon, Mar 15, 2021 at 09:33:45AM +0100, Peter Zijlstra wrote:
> On Sun, Mar 14, 2021 at 01:15:25PM -0700, Linus Torvalds wrote:
> > On Sun, Mar 14, 2021 at 8:40 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> > >
> > >  - A fix for the static_call mechanism so it handles unaligned
> > >    addresses correctly.
> > 
> > I'm not disputing the fix in any way, but why weren't the relocation
> > info and function start addresses mutually aligned?
> > 
> > Are we perhaps missing some .align directive somewhere?
> > 
> > Or am I missing something?
> 
> So I considered looking into that, but since carrying the flag on the
> absolute address is always correct I figured it was the more robust fix.
> 
> I suppose I can try and figure out where alignment went wobbly.

include/asm-generic/vmlinux.lds.h:

#define STATIC_CALL_DATA						\
	. = ALIGN(8);							\
	__start_static_call_sites = .;					\
	KEEP(*(.static_call_sites))					\
	__stop_static_call_sites = .;					\
	__start_static_call_tramp_key = .;				\
	KEEP(*(.static_call_tramp_key))					\
	__stop_static_call_tramp_key = .;

#ifndef RO_AFTER_INIT_DATA
#define RO_AFTER_INIT_DATA						\
	. = ALIGN(8);							\
	__start_ro_after_init = .;					\
	*(.data..ro_after_init)						\
	JUMP_TABLE_DATA							\
	STATIC_CALL_DATA						\
	__end_ro_after_init = .;
#endif

	.rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {		\
		__start_rodata = .;					\
		*(.rodata) *(.rodata.*)					\
		SCHED_DATA						\
		RO_AFTER_INIT_DATA	/* Read only after init */	\
		. = ALIGN(8);						\
		__start___tracepoints_ptrs = .;				\
		KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
		__stop___tracepoints_ptrs = .;				\
		*(__tracepoints_strings)/* Tracepoints: strings */	\
	}								\


$ nm defconfig-build/vmlinux | grep static_call_sites
ffffffff82916dc0 D __start_static_call_sites
ffffffff8291aaf0 D __stop_static_call_sites


Which all reads to me like it *SHOULD* work. Howver when I was debugging
the crash as reported by Steve (using his .config), I definitely saw
non-aligned base offsets causing mayhem.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 11:10     ` Peter Zijlstra
@ 2021-03-15 11:26       ` Peter Zijlstra
  2021-03-15 12:08         ` Peter Zijlstra
  0 siblings, 1 reply; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15 11:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt, Josh Poimboeuf

On Mon, Mar 15, 2021 at 12:10:10PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 15, 2021 at 09:33:45AM +0100, Peter Zijlstra wrote:
> > On Sun, Mar 14, 2021 at 01:15:25PM -0700, Linus Torvalds wrote:
> > > On Sun, Mar 14, 2021 at 8:40 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> > > >
> > > >  - A fix for the static_call mechanism so it handles unaligned
> > > >    addresses correctly.
> > > 
> > > I'm not disputing the fix in any way, but why weren't the relocation
> > > info and function start addresses mutually aligned?
> > > 
> > > Are we perhaps missing some .align directive somewhere?
> > > 
> > > Or am I missing something?
> > 
> > So I considered looking into that, but since carrying the flag on the
> > absolute address is always correct I figured it was the more robust fix.
> > 
> > I suppose I can try and figure out where alignment went wobbly.
> 
> include/asm-generic/vmlinux.lds.h:
> 
> #define STATIC_CALL_DATA						\
> 	. = ALIGN(8);							\
> 	__start_static_call_sites = .;					\
> 	KEEP(*(.static_call_sites))					\
> 	__stop_static_call_sites = .;					\
> 	__start_static_call_tramp_key = .;				\
> 	KEEP(*(.static_call_tramp_key))					\
> 	__stop_static_call_tramp_key = .;
> 
> #ifndef RO_AFTER_INIT_DATA
> #define RO_AFTER_INIT_DATA						\
> 	. = ALIGN(8);							\
> 	__start_ro_after_init = .;					\
> 	*(.data..ro_after_init)						\
> 	JUMP_TABLE_DATA							\
> 	STATIC_CALL_DATA						\
> 	__end_ro_after_init = .;
> #endif
> 
> 	.rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {		\
> 		__start_rodata = .;					\
> 		*(.rodata) *(.rodata.*)					\
> 		SCHED_DATA						\
> 		RO_AFTER_INIT_DATA	/* Read only after init */	\
> 		. = ALIGN(8);						\
> 		__start___tracepoints_ptrs = .;				\
> 		KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
> 		__stop___tracepoints_ptrs = .;				\
> 		*(__tracepoints_strings)/* Tracepoints: strings */	\
> 	}								\
> 
> 
> $ nm defconfig-build/vmlinux | grep static_call_sites
> ffffffff82916dc0 D __start_static_call_sites
> ffffffff8291aaf0 D __stop_static_call_sites
> 
> 
> Which all reads to me like it *SHOULD* work. Howver when I was debugging
> the crash as reported by Steve (using his .config), I definitely saw
> non-aligned base offsets causing mayhem.

Ooooh, modules don't have this. They still have regular
.static_call_sites sections, and *those* are unaligned.

Section Headers:
[Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al

[16] .static_call_sites PROGBITS        0000000000000000 008aa1 0006f0 00  WA  0   0  1

And that goes *BOOM*.. Let me ses if I can figure out how to make
objtool align those sections.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 11:26       ` Peter Zijlstra
@ 2021-03-15 12:08         ` Peter Zijlstra
  2021-03-15 13:31           ` Steven Rostedt
  2021-03-15 17:03           ` Josh Poimboeuf
  0 siblings, 2 replies; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15 12:08 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt, Josh Poimboeuf

On Mon, Mar 15, 2021 at 12:26:12PM +0100, Peter Zijlstra wrote:
> Ooooh, modules don't have this. They still have regular
> .static_call_sites sections, and *those* are unaligned.
> 
> Section Headers:
> [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
> 
> [16] .static_call_sites PROGBITS        0000000000000000 008aa1 0006f0 00  WA  0   0  1
> 
> And that goes *BOOM*.. Let me ses if I can figure out how to make
> objtool align those sections.

The below seems to have cured it:

[16] .static_call_sites PROGBITS        0000000000000000 008aa8 0006f0 00  WA  0   0  8


So, anybody any opinion on if we ought to do this?


---
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -683,7 +683,7 @@ static int elf_add_alternative(struct el
 	sec = find_section_by_name(elf, ".altinstructions");
 	if (!sec) {
 		sec = elf_create_section(elf, ".altinstructions",
-					 SHF_WRITE, size, 0);
+					 SHF_WRITE, size, 1, 0);
 
 		if (!sec) {
 			WARN_ELF("elf_create_section");
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -456,7 +456,7 @@ static int create_static_call_sections(s
 		idx++;
 
 	sec = elf_create_section(file->elf, ".static_call_sites", SHF_WRITE,
-				 sizeof(struct static_call_site), idx);
+				 sizeof(struct static_call_site), sizeof(unsigned long), idx);
 	if (!sec)
 		return -1;
 
@@ -567,7 +567,8 @@ static int create_mcount_loc_sections(st
 	list_for_each_entry(insn, &file->mcount_loc_list, mcount_loc_node)
 		idx++;
 
-	sec = elf_create_section(file->elf, "__mcount_loc", 0, sizeof(unsigned long), idx);
+	sec = elf_create_section(file->elf, "__mcount_loc", 0, sizeof(unsigned long),
+				sizeof(unsigned long), idx);
 	if (!sec)
 		return -1;
 
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -737,7 +737,8 @@ struct symbol *elf_create_undef_symbol(s
 }
 
 struct section *elf_create_section(struct elf *elf, const char *name,
-				   unsigned int sh_flags, size_t entsize, int nr)
+				   unsigned int sh_flags, size_t entsize,
+				   size_t entalign, int nr)
 {
 	struct section *sec, *shstrtab;
 	size_t size = entsize * nr;
@@ -777,7 +778,7 @@ struct section *elf_create_section(struc
 	}
 
 	sec->data->d_size = size;
-	sec->data->d_align = 1;
+	sec->data->d_align = entalign;
 
 	if (size) {
 		sec->data->d_buf = malloc(size);
@@ -796,7 +797,7 @@ struct section *elf_create_section(struc
 	sec->sh.sh_size = size;
 	sec->sh.sh_entsize = entsize;
 	sec->sh.sh_type = SHT_PROGBITS;
-	sec->sh.sh_addralign = 1;
+	sec->sh.sh_addralign = entalign;
 	sec->sh.sh_flags = SHF_ALLOC | sh_flags;
 
 
@@ -852,7 +853,7 @@ static struct section *elf_create_rel_re
 	strcpy(relocname, ".rel");
 	strcat(relocname, base->name);
 
-	sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rel), 0);
+	sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rel), 1, 0);
 	free(relocname);
 	if (!sec)
 		return NULL;
@@ -882,7 +883,7 @@ static struct section *elf_create_rela_r
 	strcpy(relocname, ".rela");
 	strcat(relocname, base->name);
 
-	sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rela), 0);
+	sec = elf_create_section(elf, relocname, 0, sizeof(GElf_Rela), 1, 0);
 	free(relocname);
 	if (!sec)
 		return NULL;
--- a/tools/objtool/include/objtool/elf.h
+++ b/tools/objtool/include/objtool/elf.h
@@ -121,7 +121,7 @@ static inline u32 reloc_hash(struct relo
 }
 
 struct elf *elf_open_read(const char *name, int flags);
-struct section *elf_create_section(struct elf *elf, const char *name, unsigned int sh_flags, size_t entsize, int nr);
+struct section *elf_create_section(struct elf *elf, const char *name, unsigned int sh_flags, size_t entsize, size_t entalign, int nr);
 struct section *elf_create_reloc_section(struct elf *elf, struct section *base, int reltype);
 void elf_add_reloc(struct elf *elf, struct reloc *reloc);
 int elf_write_insn(struct elf *elf, struct section *sec,
--- a/tools/objtool/orc_gen.c
+++ b/tools/objtool/orc_gen.c
@@ -235,11 +235,11 @@ int orc_create(struct objtool_file *file
 		return -1;
 	}
 	orc_sec = elf_create_section(file->elf, ".orc_unwind", 0,
-				     sizeof(struct orc_entry), nr);
+				     sizeof(struct orc_entry), 1, nr);
 	if (!orc_sec)
 		return -1;
 
-	sec = elf_create_section(file->elf, ".orc_unwind_ip", 0, sizeof(int), nr);
+	sec = elf_create_section(file->elf, ".orc_unwind_ip", 0, sizeof(int), 1, nr);
 	if (!sec)
 		return -1;
 	ip_rsec = elf_create_reloc_section(file->elf, sec, SHT_RELA);

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 12:08         ` Peter Zijlstra
@ 2021-03-15 13:31           ` Steven Rostedt
  2021-03-15 17:03           ` Josh Poimboeuf
  1 sibling, 0 replies; 20+ messages in thread
From: Steven Rostedt @ 2021-03-15 13:31 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Linus Torvalds, Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Josh Poimboeuf

On Mon, 15 Mar 2021 13:08:27 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> So, anybody any opinion on if we ought to do this?

Looks fine to me.

-- Steve

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 12:08         ` Peter Zijlstra
  2021-03-15 13:31           ` Steven Rostedt
@ 2021-03-15 17:03           ` Josh Poimboeuf
  2021-03-15 17:43             ` Peter Zijlstra
  2021-03-15 18:59             ` Linus Torvalds
  1 sibling, 2 replies; 20+ messages in thread
From: Josh Poimboeuf @ 2021-03-15 17:03 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Linus Torvalds, Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt

On Mon, Mar 15, 2021 at 01:08:27PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 15, 2021 at 12:26:12PM +0100, Peter Zijlstra wrote:
> > Ooooh, modules don't have this. They still have regular
> > .static_call_sites sections, and *those* are unaligned.
> > 
> > Section Headers:
> > [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
> > 
> > [16] .static_call_sites PROGBITS        0000000000000000 008aa1 0006f0 00  WA  0   0  1
> > 
> > And that goes *BOOM*.. Let me ses if I can figure out how to make
> > objtool align those sections.
> 
> The below seems to have cured it:
> 
> [16] .static_call_sites PROGBITS        0000000000000000 008aa8 0006f0 00  WA  0   0  8
> 
> 
> So, anybody any opinion on if we ought to do this?

I'd say yes to alignment, for the sake of consistency with vmlinux.

Though instead of using objtool, it can be done in the module linker
script:

diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 168cd27e6122..73345cbfe100 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -17,6 +17,7 @@ SECTIONS {
 	.init_array		0 : ALIGN(8) { *(SORT(.init_array.*)) *(.init_array) }
 
 	__jump_table		0 : ALIGN(8) { KEEP(*(__jump_table)) }
+	.static_call_sites	0 : ALIGN(8) { KEEP(*(.static_call_sites)) }
 
 	__patchable_function_entries : { *(__patchable_function_entries) }
 


^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 17:03           ` Josh Poimboeuf
@ 2021-03-15 17:43             ` Peter Zijlstra
  2021-03-15 18:59             ` Linus Torvalds
  1 sibling, 0 replies; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15 17:43 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Linus Torvalds, Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt

On Mon, Mar 15, 2021 at 12:03:21PM -0500, Josh Poimboeuf wrote:
> On Mon, Mar 15, 2021 at 01:08:27PM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 15, 2021 at 12:26:12PM +0100, Peter Zijlstra wrote:
> > > Ooooh, modules don't have this. They still have regular
> > > .static_call_sites sections, and *those* are unaligned.
> > > 
> > > Section Headers:
> > > [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
> > > 
> > > [16] .static_call_sites PROGBITS        0000000000000000 008aa1 0006f0 00  WA  0   0  1
> > > 
> > > And that goes *BOOM*.. Let me ses if I can figure out how to make
> > > objtool align those sections.
> > 
> > The below seems to have cured it:
> > 
> > [16] .static_call_sites PROGBITS        0000000000000000 008aa8 0006f0 00  WA  0   0  8
> > 
> > 
> > So, anybody any opinion on if we ought to do this?
> 
> I'd say yes to alignment, for the sake of consistency with vmlinux.
> 
> Though instead of using objtool, it can be done in the module linker
> script:

Pfff, I should've looked for one.. Yes, that's much nicer.

> diff --git a/scripts/module.lds.S b/scripts/module.lds.S
> index 168cd27e6122..73345cbfe100 100644
> --- a/scripts/module.lds.S
> +++ b/scripts/module.lds.S
> @@ -17,6 +17,7 @@ SECTIONS {
>  	.init_array		0 : ALIGN(8) { *(SORT(.init_array.*)) *(.init_array) }
>  
>  	__jump_table		0 : ALIGN(8) { KEEP(*(__jump_table)) }
> +	.static_call_sites	0 : ALIGN(8) { KEEP(*(.static_call_sites)) }
>  
>  	__patchable_function_entries : { *(__patchable_function_entries) }
>  
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 17:03           ` Josh Poimboeuf
  2021-03-15 17:43             ` Peter Zijlstra
@ 2021-03-15 18:59             ` Linus Torvalds
  2021-03-15 22:09               ` Peter Zijlstra
  1 sibling, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2021-03-15 18:59 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Peter Zijlstra, Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt

On Mon, Mar 15, 2021 at 10:03 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> Though instead of using objtool, it can be done in the module linker
> script:

This is obviously the way to go, but it raises another question: do we
guarantee that functions are aligned?

We actually have a couple of 32-bit x86 sub-architectures that do

    -falign-functions=0

ie Crusoe, Efficeon, and Cyrix III. Also "-Os" does that, iirc.

Is it only the static_call_sites entry itself that needs the
alignment? Or do we end up depending on the static call function being
at least 4-byte aligned too? The way it plays games with the key makes
me worry.

             Linus

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [GIT pull] locking/urgent for v5.12-rc3
  2021-03-15 18:59             ` Linus Torvalds
@ 2021-03-15 22:09               ` Peter Zijlstra
  0 siblings, 0 replies; 20+ messages in thread
From: Peter Zijlstra @ 2021-03-15 22:09 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Josh Poimboeuf, Thomas Gleixner, Linux Kernel Mailing List,
	the arch/x86 maintainers, Steven Rostedt

On Mon, Mar 15, 2021 at 11:59:12AM -0700, Linus Torvalds wrote:
> Is it only the static_call_sites entry itself that needs the
> alignment? Or do we end up depending on the static call function being
> at least 4-byte aligned too? The way it plays games with the key makes
> me worry.

The only thing that absolutely needs to be aligned is the
struct static_call_key address. We use the 2 LSB there.

The code address has no alignment requirements, due to x86 instruction
coding the actual CALL (or JMP for tail-calls) can be anywhere.

Now, static_call_site is PC32 encoded, that is:

	struct static_call_key *key =
		(void *)((unsigned long)&site->key + site->key);

And assuming &site->key is aligned, then site->key & 3 == key & 3.

Per the missing alignment for modules, the above went side-ways. The
patch in question fixed this by not relying on that and always computing
the absolute address first, then transfer the LSBs and then re-encoding
it.

Anyway, still good to also fix the alignment.

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-03-15 22:10 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-14 15:39 [GIT pull] locking/urgent for v5.12-rc3 Thomas Gleixner
2021-03-14 15:39 ` [GIT pull] objtool/urgent " Thomas Gleixner
2021-03-14 20:38   ` pr-tracker-bot
2021-03-14 15:39 ` [GIT pull] sched/urgent " Thomas Gleixner
2021-03-14 20:38   ` pr-tracker-bot
2021-03-14 15:40 ` [GIT pull] timers/urgent " Thomas Gleixner
2021-03-14 20:38   ` pr-tracker-bot
2021-03-14 15:40 ` [GIT pull] irq/urgent for v5.12-rc2 Thomas Gleixner
2021-03-14 20:38   ` pr-tracker-bot
2021-03-14 20:15 ` [GIT pull] locking/urgent for v5.12-rc3 Linus Torvalds
2021-03-15  8:33   ` Peter Zijlstra
2021-03-15 11:10     ` Peter Zijlstra
2021-03-15 11:26       ` Peter Zijlstra
2021-03-15 12:08         ` Peter Zijlstra
2021-03-15 13:31           ` Steven Rostedt
2021-03-15 17:03           ` Josh Poimboeuf
2021-03-15 17:43             ` Peter Zijlstra
2021-03-15 18:59             ` Linus Torvalds
2021-03-15 22:09               ` Peter Zijlstra
2021-03-14 20:38 ` pr-tracker-bot

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.