* [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] 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
* 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