llext: fix save-restore with no initialized modules

[lyakh]

LLEXT save-restore to DRAM had a bug: if the DSP is powered off with loaded LLEXT modules, none of which was used, context restoration was performed incorrectly, leading to inability to use LLEXT after the next boot. This patch fixes that bug.

[Copilot]

Pull Request Overview

This PR enhances the LLEXT (Loadable Extensions) manager's DRAM storage and restoration functionality by adding tracking for the total number of modules (n_mod) in addition to the existing tracking of instantiated LLEXT instances (n_llext). This allows the system to properly handle scenarios where modules exist without LLEXT instances.

Key changes:

• Added n_mod field to track total number of modules stored in DRAM
• Modified the restore function's initial check to use n_mod instead of n_llext for determining if modules are saved
• Refactored memory allocation for LLEXT restoration to be conditional on n_llext > 0

Comments suppressed due to low confidence (2)

src/library_manager/llext_manager_dram.c:310

• Missing cleanup of lib_manager_dram.n_mod field. This field should also be reset to 0 after successful restoration to maintain consistency with the new tracking mechanism and prevent stale data on subsequent operations. Add lib_manager_dram.n_mod = 0; after line 310.

	lib_manager_dram.n_llext = 0;

src/library_manager/llext_manager_dram.c:308

• Memory leak when lib_manager_dram.n_llext == 0. The rfree(ldr) call at line 308 attempts to free ldr, but when n_llext is 0, ldr is set to NULL (line 191), making this a no-op. However, if the code takes the goto nomem path before the conditional check at line 275, ldr might be undefined. Additionally, the comment and logic suggest ptr_array should be freed, not ldr specifically. Consider freeing using a temporary variable that holds ptr_array or adjusting the logic to ensure proper cleanup.

	rfree(ldr);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jsarha]

Hmm. Where are the CI test results? I do not see them in in failed, successful or pendig list. The function where the fix is is too long an hairy for me to truly understand in one or two hours, but for what I understand it looks ok. I also run some manual tests to verify that the code now indeed works.

[kv2019i]

@jsarha We can't yet see the results in PR testing. The Linux overlay config is only enabled for daily testing now, so to see whether this PR helps, we need to merge it and wait for next daily. Same goes with #10356

[lyakh]

weird, the build step isn't completing https://sof-ci.01.org/sofpr/PR10360/build17230/build

[lyakh]

SOFCI TEST

[lyakh]

@lrudyX hi, could you check "Internal CI" results please? All TGL and MTL tests failed and they shouldn't be affected at all, because this PR only touches LLEXT, and neither of them uses it

[lgirdwood]

@lyakh 2.14 ?

[lyakh]

@lyakh 2.14 ?

@lgirdwood if we want to disable full context saving for LNL in 2.14, then yes, it's needed. Otherwise - not urgent.

[lgirdwood]

SOFCI TEST

[lgirdwood]

rerun CI, looks like it was stuck.

[kv2019i]

@lyakh Can you check the warning from doxygen, it's blockng merge. Otherwise this would be ready to go.

[kv2019i]

@lyakh Can you check the warning from doxygen, it's blockng merge. Otherwise this would be ready to go.

Uh, this was broken in #10350 , not this PR. Proceeding with merge of this one, but please fix in a follow-up.

[lyakh]

@lyakh Can you check the warning from doxygen, it's blockng merge. Otherwise this would be ready to go.

Uh, this was broken in #10350 , not this PR. Proceeding with merge of this one, but please fix in a follow-up.

@kv2019i it's already fixed AFAICS ea1fccd