* [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() [not found] <20210810134127.1394269-1-valentin.schneider@arm.com> @ 2021-08-10 13:41 ` Valentin Schneider 2021-08-10 13:54 ` Sebastian Andrzej Siewior 2021-08-10 13:41 ` [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() Valentin Schneider 2021-08-10 13:41 ` [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping Valentin Schneider 2 siblings, 1 reply; 13+ messages in thread From: Valentin Schneider @ 2021-08-10 13:41 UTC (permalink / raw) To: linux-kernel, linux-rt-users Cc: Will Deacon, Mark Rutland, Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman [ 4.172817] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 [ 4.172820] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 19, name: cpuhp/0 [ 4.172822] 3 locks held by cpuhp/0/19: [ 4.172824] #0: ffff800011cf8690 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun (kernel/cpu.c:739) [ 4.172833] #1: ffff800011cf86e0 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun (kernel/cpu.c:739) [ 4.172838] #2: ffff008f36237c08 (&(&c->lock)->lock){+.+.}-{0:0}, at: ___slab_alloc (mm/slub.c:2872) [ 4.172844] irq event stamp: 40 [ 4.172845] hardirqs last enabled at (39): finish_task_switch (./arch/arm64/include/asm/irqflags.h:35 kernel/sched/sched.h:1319 kernel/sched/core.c:4531 kernel/sched/core.c:4649) [ 4.172849] hardirqs last disabled at (40): cpuhp_thread_fun (kernel/cpu.c:761 (discriminator 1)) [ 4.172851] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) [ 4.172855] softirqs last disabled at (0): 0x0 [ 4.172860] CPU: 0 PID: 19 Comm: cpuhp/0 Tainted: G W 5.14.0-rc4-rt6-torture+ #56 [ 4.172863] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.0 06/28/2019 [ 4.172864] Call trace: [ 4.172865] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) [ 4.172867] show_stack (arch/arm64/kernel/stacktrace.c:217) [ 4.172869] dump_stack_lvl (lib/dump_stack.c:106) [ 4.172872] dump_stack (lib/dump_stack.c:113) [ 4.172874] ___might_sleep (kernel/sched/core.c:9306) [ 4.172877] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) [ 4.172879] ___slab_alloc (mm/slub.c:2872) [ 4.172882] __slab_alloc.isra.0 (mm/slub.c:3038) [ 4.172884] kmem_cache_alloc_trace (mm/slub.c:3129 mm/slub.c:3171 mm/slub.c:3188) [ 4.172886] __armpmu_alloc (./include/linux/slab.h:591 ./include/linux/slab.h:721 drivers/perf/arm_pmu.c:869) [ 4.172889] armpmu_alloc_atomic (drivers/perf/arm_pmu.c:927) [ 4.172891] arm_pmu_acpi_cpu_starting (drivers/perf/arm_pmu_acpi.c:202 drivers/perf/arm_pmu_acpi.c:264) [ 4.172893] cpuhp_invoke_callback (kernel/cpu.c:180) [ 4.172895] cpuhp_thread_fun (kernel/cpu.c:762 (discriminator 3)) [ 4.172896] smpboot_thread_fn (kernel/smpboot.c:164 (discriminator 3)) [ 4.172900] kthread (kernel/kthread.c:327) [ 4.172902] ret_from_fork (arch/arm64/kernel/entry.S:783) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() 2021-08-10 13:41 ` [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() Valentin Schneider @ 2021-08-10 13:54 ` Sebastian Andrzej Siewior 2021-08-10 17:16 ` Thomas Gleixner 0 siblings, 1 reply; 13+ messages in thread From: Sebastian Andrzej Siewior @ 2021-08-10 13:54 UTC (permalink / raw) To: Valentin Schneider Cc: linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Marc Zyngier, Thomas Gleixner, Mel Gorman On 2021-08-10 14:41:25 [+0100], Valentin Schneider wrote: > [ 4.172817] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 Would it work to allocate the memory upfront and invoke the HP callback via smp_function_call()? That is implemented via the hp-callback. It is invoked after all CPUs are up. There is one "memory allocation" per "node". This does not change during runtime, right? Sebastian ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() 2021-08-10 13:54 ` Sebastian Andrzej Siewior @ 2021-08-10 17:16 ` Thomas Gleixner 2021-08-10 18:39 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 13+ messages in thread From: Thomas Gleixner @ 2021-08-10 17:16 UTC (permalink / raw) To: Sebastian Andrzej Siewior, Valentin Schneider Cc: linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Marc Zyngier, Mel Gorman On Tue, Aug 10 2021 at 15:54, Sebastian Andrzej Siewior wrote: > On 2021-08-10 14:41:25 [+0100], Valentin Schneider wrote: >> [ 4.172817] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 > > Would it work to allocate the memory upfront and invoke the HP callback > via smp_function_call()? Huch? If the memory is allocated during the prepare stage then the actual hotplug callback can just use it. So what's the SMP function call for? Thanks, tglx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() 2021-08-10 17:16 ` Thomas Gleixner @ 2021-08-10 18:39 ` Sebastian Andrzej Siewior 2021-08-10 19:56 ` Thomas Gleixner 0 siblings, 1 reply; 13+ messages in thread From: Sebastian Andrzej Siewior @ 2021-08-10 18:39 UTC (permalink / raw) To: Thomas Gleixner Cc: Valentin Schneider, linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Marc Zyngier, Mel Gorman On 2021-08-10 19:16:19 [+0200], Thomas Gleixner wrote: > On Tue, Aug 10 2021 at 15:54, Sebastian Andrzej Siewior wrote: > > On 2021-08-10 14:41:25 [+0100], Valentin Schneider wrote: > >> [ 4.172817] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 > > > > Would it work to allocate the memory upfront and invoke the HP callback > > via smp_function_call()? > > Huch? If the memory is allocated during the prepare stage then the > actual hotplug callback can just use it. So what's the SMP function call > for? You allocate the memory per-node (based on cpuid id) and you figure that out on the target CPU. That is the smp-function call for unless there another way to gather that information. That is done in arm_pmu_acpi_find_alloc_pmu() -> read_cpuid_id() > Thanks, > > tglx Sebastian ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() 2021-08-10 18:39 ` Sebastian Andrzej Siewior @ 2021-08-10 19:56 ` Thomas Gleixner 0 siblings, 0 replies; 13+ messages in thread From: Thomas Gleixner @ 2021-08-10 19:56 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: Valentin Schneider, linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Marc Zyngier, Mel Gorman On Tue, Aug 10 2021 at 20:39, Sebastian Andrzej Siewior wrote: > On 2021-08-10 19:16:19 [+0200], Thomas Gleixner wrote: >> On Tue, Aug 10 2021 at 15:54, Sebastian Andrzej Siewior wrote: >> > On 2021-08-10 14:41:25 [+0100], Valentin Schneider wrote: >> >> [ 4.172817] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 >> > >> > Would it work to allocate the memory upfront and invoke the HP callback >> > via smp_function_call()? >> >> Huch? If the memory is allocated during the prepare stage then the >> actual hotplug callback can just use it. So what's the SMP function call >> for? > > You allocate the memory per-node (based on cpuid id) and you figure that > out on the target CPU. That is the smp-function call for unless there > another way to gather that information. > That is done in > arm_pmu_acpi_find_alloc_pmu() -> read_cpuid_id() There is no SMP function call involved. This is straight CPU hotplug context on the upcoming CPU. You cannot allocate upfront on the control CPU and do an SMP function call to a not even started CPU. No idea what you are trying to do, but this is going nowhere. The reason why this atomic allocation is done is described in this commit: commit 0dc1a1851af1d593eee248b94c1277c7c7ccbbce Author: Mark Rutland <mark.rutland@arm.com> Date: Mon Feb 5 16:41:58 2018 +0000 arm_pmu: add armpmu_alloc_atomic() In ACPI systems, we don't know the makeup of CPUs until we hotplug them on, and thus have to allocate the PMU datastructures at hotplug time. Thus, we must use GFP_ATOMIC allocations. I have no idea why ACPI does not expose topology and PMU information in the first place, but do I really want to know? So the easy way out is to preallocate one PMU and use that preallocation when needed in the starting callback. Completely untested patch below. Note, that because I'm lazy this will waste one preallocated PMU at the end, but that's trivial enough to clean up. Thanks, tglx --- --- a/drivers/perf/arm_pmu.c +++ b/drivers/perf/arm_pmu.c @@ -861,12 +861,12 @@ static void cpu_pmu_destroy(struct arm_p &cpu_pmu->node); } -static struct arm_pmu *__armpmu_alloc(gfp_t flags) +struct arm_pmu *armpmu_alloc(void) { struct arm_pmu *pmu; int cpu; - pmu = kzalloc(sizeof(*pmu), flags); + pmu = kzalloc(sizeof(*pmu), GFP_KERNEL); if (!pmu) goto out; @@ -916,17 +916,6 @@ static struct arm_pmu *__armpmu_alloc(gf return NULL; } -struct arm_pmu *armpmu_alloc(void) -{ - return __armpmu_alloc(GFP_KERNEL); -} - -struct arm_pmu *armpmu_alloc_atomic(void) -{ - return __armpmu_alloc(GFP_ATOMIC); -} - - void armpmu_free(struct arm_pmu *pmu) { free_percpu(pmu->hw_events); --- a/drivers/perf/arm_pmu_acpi.c +++ b/drivers/perf/arm_pmu_acpi.c @@ -185,6 +185,8 @@ static int arm_pmu_acpi_parse_irqs(void) return err; } +static struct arm_pmu *arm_pmu_prealloced; + static struct arm_pmu *arm_pmu_acpi_find_alloc_pmu(void) { unsigned long cpuid = read_cpuid_id(); @@ -199,15 +201,9 @@ static struct arm_pmu *arm_pmu_acpi_find return pmu; } - pmu = armpmu_alloc_atomic(); - if (!pmu) { - pr_warn("Unable to allocate PMU for CPU%d\n", - smp_processor_id()); - return NULL; - } - + pmu = arm_pmu_prealloced; + arm_pmu_prealloced = NULL; pmu->acpi_cpuid = cpuid; - return pmu; } @@ -284,6 +280,19 @@ static int arm_pmu_acpi_cpu_starting(uns return 0; } +static int arm_pmu_acpi_cpu_prepare(unsigned int cpu) +{ + if (per_cpu(probed_pmus, cpu) || arm_pmu_prealloced) + return 0; + + arm_pmu_prealloced = armpmu_alloc(); + if (!arm_pmu_prealloced) { + pr_warn("Unable to allocate PMU for CPU%d\n", cpu); + return -ENOMEM; + } + return 0; +} + int arm_pmu_acpi_probe(armpmu_init_fn init_fn) { int pmu_idx = 0; @@ -338,7 +347,7 @@ int arm_pmu_acpi_probe(armpmu_init_fn in static int arm_pmu_acpi_init(void) { - int ret; + int ret, dynstate; if (acpi_disabled) return 0; @@ -349,9 +358,17 @@ static int arm_pmu_acpi_init(void) if (ret) return ret; + dynstate = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, + "perf/arm/pmu_acpi:prepare", + arm_pmu_acpi_cpu_prepare, NULL); + if (dynstate < 0) + return dynstate; + ret = cpuhp_setup_state(CPUHP_AP_PERF_ARM_ACPI_STARTING, "perf/arm/pmu_acpi:starting", arm_pmu_acpi_cpu_starting, NULL); + if (ret) + cpuhp_remove_state(dynstate); return ret; } --- a/include/linux/perf/arm_pmu.h +++ b/include/linux/perf/arm_pmu.h @@ -165,7 +165,6 @@ static inline int arm_pmu_acpi_probe(arm /* Internal functions only for core arm_pmu code */ struct arm_pmu *armpmu_alloc(void); -struct arm_pmu *armpmu_alloc_atomic(void); void armpmu_free(struct arm_pmu *pmu); int armpmu_register(struct arm_pmu *pmu); int armpmu_request_irq(int irq, int cpu); ^ permalink raw reply [flat|nested] 13+ messages in thread
* [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() [not found] <20210810134127.1394269-1-valentin.schneider@arm.com> 2021-08-10 13:41 ` [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() Valentin Schneider @ 2021-08-10 13:41 ` Valentin Schneider 2021-08-11 8:50 ` Marc Zyngier 2021-08-10 13:41 ` [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping Valentin Schneider 2 siblings, 1 reply; 13+ messages in thread From: Valentin Schneider @ 2021-08-10 13:41 UTC (permalink / raw) To: linux-kernel, linux-rt-users Cc: Will Deacon, Mark Rutland, Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman [ 0.134518] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 [ 0.134520] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/1 [ 0.134522] 1 lock held by swapper/1/0: [ 0.134523] #0: ffff008f3624f728 ((lock).lock){+.+.}-{2:2}, at: get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) [ 0.134533] irq event stamp: 0 [ 0.134534] hardirqs last enabled at (0): 0x0 [ 0.134538] hardirqs last disabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) [ 0.134542] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) [ 0.134545] softirqs last disabled at (0): 0x0 [ 0.134547] Preemption disabled at: [ 0.134547] rt_mutex_slowunlock (kernel/locking/rtmutex.c:1223) [ 0.134552] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-rc4-rt6-torture+ #56 [ 0.134555] Call trace: [ 0.134556] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) [ 0.134558] show_stack (arch/arm64/kernel/stacktrace.c:217) [ 0.134559] dump_stack_lvl (lib/dump_stack.c:106) [ 0.134563] dump_stack (lib/dump_stack.c:113) [ 0.134565] ___might_sleep (kernel/sched/core.c:9306) [ 0.134567] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) [ 0.134569] get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) [ 0.134571] __alloc_pages (mm/page_alloc.c:5391) [ 0.134573] alloc_page_interleave (mm/mempolicy.c:2119) [ 0.134576] alloc_pages (mm/mempolicy.c:2249) [ 0.134577] new_slab (mm/slub.c:1740 mm/slub.c:1877 mm/slub.c:1940) [ 0.134580] ___slab_alloc (mm/slub.c:2951) [ 0.134582] __slab_alloc.isra.0 (mm/slub.c:3038) [ 0.134584] kmem_cache_alloc_trace (mm/slub.c:3129 mm/slub.c:3171 mm/slub.c:3188) [ 0.134587] efi_mem_reserve_iomem (drivers/firmware/efi/efi.c:905) [ 0.134590] efi_mem_reserve_persistent (drivers/firmware/efi/efi.c:952) [ 0.134593] its_cpu_init (drivers/irqchip/irq-gic-v3-its.c:3074 drivers/irqchip/irq-gic-v3-its.c:5196) [ 0.134596] gic_starting_cpu (drivers/irqchip/irq-gic.c:798) [ 0.134599] cpuhp_invoke_callback (kernel/cpu.c:180) [ 0.134601] cpuhp_invoke_callback_range (kernel/cpu.c:656) [ 0.134603] notify_cpu_starting (kernel/cpu.c:1270) [ 0.134605] secondary_start_kernel (arch/arm64/kernel/smp.c:243) [ 0.134608] __secondary_switched (arch/arm64/kernel/head.S:661) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() 2021-08-10 13:41 ` [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() Valentin Schneider @ 2021-08-11 8:50 ` Marc Zyngier 2021-08-11 12:28 ` Thomas Gleixner 2021-08-17 15:16 ` Ard Biesheuvel 0 siblings, 2 replies; 13+ messages in thread From: Marc Zyngier @ 2021-08-11 8:50 UTC (permalink / raw) To: Valentin Schneider Cc: linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman, Ard Biesheuvel [+ Ard] On Tue, 10 Aug 2021 14:41:26 +0100, Valentin Schneider <valentin.schneider@arm.com> wrote: > > [ 0.134518] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 > [ 0.134520] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/1 > [ 0.134522] 1 lock held by swapper/1/0: > [ 0.134523] #0: ffff008f3624f728 ((lock).lock){+.+.}-{2:2}, at: get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) > [ 0.134533] irq event stamp: 0 > [ 0.134534] hardirqs last enabled at (0): 0x0 > [ 0.134538] hardirqs last disabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) > [ 0.134542] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) > [ 0.134545] softirqs last disabled at (0): 0x0 > [ 0.134547] Preemption disabled at: > [ 0.134547] rt_mutex_slowunlock (kernel/locking/rtmutex.c:1223) > [ 0.134552] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-rc4-rt6-torture+ #56 > [ 0.134555] Call trace: > [ 0.134556] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) > [ 0.134558] show_stack (arch/arm64/kernel/stacktrace.c:217) > [ 0.134559] dump_stack_lvl (lib/dump_stack.c:106) > [ 0.134563] dump_stack (lib/dump_stack.c:113) > [ 0.134565] ___might_sleep (kernel/sched/core.c:9306) > [ 0.134567] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) > [ 0.134569] get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) > [ 0.134571] __alloc_pages (mm/page_alloc.c:5391) > [ 0.134573] alloc_page_interleave (mm/mempolicy.c:2119) > [ 0.134576] alloc_pages (mm/mempolicy.c:2249) > [ 0.134577] new_slab (mm/slub.c:1740 mm/slub.c:1877 mm/slub.c:1940) > [ 0.134580] ___slab_alloc (mm/slub.c:2951) > [ 0.134582] __slab_alloc.isra.0 (mm/slub.c:3038) > [ 0.134584] kmem_cache_alloc_trace (mm/slub.c:3129 mm/slub.c:3171 mm/slub.c:3188) > [ 0.134587] efi_mem_reserve_iomem (drivers/firmware/efi/efi.c:905) > [ 0.134590] efi_mem_reserve_persistent (drivers/firmware/efi/efi.c:952) > [ 0.134593] its_cpu_init (drivers/irqchip/irq-gic-v3-its.c:3074 drivers/irqchip/irq-gic-v3-its.c:5196) > [ 0.134596] gic_starting_cpu (drivers/irqchip/irq-gic.c:798) > [ 0.134599] cpuhp_invoke_callback (kernel/cpu.c:180) > [ 0.134601] cpuhp_invoke_callback_range (kernel/cpu.c:656) > [ 0.134603] notify_cpu_starting (kernel/cpu.c:1270) > [ 0.134605] secondary_start_kernel (arch/arm64/kernel/smp.c:243) > [ 0.134608] __secondary_switched (arch/arm64/kernel/head.S:661) The issue is that although the redistributor tables have been allocated ahead of time (outside of any cpuhp callback), they cannot be programmed into the RDs until the corresponding CPUs have been brought up (the registers may not be accessible). For the same reason, we don't know whether we can free them (because there is already a table programmed there) or have to reserve them with an efi_mem_reserve_persistent() call. efi_mem_reserve_iomem() uses GFP_ATOMIC for its allocation, but this is not sufficient for RT anymore. We could postpone the reservation of the memory to a later point (it is only useful for kexec), but it isn't clear where that point is. The CPU is not quite up yet, and we can't easily IPI the boot CPU to do the reserve call. M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() 2021-08-11 8:50 ` Marc Zyngier @ 2021-08-11 12:28 ` Thomas Gleixner 2021-08-11 15:14 ` Marc Zyngier 2021-08-17 15:16 ` Ard Biesheuvel 1 sibling, 1 reply; 13+ messages in thread From: Thomas Gleixner @ 2021-08-11 12:28 UTC (permalink / raw) To: Marc Zyngier, Valentin Schneider Cc: linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Sebastian Andrzej Siewior, Mel Gorman, Ard Biesheuvel On Wed, Aug 11 2021 at 09:50, Marc Zyngier wrote: > On Tue, 10 Aug 2021 14:41:26 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: > The issue is that although the redistributor tables have been > allocated ahead of time (outside of any cpuhp callback), they cannot > be programmed into the RDs until the corresponding CPUs have been > brought up (the registers may not be accessible). > > For the same reason, we don't know whether we can free them (because > there is already a table programmed there) or have to reserve them > with an efi_mem_reserve_persistent() call. efi_mem_reserve_iomem() > uses GFP_ATOMIC for its allocation, but this is not sufficient for RT > anymore. > > We could postpone the reservation of the memory to a later point (it > is only useful for kexec), but it isn't clear where that point is. The > CPU is not quite up yet, and we can't easily IPI the boot CPU to do > the reserve call. Right, but don't you know about the need for reservation _before_ bringing the CPU up? Thanks, tglx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() 2021-08-11 12:28 ` Thomas Gleixner @ 2021-08-11 15:14 ` Marc Zyngier 0 siblings, 0 replies; 13+ messages in thread From: Marc Zyngier @ 2021-08-11 15:14 UTC (permalink / raw) To: Thomas Gleixner Cc: Valentin Schneider, linux-kernel, linux-rt-users, Will Deacon, Mark Rutland, Sebastian Andrzej Siewior, Mel Gorman, Ard Biesheuvel On Wed, 11 Aug 2021 13:28:21 +0100, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Wed, Aug 11 2021 at 09:50, Marc Zyngier wrote: > > On Tue, 10 Aug 2021 14:41:26 +0100, > > Valentin Schneider <valentin.schneider@arm.com> wrote: > > The issue is that although the redistributor tables have been > > allocated ahead of time (outside of any cpuhp callback), they cannot > > be programmed into the RDs until the corresponding CPUs have been > > brought up (the registers may not be accessible). > > > > For the same reason, we don't know whether we can free them (because > > there is already a table programmed there) or have to reserve them > > with an efi_mem_reserve_persistent() call. efi_mem_reserve_iomem() > > uses GFP_ATOMIC for its allocation, but this is not sufficient for RT > > anymore. > > > > We could postpone the reservation of the memory to a later point (it > > is only useful for kexec), but it isn't clear where that point is. The > > CPU is not quite up yet, and we can't easily IPI the boot CPU to do > > the reserve call. > > Right, but don't you know about the need for reservation _before_ > bringing the CPU up? Unfortunately not. To find out, you need to access a pair of per-CPU registers which are not guaranteed to be powered-on until the corresponding CPU has made it into the kernel (the firmware will power things on as part of bringing the CPU up). Which is why we always allocate the memory upfront for all the CPUs, and each CPU either frees the memory if it already had something in its redistributor, or point the redistributor to the memory and reserves it. This is probably the most epic fail of the GICv3 architecture... Thanks, M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() 2021-08-11 8:50 ` Marc Zyngier 2021-08-11 12:28 ` Thomas Gleixner @ 2021-08-17 15:16 ` Ard Biesheuvel 1 sibling, 0 replies; 13+ messages in thread From: Ard Biesheuvel @ 2021-08-17 15:16 UTC (permalink / raw) To: Marc Zyngier Cc: Valentin Schneider, Linux Kernel Mailing List, linux-rt-users, Will Deacon, Mark Rutland, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman On Wed, 11 Aug 2021 at 10:50, Marc Zyngier <maz@kernel.org> wrote: > > [+ Ard] > > On Tue, 10 Aug 2021 14:41:26 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: > > > > [ 0.134518] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 > > [ 0.134520] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/1 > > [ 0.134522] 1 lock held by swapper/1/0: > > [ 0.134523] #0: ffff008f3624f728 ((lock).lock){+.+.}-{2:2}, at: get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) > > [ 0.134533] irq event stamp: 0 > > [ 0.134534] hardirqs last enabled at (0): 0x0 > > [ 0.134538] hardirqs last disabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) > > [ 0.134542] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) > > [ 0.134545] softirqs last disabled at (0): 0x0 > > [ 0.134547] Preemption disabled at: > > [ 0.134547] rt_mutex_slowunlock (kernel/locking/rtmutex.c:1223) > > [ 0.134552] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.14.0-rc4-rt6-torture+ #56 > > [ 0.134555] Call trace: > > [ 0.134556] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) > > [ 0.134558] show_stack (arch/arm64/kernel/stacktrace.c:217) > > [ 0.134559] dump_stack_lvl (lib/dump_stack.c:106) > > [ 0.134563] dump_stack (lib/dump_stack.c:113) > > [ 0.134565] ___might_sleep (kernel/sched/core.c:9306) > > [ 0.134567] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) > > [ 0.134569] get_page_from_freelist (mm/page_alloc.c:3673 mm/page_alloc.c:3704 mm/page_alloc.c:4166) > > [ 0.134571] __alloc_pages (mm/page_alloc.c:5391) > > [ 0.134573] alloc_page_interleave (mm/mempolicy.c:2119) > > [ 0.134576] alloc_pages (mm/mempolicy.c:2249) > > [ 0.134577] new_slab (mm/slub.c:1740 mm/slub.c:1877 mm/slub.c:1940) > > [ 0.134580] ___slab_alloc (mm/slub.c:2951) > > [ 0.134582] __slab_alloc.isra.0 (mm/slub.c:3038) > > [ 0.134584] kmem_cache_alloc_trace (mm/slub.c:3129 mm/slub.c:3171 mm/slub.c:3188) > > [ 0.134587] efi_mem_reserve_iomem (drivers/firmware/efi/efi.c:905) > > [ 0.134590] efi_mem_reserve_persistent (drivers/firmware/efi/efi.c:952) > > [ 0.134593] its_cpu_init (drivers/irqchip/irq-gic-v3-its.c:3074 drivers/irqchip/irq-gic-v3-its.c:5196) > > [ 0.134596] gic_starting_cpu (drivers/irqchip/irq-gic.c:798) > > [ 0.134599] cpuhp_invoke_callback (kernel/cpu.c:180) > > [ 0.134601] cpuhp_invoke_callback_range (kernel/cpu.c:656) > > [ 0.134603] notify_cpu_starting (kernel/cpu.c:1270) > > [ 0.134605] secondary_start_kernel (arch/arm64/kernel/smp.c:243) > > [ 0.134608] __secondary_switched (arch/arm64/kernel/head.S:661) > > The issue is that although the redistributor tables have been > allocated ahead of time (outside of any cpuhp callback), they cannot > be programmed into the RDs until the corresponding CPUs have been > brought up (the registers may not be accessible). > > For the same reason, we don't know whether we can free them (because > there is already a table programmed there) or have to reserve them > with an efi_mem_reserve_persistent() call. efi_mem_reserve_iomem() > uses GFP_ATOMIC for its allocation, but this is not sufficient for RT > anymore. > > We could postpone the reservation of the memory to a later point (it > is only useful for kexec), but it isn't clear where that point is. The > CPU is not quite up yet, and we can't easily IPI the boot CPU to do > the reserve call. > The kzalloc() call in question is used to allocate the struct resource which is inserted in to the iomem resource tree. This could definitely be postponed, given that the kernel itself does not care about these entries, only user space (IIUC) ^ permalink raw reply [flat|nested] 13+ messages in thread
* [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping [not found] <20210810134127.1394269-1-valentin.schneider@arm.com> 2021-08-10 13:41 ` [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() Valentin Schneider 2021-08-10 13:41 ` [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() Valentin Schneider @ 2021-08-10 13:41 ` Valentin Schneider 2021-08-10 20:33 ` Thomas Gleixner 2021-08-11 10:52 ` Andy Shevchenko 2 siblings, 2 replies; 13+ messages in thread From: Valentin Schneider @ 2021-08-10 13:41 UTC (permalink / raw) To: linux-kernel, linux-rt-users Cc: Will Deacon, Mark Rutland, Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman [ 11.549741] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 [ 11.549745] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 553, name: systemd-udevd [ 11.549747] 4 locks held by systemd-udevd/553: [ 11.549749] #0: ffff00080338b168 (&dev->mutex){....}-{0:0}, at: __device_driver_lock (drivers/base/dd.c:1029) [ 11.549760] #1: ffff800011df0780 (irq_domain_mutex){+.+.}-{3:3}, at: irq_domain_associate (kernel/irq/irqdomain.c:576) [ 11.549769] #2: ffff0008112a6900 (lock_class){....}-{2:2}, at: __irq_get_desc_lock (kernel/irq/irqdesc.c:857) [ 11.549775] #3: ffff0008112a59c8 (&gc->bgpio_lock){+.+.}-{0:0}, at: dwapb_irq_ack (drivers/gpio/gpio-dwapb.c:151 drivers/gpio/gpio-dwapb.c:233) gpio_dwapb [ 11.549783] irq event stamp: 157476 [ 11.549785] hardirqs last enabled at (157475): _raw_spin_unlock_irqrestore (./include/linux/spinlock_api_smp.h:160 kernel/locking/spinlock.c:194) [ 11.549790] hardirqs last disabled at (157476): _raw_spin_lock_irqsave (./include/linux/spinlock_api_smp.h:108 kernel/locking/spinlock.c:162) [ 11.549793] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) [ 11.549797] softirqs last disabled at (0): 0x0 [ 11.549801] Preemption disabled at: [ 11.549802] __irq_get_desc_lock (kernel/irq/irqdesc.c:857) [ 11.549806] CPU: 22 PID: 553 Comm: systemd-udevd Tainted: G W 5.14.0-rc4-rt6-torture+ #56 [ 11.549808] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.0 06/28/2019 [ 11.549810] Call trace: [ 11.549811] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) [ 11.549814] show_stack (arch/arm64/kernel/stacktrace.c:217) [ 11.549815] dump_stack_lvl (lib/dump_stack.c:106) [ 11.549819] dump_stack (lib/dump_stack.c:113) [ 11.549821] ___might_sleep (kernel/sched/core.c:9306) [ 11.549824] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) [ 11.549827] dwapb_irq_ack (drivers/gpio/gpio-dwapb.c:151 drivers/gpio/gpio-dwapb.c:233) gpio_dwapb [ 11.549831] __irq_do_set_handler (kernel/irq/chip.c:414 kernel/irq/chip.c:406 kernel/irq/chip.c:1009) [ 11.549833] __irq_set_handler (kernel/irq/internals.h:178 kernel/irq/chip.c:1053) [ 11.549836] irq_set_chip_and_handler_name (kernel/irq/chip.c:1080) [ 11.549838] gpiochip_irq_map (drivers/gpio/gpiolib.c:1262) [ 11.549842] irq_domain_associate (kernel/irq/irqdomain.c:579) [ 11.549845] irq_create_mapping_affinity (kernel/irq/irqdomain.c:716) [ 11.549848] gpiochip_to_irq (drivers/gpio/gpiolib.c:1365) [ 11.549851] gpiod_to_irq (drivers/gpio/gpiolib.c:3082) [ 11.549853] acpi_gpiochip_alloc_event (drivers/gpio/gpiolib-acpi.c:422) [ 11.549856] acpi_walk_resource_buffer (drivers/acpi/acpica/rsxface.c:548) [ 11.549859] acpi_walk_resources (drivers/acpi/acpica/rsxface.c:623 drivers/acpi/acpica/rsxface.c:594) [ 11.549862] acpi_gpiochip_request_interrupts (drivers/gpio/gpiolib-acpi.c:505) [ 11.549864] gpiochip_add_data_with_key (drivers/gpio/gpiolib.c:748) [ 11.549867] devm_gpiochip_add_data_with_key (drivers/gpio/gpiolib-devres.c:510) [ 11.549869] dwapb_gpio_probe (drivers/gpio/gpio-dwapb.c:517 drivers/gpio/gpio-dwapb.c:712) gpio_dwapb [ 11.549873] platform_probe (drivers/base/platform.c:1428) [ 11.549876] really_probe (drivers/base/dd.c:517 drivers/base/dd.c:595 drivers/base/dd.c:541) [ 11.549877] __driver_probe_device (drivers/base/dd.c:747) [ 11.549879] driver_probe_device (drivers/base/dd.c:777) [ 11.549881] __driver_attach (drivers/base/dd.c:1137) [ 11.549883] bus_for_each_dev (drivers/base/bus.c:301) [ 11.549885] driver_attach (drivers/base/dd.c:1154) [ 11.549887] bus_add_driver (drivers/base/bus.c:619) [ 11.549888] driver_register (drivers/base/driver.c:171) [ 11.549890] __platform_driver_register (drivers/base/platform.c:875) [ 11.549893] dwapb_gpio_driver_init (drivers/gpio/gpio-dwapb.c:343) gpio_dwapb [ 11.549897] do_one_initcall (init/main.c:1282) [ 11.549900] do_init_module (kernel/module.c:3690) [ 11.549904] load_module (kernel/module.c:4091) [ 11.549906] __do_sys_finit_module (kernel/module.c:4182) [ 11.549909] __arm64_sys_finit_module (kernel/module.c:4159) [ 11.549911] invoke_syscall (./arch/arm64/include/asm/current.h:19 ./arch/arm64/include/asm/compat.h:183 arch/arm64/kernel/syscall.c:57) [ 11.549914] el0_svc_common (./arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/syscall.c:153) [ 11.549917] do_el0_svc (arch/arm64/kernel/syscall.c:185) [ 11.549919] el0_svc (arch/arm64/kernel/entry-common.c:512) [ 11.549922] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:528) [ 11.549924] el0t_64_sync (arch/arm64/kernel/entry.S:574) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping 2021-08-10 13:41 ` [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping Valentin Schneider @ 2021-08-10 20:33 ` Thomas Gleixner 2021-08-11 10:52 ` Andy Shevchenko 1 sibling, 0 replies; 13+ messages in thread From: Thomas Gleixner @ 2021-08-10 20:33 UTC (permalink / raw) To: Valentin Schneider, linux-kernel, linux-rt-users Cc: Will Deacon, Mark Rutland, Marc Zyngier, Sebastian Andrzej Siewior, Mel Gorman, Linus Walleij, Bartosz Golaszewski, linux-gpio On Tue, Aug 10 2021 at 14:41, Valentin Schneider wrote: > [ 11.549824] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) > [ 11.549827] dwapb_irq_ack (drivers/gpio/gpio-dwapb.c:151 drivers/gpio/gpio-dwapb.c:233) gpio_dwapb > [ 11.549831] __irq_do_set_handler (kernel/irq/chip.c:414 kernel/irq/chip.c:406 kernel/irq/chip.c:1009) > [ 11.549833] __irq_set_handler (kernel/irq/internals.h:178 kernel/irq/chip.c:1053) This is gpio_chip->bgpio_lock which is a regular spinlock. AFAICT this lock should merely serializing access to MMIO registers, so it should not be a problem to make this lock raw. Except for the obligatory exception: grgpio_irq_handler() holds that lock from the demultiplexing handler and invokes all handlers for the individual GPIOs which have interrupts enabled without ever consulting a pending register. That drivers usage of that lock is interesting in general, see grgpio_map_irq() for illustration. Quality stuff for mission critical systems... But nevertheless it should just work with a raw lock on RT AFACIT. Thanks, tglx ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping 2021-08-10 13:41 ` [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping Valentin Schneider 2021-08-10 20:33 ` Thomas Gleixner @ 2021-08-11 10:52 ` Andy Shevchenko 1 sibling, 0 replies; 13+ messages in thread From: Andy Shevchenko @ 2021-08-11 10:52 UTC (permalink / raw) To: Valentin Schneider, Serge Semin Cc: Linux Kernel Mailing List, linux-rt-users, Will Deacon, Mark Rutland, Marc Zyngier, Thomas Gleixner, Sebastian Andrzej Siewior, Mel Gorman +Cc: Serge, maintainer of the driver On Tue, Aug 10, 2021 at 7:34 PM Valentin Schneider <valentin.schneider@arm.com> wrote: > > [ 11.549741] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35 > [ 11.549745] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 553, name: systemd-udevd > [ 11.549747] 4 locks held by systemd-udevd/553: > [ 11.549749] #0: ffff00080338b168 (&dev->mutex){....}-{0:0}, at: __device_driver_lock (drivers/base/dd.c:1029) > [ 11.549760] #1: ffff800011df0780 (irq_domain_mutex){+.+.}-{3:3}, at: irq_domain_associate (kernel/irq/irqdomain.c:576) > [ 11.549769] #2: ffff0008112a6900 (lock_class){....}-{2:2}, at: __irq_get_desc_lock (kernel/irq/irqdesc.c:857) > [ 11.549775] #3: ffff0008112a59c8 (&gc->bgpio_lock){+.+.}-{0:0}, at: dwapb_irq_ack (drivers/gpio/gpio-dwapb.c:151 drivers/gpio/gpio-dwapb.c:233) gpio_dwapb > [ 11.549783] irq event stamp: 157476 > [ 11.549785] hardirqs last enabled at (157475): _raw_spin_unlock_irqrestore (./include/linux/spinlock_api_smp.h:160 kernel/locking/spinlock.c:194) > [ 11.549790] hardirqs last disabled at (157476): _raw_spin_lock_irqsave (./include/linux/spinlock_api_smp.h:108 kernel/locking/spinlock.c:162) > [ 11.549793] softirqs last enabled at (0): copy_process (./include/linux/lockdep.h:195 ./include/linux/lockdep.h:202 ./include/linux/lockdep.h:208 ./include/linux/seqlock.h:78 kernel/fork.c:2084) > [ 11.549797] softirqs last disabled at (0): 0x0 > [ 11.549801] Preemption disabled at: > [ 11.549802] __irq_get_desc_lock (kernel/irq/irqdesc.c:857) > [ 11.549806] CPU: 22 PID: 553 Comm: systemd-udevd Tainted: G W 5.14.0-rc4-rt6-torture+ #56 > [ 11.549808] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 1.0 06/28/2019 > [ 11.549810] Call trace: > [ 11.549811] dump_backtrace (arch/arm64/kernel/stacktrace.c:151) > [ 11.549814] show_stack (arch/arm64/kernel/stacktrace.c:217) > [ 11.549815] dump_stack_lvl (lib/dump_stack.c:106) > [ 11.549819] dump_stack (lib/dump_stack.c:113) > [ 11.549821] ___might_sleep (kernel/sched/core.c:9306) > [ 11.549824] rt_spin_lock (kernel/locking/rtmutex.c:1641 (discriminator 4) kernel/locking/spinlock_rt.c:30 (discriminator 4) kernel/locking/spinlock_rt.c:36 (discriminator 4) kernel/locking/spinlock_rt.c:44 (discriminator 4)) > [ 11.549827] dwapb_irq_ack (drivers/gpio/gpio-dwapb.c:151 drivers/gpio/gpio-dwapb.c:233) gpio_dwapb > [ 11.549831] __irq_do_set_handler (kernel/irq/chip.c:414 kernel/irq/chip.c:406 kernel/irq/chip.c:1009) > [ 11.549833] __irq_set_handler (kernel/irq/internals.h:178 kernel/irq/chip.c:1053) > [ 11.549836] irq_set_chip_and_handler_name (kernel/irq/chip.c:1080) > [ 11.549838] gpiochip_irq_map (drivers/gpio/gpiolib.c:1262) > [ 11.549842] irq_domain_associate (kernel/irq/irqdomain.c:579) > [ 11.549845] irq_create_mapping_affinity (kernel/irq/irqdomain.c:716) > [ 11.549848] gpiochip_to_irq (drivers/gpio/gpiolib.c:1365) > [ 11.549851] gpiod_to_irq (drivers/gpio/gpiolib.c:3082) > [ 11.549853] acpi_gpiochip_alloc_event (drivers/gpio/gpiolib-acpi.c:422) > [ 11.549856] acpi_walk_resource_buffer (drivers/acpi/acpica/rsxface.c:548) > [ 11.549859] acpi_walk_resources (drivers/acpi/acpica/rsxface.c:623 drivers/acpi/acpica/rsxface.c:594) > [ 11.549862] acpi_gpiochip_request_interrupts (drivers/gpio/gpiolib-acpi.c:505) > [ 11.549864] gpiochip_add_data_with_key (drivers/gpio/gpiolib.c:748) > [ 11.549867] devm_gpiochip_add_data_with_key (drivers/gpio/gpiolib-devres.c:510) > [ 11.549869] dwapb_gpio_probe (drivers/gpio/gpio-dwapb.c:517 drivers/gpio/gpio-dwapb.c:712) gpio_dwapb > [ 11.549873] platform_probe (drivers/base/platform.c:1428) > [ 11.549876] really_probe (drivers/base/dd.c:517 drivers/base/dd.c:595 drivers/base/dd.c:541) > [ 11.549877] __driver_probe_device (drivers/base/dd.c:747) > [ 11.549879] driver_probe_device (drivers/base/dd.c:777) > [ 11.549881] __driver_attach (drivers/base/dd.c:1137) > [ 11.549883] bus_for_each_dev (drivers/base/bus.c:301) > [ 11.549885] driver_attach (drivers/base/dd.c:1154) > [ 11.549887] bus_add_driver (drivers/base/bus.c:619) > [ 11.549888] driver_register (drivers/base/driver.c:171) > [ 11.549890] __platform_driver_register (drivers/base/platform.c:875) > [ 11.549893] dwapb_gpio_driver_init (drivers/gpio/gpio-dwapb.c:343) gpio_dwapb > [ 11.549897] do_one_initcall (init/main.c:1282) > [ 11.549900] do_init_module (kernel/module.c:3690) > [ 11.549904] load_module (kernel/module.c:4091) > [ 11.549906] __do_sys_finit_module (kernel/module.c:4182) > [ 11.549909] __arm64_sys_finit_module (kernel/module.c:4159) > [ 11.549911] invoke_syscall (./arch/arm64/include/asm/current.h:19 ./arch/arm64/include/asm/compat.h:183 arch/arm64/kernel/syscall.c:57) > [ 11.549914] el0_svc_common (./arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/syscall.c:153) > [ 11.549917] do_el0_svc (arch/arm64/kernel/syscall.c:185) > [ 11.549919] el0_svc (arch/arm64/kernel/entry-common.c:512) > [ 11.549922] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:528) > [ 11.549924] el0t_64_sync (arch/arm64/kernel/entry.S:574) As Thomas said already the usual fix for GPIO drivers is to switch to the raw version of spin locks. See other drivers for the example of such conversion (yet, the IRQ handler cases might be needing the additional care). -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-08-17 15:17 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210810134127.1394269-1-valentin.schneider@arm.com>
2021-08-10 13:41 ` [SPLAT 1/3] arm_pmu: Sleeping spinlocks down armpmu_alloc_atomic() Valentin Schneider
2021-08-10 13:54 ` Sebastian Andrzej Siewior
2021-08-10 17:16 ` Thomas Gleixner
2021-08-10 18:39 ` Sebastian Andrzej Siewior
2021-08-10 19:56 ` Thomas Gleixner
2021-08-10 13:41 ` [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() Valentin Schneider
2021-08-11 8:50 ` Marc Zyngier
2021-08-11 12:28 ` Thomas Gleixner
2021-08-11 15:14 ` Marc Zyngier
2021-08-17 15:16 ` Ard Biesheuvel
2021-08-10 13:41 ` [SPLAT 3/3] gpio: dwapb: Sleeping spinlocks down IRQ mapping Valentin Schneider
2021-08-10 20:33 ` Thomas Gleixner
2021-08-11 10:52 ` Andy Shevchenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox