On 26/02/2022 08:03, Kinsey Moore wrote:
On 2/26/2022 00:53, Sebastian Huber wrote:
On 26/02/2022 00:41, Kinsey Moore wrote:
This may also be an issue for ARM, RISC-V and others as it doesn't
appear that ARM saves CPSR during context switch and I couldn't tell
that RISC-V does this either, though I'm less familiar with it.
This doesn't look like the right way to fix this issue.
There is currently the assumption that all processors start
multitasking with a context switch to _Thread_Handler() which sets the
interrupt level. It is possible to construct a scenario in which we
start multitasking with a migration of a thread which already executed
the _Thread_Handler() prologue. This would result in an execution with
disabled interrupts. I think the proper fix for this scenario is to
enable interrupts in _CPU_SMP_Prepare_start_multitasking().
Doing a context switch with interrupts disabled is a fatal application
error on all architectures with
#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE
or enabled SMP support.
Ok, great. I was wondering if that was the case and this is definitely
the kind of feedback I was looking for. I'll adjust the patch set to
reflect that. I still wonder if this is an issue on other SMP CPU ports,
though, since most of them don't implement that hook, either.
I would like to have a closer look at this next week then I am back from
holidays.
Enabling interrupts in _CPU_SMP_Prepare_start_multitasking() would not
work since we use the interrupt stack at this point. We should add a
ticket and a test case for this (I can do this next week). How did you
observe this bug?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
