Fix lockup when attempting to load a l0dable with disabled ELF loading (!445) · Merge requests · card10 / firmware

Merged rahix requested to merge rahix/l0dable-lockup into master 4 years ago

Jan 13, 2021

feat(lifecycle): Return to menu if loading failed · 9207eeed

rahix authored 4 years ago

If an asynchronous load fails, return to the menu instead of leaving
card10 in a state where no app is running.

Ref: #228

9207eeed

fix(lifecycle): Don't reset core1 for disallowed ELF loading attempt · f1b764aa

rahix authored 4 years ago

If ELF loading is disabled, return from do_load() early, before
performing a reset of core1 and resetting drivers.

f1b764aa

fix(core1-control): Free semaphore between ready waiting and loading · 6db60457

rahix authored 4 years ago

Up to now, the semaphore was locked in core1_wait_ready() and later
freed in core1_load().  This is problematic when only core1_wait_ready()
is called (e.g. due to an invalid payload).

Instead, free the semaphore before leaving core1_wait_ready() and
reaquire it in core1_load().  This way an incorrect call sequence cannot
lead to a lockup.

Ref: #228

6db60457

Jan 12, 2021

chore(lifecycle): Make it more explicit where core1_mutex needs to be locked · 685985d6

rahix authored 4 years ago

All current callers handle this correctly but the assumption that
core1_mutex is locked while calling do_load(), load_async(), or
load_sync() should not be implicit.  Make it more explicit by adding
mutex assertions in all three functions.

685985d6

feat(mutex): Add mutex_assert_locked() function · 61fd90a8

rahix authored 4 years ago

mutex_assert_locked() allows functions to assert that the current task
is holding a mutex.  This is meant for safe-guarding APIs where the
caller must ensure a certain mutex is locked.

61fd90a8

Fix lockup when attempting to load a l0dable with disabled ELF loading

Merge request reports

Activity