Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36 |
|
#
5cd474e5 |
| 26-Jun-2023 |
D Scott Phillips <scott@os.amperecomputing.com> |
arm64: sdei: abort running SDEI handlers during crash
Interrupts are blocked in SDEI context, per the SDEI spec: "The client interrupts cannot preempt the event handler." If we crashed in the SDEI h
arm64: sdei: abort running SDEI handlers during crash
Interrupts are blocked in SDEI context, per the SDEI spec: "The client interrupts cannot preempt the event handler." If we crashed in the SDEI handler-running context (as with ACPI's AGDI) then we need to clean up the SDEI state before proceeding to the crash kernel so that the crash kernel can have working interrupts.
Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME the handler, discarding the interrupted context.
Fixes: f5df26961853 ("arm64: kernel: Add arch-specific SDEI entry code and CPU masking") Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com> Cc: stable@vger.kernel.org Reviewed-by: James Morse <james.morse@arm.com> Tested-by: Mihai Carabas <mihai.carabas@oracle.com> Link: https://lore.kernel.org/r/20230627002939.2758-1-scott@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2 |
|
#
d2c48b23 |
| 16-Feb-2023 |
Pierre Gondois <pierre.gondois@arm.com> |
firmware: arm_sdei: Fix sleep from invalid context BUG
Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra triggers:
BUG: sleeping function called from invalid context at kernel/l
firmware: arm_sdei: Fix sleep from invalid context BUG
Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra triggers:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [<ffffda301e85b7bc>] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [<ffffda301e80b184>] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20
sdei_cpuhp_up() is called in the STARTING hotplug section, which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entry instead to execute the cpuhp cb later, with preemption enabled.
SDEI originally got its own cpuhp slot to allow interacting with perf. It got superseded by pNMI and this early slot is not relevant anymore. [1]
Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on the calling CPU. It is checked that preemption is disabled for them. _ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'. Preemption is enabled in those threads, but their cpumask is limited to 1 CPU. Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cb don't trigger them.
Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI call which acts on the calling CPU.
[1]: https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/
Suggested-by: James Morse <james.morse@arm.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20230216084920.144064-1-pierre.gondois@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26 |
|
#
dc4e8c07 |
| 27-Feb-2022 |
Shuai Xue <xueshuai@linux.alibaba.com> |
ACPI: APEI: explicit init of HEST and GHES in apci_init()
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to m
ACPI: APEI: explicit init of HEST and GHES in apci_init()
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage the estatus memory pool. On the other hand, ghes_init() relies on sdei_init() to detect the SDEI version and (un)register events. The dependencies are as follows:
ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init() ghes_init() => sdei_init()
HEST is not PCI-specific and initcall ordering is implicit and not well-defined within a level.
Based on above, remove acpi_hest_init() from acpi_pci_root_init() and convert ghes_init() and sdei_init() from initcalls to explicit calls in the following order:
acpi_hest_init() ghes_init() sdei_init()
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
335852f7 |
| 27-Feb-2022 |
Shuai Xue <xueshuai@linux.alibaba.com> |
ACPI: APEI: explicit init of HEST and GHES in apci_init()
[ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory
ACPI: APEI: explicit init of HEST and GHES in apci_init()
[ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ]
From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage the estatus memory pool. On the other hand, ghes_init() relies on sdei_init() to detect the SDEI version and (un)register events. The dependencies are as follows:
ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init() ghes_init() => sdei_init()
HEST is not PCI-specific and initcall ordering is implicit and not well-defined within a level.
Based on above, remove acpi_hest_init() from acpi_pci_root_init() and convert ghes_init() and sdei_init() from initcalls to explicit calls in the following order:
acpi_hest_init() ghes_init() sdei_init()
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
a0ccf2ba |
| 02-Dec-2020 |
Mark Rutland <mark.rutland@arm.com> |
arm64: sdei: move uaccess logic to arch/arm64/
The SDEI support code is split across arch/arm64/ and drivers/firmware/, largley this is split so that the arch-specific portions are under arch/arm64,
arm64: sdei: move uaccess logic to arch/arm64/
The SDEI support code is split across arch/arm64/ and drivers/firmware/, largley this is split so that the arch-specific portions are under arch/arm64, and the management logic is under drivers/firmware/. However, exception entry fixups are currently under drivers/firmware.
Let's move the exception entry fixups under arch/arm64/. This de-clutters the management logic, and puts all the arch-specific portions in one place. Doing this also allows the fixups to be applied earlier, so things like PAN and UAO will be in a known good state before we run other logic. This will also make subsequent refactoring easier.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20201202131558.39270-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11 |
|
#
4b2b76cb |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove _sdei_event_unregister()
_sdei_event_unregister() is called by sdei_event_unregister() and sdei_device_freeze(). _sdei_event_unregister() covers the shared and private eve
firmware: arm_sdei: Remove _sdei_event_unregister()
_sdei_event_unregister() is called by sdei_event_unregister() and sdei_device_freeze(). _sdei_event_unregister() covers the shared and private events, but sdei_device_freeze() only covers the shared events. So the logic to cover the private events isn't needed by sdei_device_freeze().
sdei_event_unregister sdei_device_freeze _sdei_event_unregister sdei_unregister_shared _sdei_event_unregister
This removes _sdei_event_unregister(). Its logic is moved to its callers accordingly. This shouldn't cause any logical changes.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-14-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
d2fc580d |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove _sdei_event_register()
The function _sdei_event_register() is called by sdei_event_register() and sdei_device_thaw() as the following functional call chain shows. _sdei_ev
firmware: arm_sdei: Remove _sdei_event_register()
The function _sdei_event_register() is called by sdei_event_register() and sdei_device_thaw() as the following functional call chain shows. _sdei_event_register() covers the shared and private events, but sdei_device_thaw() only covers the shared events. So the logic to cover the private events in _sdei_event_register() isn't needed by sdei_device_thaw().
Similarly, sdei_reregister_event_llocked() covers the shared and private events in the regard of reenablement. The logic to cover the private events isn't needed by sdei_device_thaw() either.
sdei_event_register sdei_device_thaw _sdei_event_register sdei_reregister_shared sdei_reregister_event_llocked _sdei_event_register
This removes _sdei_event_register() and sdei_reregister_event_llocked(). Their logic is moved to sdei_event_register() and sdei_reregister_shared(). This shouldn't cause any logical changes.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-13-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
f4673625 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Introduce sdei_do_local_call()
During the CPU hotplug, the private events are registered, enabled or unregistered on the specific CPU. It repeats the same steps: initializing cro
firmware: arm_sdei: Introduce sdei_do_local_call()
During the CPU hotplug, the private events are registered, enabled or unregistered on the specific CPU. It repeats the same steps: initializing cross call argument, make function call on local CPU, check the returned error.
This introduces sdei_do_local_call() to cover the first steps. The other benefit is to make CROSSCALL_INIT and struct sdei_crosscall_args are only visible to sdei_do_{cross, local}_call().
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-12-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
a27c04e1 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Cleanup on cross call function
This applies cleanup on the cross call functions, no functional changes are introduced:
* Wrap the code block of CROSSCALL_INIT inside "do { }
firmware: arm_sdei: Cleanup on cross call function
This applies cleanup on the cross call functions, no functional changes are introduced:
* Wrap the code block of CROSSCALL_INIT inside "do { } while (0)" as linux kernel usually does. Otherwise, scripts/checkpatch.pl reports warning regarding this. * Use smp_call_func_t for @fn argument in sdei_do_cross_call() as the function is called on target CPU(s). * Remove unnecessary space before @event in sdei_do_cross_call()
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-11-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
b06146b6 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove while loop in sdei_event_unregister()
This removes the unnecessary while loop in sdei_event_unregister() because of the following two reasons. This shouldn't cause any fun
firmware: arm_sdei: Remove while loop in sdei_event_unregister()
This removes the unnecessary while loop in sdei_event_unregister() because of the following two reasons. This shouldn't cause any functional changes.
* The while loop is executed for once, meaning it's not needed in theory. * With the while loop removed, the nested statements can be avoid to make the code a bit cleaner.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200922130423.10173-10-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
1bbc7551 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove while loop in sdei_event_register()
This removes the unnecessary while loop in sdei_event_register() because of the following two reasons. This shouldn't cause any functio
firmware: arm_sdei: Remove while loop in sdei_event_register()
This removes the unnecessary while loop in sdei_event_register() because of the following two reasons. This shouldn't cause any functional changes.
* The while loop is executed for once, meaning it's not needed in theory. * With the while loop removed, the nested statements can be avoid to make the code a bit cleaner.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200922130423.10173-9-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
101119a3 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove redundant error message in sdei_probe()
This removes the redundant error message in sdei_probe() because the case can be identified from the errno in next error message.
firmware: arm_sdei: Remove redundant error message in sdei_probe()
This removes the redundant error message in sdei_probe() because the case can be identified from the errno in next error message.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-8-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
bc110fd3 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove duplicate check in sdei_get_conduit()
The following two checks are duplicate because @acpi_disabled doesn't depend on CONFIG_ACPI. So the duplicate check (IS_ENABLED(CONFI
firmware: arm_sdei: Remove duplicate check in sdei_get_conduit()
The following two checks are duplicate because @acpi_disabled doesn't depend on CONFIG_ACPI. So the duplicate check (IS_ENABLED(CONFIG_ACPI)) can be dropped. More details is provided to keep the commit log complete:
* @acpi_disabled is defined in arch/arm64/kernel/acpi.c when CONFIG_ACPI is enabled. * @acpi_disabled in defined in include/acpi.h when CONFIG_ACPI is disabled.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-7-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
63627cae |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Unregister driver on error in sdei_init()
The SDEI platform device is created from device-tree node or ACPI (SDEI) table. For the later case, the platform device is created expli
firmware: arm_sdei: Unregister driver on error in sdei_init()
The SDEI platform device is created from device-tree node or ACPI (SDEI) table. For the later case, the platform device is created explicitly by this module. It'd better to unregister the driver on failure to create the device to keep the symmetry. The driver, owned by this module, isn't needed if the device isn't existing.
Besides, the errno (@ret) should be updated accordingly in this case.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-6-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
10fd7c42 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Avoid nested statements in sdei_init()
In sdei_init(), the nested statements can be avoided by bailing on error from platform_driver_register() or absent ACPI SDEI table. With it
firmware: arm_sdei: Avoid nested statements in sdei_init()
In sdei_init(), the nested statements can be avoided by bailing on error from platform_driver_register() or absent ACPI SDEI table. With it, the code looks a bit more readable.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-5-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
663c0e89 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Retrieve event number from event instance
In sdei_event_create(), the event number is retrieved from the variable @event_num for the shared event. The event number was stored in
firmware: arm_sdei: Retrieve event number from event instance
In sdei_event_create(), the event number is retrieved from the variable @event_num for the shared event. The event number was stored in the event instance. So we can fetch it from the event instance, similar to what we're doing for the private event.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-4-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
11988424 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Common block for failing path in sdei_event_create()
There are multiple calls of kfree(event) in the failing path of sdei_event_create() to free the SDEI event. It means we need
firmware: arm_sdei: Common block for failing path in sdei_event_create()
There are multiple calls of kfree(event) in the failing path of sdei_event_create() to free the SDEI event. It means we need to call it again when adding more code in the failing path. It's prone to miss doing that and introduce memory leakage.
This introduces common block for failing path in sdei_event_create() to resolve the issue. This shouldn't cause functional changes.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200922130423.10173-3-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
5735f515 |
| 22-Sep-2020 |
Gavin Shan <gshan@redhat.com> |
firmware: arm_sdei: Remove sdei_is_err()
sdei_is_err() is only called by sdei_to_linux_errno(). The logic of checking on the error number is common to them. They can be combined finely.
This remove
firmware: arm_sdei: Remove sdei_is_err()
sdei_is_err() is only called by sdei_to_linux_errno(). The logic of checking on the error number is common to them. They can be combined finely.
This removes sdei_is_err() and its logic is combined to the function sdei_to_linux_errno(). Also, the assignment of @err to zero is also dropped in invoke_sdei_fn() because it's always overridden afterwards. This shouldn't cause functional changes.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: James Morse <james.morse@arm.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20200922130423.10173-2-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59 |
|
#
3d13f313 |
| 11-Aug-2020 |
Christoph Hellwig <hch@lst.de> |
uaccess: add force_uaccess_{begin,end} helpers
Add helpers to wrap the get_fs/set_fs magic for undoing any damange done by set_fs(KERNEL_DS). There is no real functional benefit, but this documents
uaccess: add force_uaccess_{begin,end} helpers
Add helpers to wrap the get_fs/set_fs magic for undoing any damange done by set_fs(KERNEL_DS). There is no real functional benefit, but this documents the intent of these calls better, and will allow stubbing the functions out easily for kernels builds that do not allow address space overrides in the future.
[hch@lst.de: drop two incorrect hunks, fix a commit log typo] Link: http://lkml.kernel.org/r/20200714105505.935079-6-hch@lst.de
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Greentime Hu <green.hu@gmail.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Nick Hu <nickhu@andestech.com> Cc: Vincent Chen <deanbo422@gmail.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Link: http://lkml.kernel.org/r/20200710135706.537715-6-hch@lst.de Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
472de63b |
| 19-May-2020 |
James Morse <james.morse@arm.com> |
firmware: arm_sdei: Document the motivation behind these set_fs() calls
The SDEI handler save/restores the addr_limit using set_fs(). It isn't very clear why. The reason is to mirror the arch code's
firmware: arm_sdei: Document the motivation behind these set_fs() calls
The SDEI handler save/restores the addr_limit using set_fs(). It isn't very clear why. The reason is to mirror the arch code's entry assembly. The arch code does this because perf may access user-space, and inheriting the addr_limit may be a problem.
Add a comment explaining why this is here.
Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Morse <james.morse@arm.com> Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822 Link: https://lore.kernel.org/r/20200519182108.13693-4-james.morse@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
82b2077a |
| 19-May-2020 |
Christoph Hellwig <hch@lst.de> |
firmware: arm_sdei: remove unused interfaces
The export symbols to register/unregister and enable/disable events aren't used upstream, remove them.
[ dropped the parts of Christoph's patch that mad
firmware: arm_sdei: remove unused interfaces
The export symbols to register/unregister and enable/disable events aren't used upstream, remove them.
[ dropped the parts of Christoph's patch that made the API static too ]
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/linux-arm-kernel/20200504164224.2842960-1-hch@lst.de/ Link: https://lore.kernel.org/r/20200519182108.13693-3-james.morse@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
#
70e6352a |
| 19-May-2020 |
Hanjun Guo <guohanjun@huawei.com> |
firmware: arm_sdei: Put the SDEI table after using it
The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used for runtime after the initialization to release the
firmware: arm_sdei: Put the SDEI table after using it
The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used for runtime after the initialization to release the table mapping, put the SDEI table after using it.
Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/linux-arm-kernel/1589021566-46373-1-git-send-email-guohanjun@huawei.com/ Link: https://lore.kernel.org/r/20200519182108.13693-2-james.morse@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35 |
|
#
caf2cd61 |
| 22-Apr-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_sdei: Drop check for /firmware/ node and always register driver
As with most of the drivers, let us register this driver unconditionally by dropping the checks for presence of firmware
firmware: arm_sdei: Drop check for /firmware/ node and always register driver
As with most of the drivers, let us register this driver unconditionally by dropping the checks for presence of firmware nodes(DT) or entries(ACPI).
Further, as mentioned in the commit acafce48b07b ("firmware: arm_sdei: Fix DT platform device creation"), the core takes care of creation of platform device when the appropriate device node is found and probe is called accordingly.
Let us check only for the presence of ACPI firmware entry before creating the platform device and flag warning if we fail.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Cc: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200422122823.1390-1-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
Revision tags: v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22 |
|
#
f7d5ef0c |
| 21-Feb-2020 |
Liguang Zhang <zhangliguang@linux.alibaba.com> |
firmware: arm_sdei: clean up sdei_event_create()
Function sdei_event_find() is always called in sdei_event_create(), but it is already called in sdei_event_register(). This code is trying to avoid a
firmware: arm_sdei: clean up sdei_event_create()
Function sdei_event_find() is always called in sdei_event_create(), but it is already called in sdei_event_register(). This code is trying to avoid a double-create of the same event, which can't happen as we still hold the sdei_events_lock. We can remove this needless sdei_event_find() call.
Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com> [expanded commit message] Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
#
54f529a6 |
| 21-Feb-2020 |
James Morse <james.morse@arm.com> |
firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhp
SDEI has private events that need registering and enabling on each CPU. CPUs can come and go while we are trying to do this. SDEI t
firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhp
SDEI has private events that need registering and enabling on each CPU. CPUs can come and go while we are trying to do this. SDEI tries to avoid these problems by setting the reregister flag before the register call, so any CPUs that come online register the event too. Sticking plaster like this doesn't work, as if the register call fails, a CPU that subsequently comes online will register the event before reregister is cleared.
Take cpus_read_lock() around the register and enable calls. We don't want surprise CPUs to do the wrong thing if they race with these calls failing.
Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|