Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib_manager: modules: Fix missing call to modules_free #8935

Merged
merged 1 commit into from
Apr 17, 2024

Conversation

softwarecki
Copy link
Collaborator

@softwarecki softwarecki commented Mar 12, 2024

This PR addresses an issue with non-iadk loadable modules for which the modules_free function is not called.

For some of following commits I already prepared PRs - pending review.

Actual PR content:
e27ea44 lib_manager: modules: move native lib support to lib_manager

Copy link
Collaborator

@lyakh lyakh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the end result, that modules.c is no longer needed for native modules. Need to test this with LLEXT (and add a CI LLEXT test...)

src/ipc/ipc4/helper.c Outdated Show resolved Hide resolved
src/ipc/ipc4/helper.c Outdated Show resolved Hide resolved
build_info->api_version_number.full == SOF_MODULE_API_CURRENT_VERSION) {
/* Use lib_manager shim functions */
drv->ops.create = &lib_manager_module_create;
drv->ops.free = &lib_manager_module_free;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do I understand it correctly, that after this change modules.c will only be used for IADK? That would actually be good indeed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By design IADK modules are inheriting interface from native loadable modules.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

modules.c (part of the Processing Module Adapter) was supposed to be responsible only for calling C++ functions related to IADK modules. After this change it is no longer used by other module types.

Copy link
Collaborator

@lyakh lyakh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested, unfortunately this breaks llext

src/audio/module_adapter/module/modules.c Show resolved Hide resolved
@softwarecki
Copy link
Collaborator Author

@lyakh Can you check do it still breaks llext?

@lyakh
Copy link
Collaborator

lyakh commented Mar 22, 2024

@lyakh Can you check do it still breaks llext?

@softwarecki why do you think it's fixed now? What's been changed compared to that version? I compared and I don't see any changes that would fix it. buildinfo is still lost so the module entry point isn't identified and called correctly, AFAICS

@softwarecki
Copy link
Collaborator Author

@softwarecki why do you think it's fixed now? What's been changed compared to that version? I compared and I don't see any changes that would fix it. buildinfo is still lost so the module entry point isn't identified and called correctly, AFAICS

@lyakh The module entry is taken from a module manifest. This code path has not been changed (lib_manager_allocate_module -> llext_manager_allocate_module -> llext_manager_load_module).

@lyakh
Copy link
Collaborator

lyakh commented Apr 2, 2024

@softwarecki why do you think it's fixed now? What's been changed compared to that version? I compared and I don't see any changes that would fix it. buildinfo is still lost so the module entry point isn't identified and called correctly, AFAICS

@lyakh The module entry is taken from a module manifest. This code path has not been changed (lib_manager_allocate_module -> llext_manager_allocate_module -> llext_manager_load_module).

@softwarecki I'm talking about buildinfo not the manifest

@lyakh
Copy link
Collaborator

lyakh commented Apr 2, 2024

@softwarecki I'm talking about buildinfo not the manifest

@softwarecki ...and sorry for a delay - that comment was sitting in my browser for days, I must've forgotten to press "comment" :-(

@softwarecki
Copy link
Collaborator Author

softwarecki commented Apr 2, 2024

@lyakh The buildinfo structure is not propagated up because there is no need for it. For llext modules it is retrieved in the llext_manager_link function and checked in llext_manager_allocate_module (see: https://github.com/thesofproject/sof/pull/8935/files#diff-105bb3747dadc76f4ae373fd79ca6aba210883d29b7caee205f4adda6f6d6dccR256) . For other modules types, obtaining and checking is done in lib_manager_register_module (https://github.com/thesofproject/sof/pull/8935/files#diff-957336c9ebdbe16dab94f6e49620e9b112d3b373d3de4d1035cdf289f745a00dR666).

lyakh
lyakh previously approved these changes Apr 3, 2024
Copy link
Collaborator

@lyakh lyakh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 nitpicks - let's fix in a follow-up

src/ipc/ipc4/helper.c Outdated Show resolved Hide resolved
src/ipc/ipc4/helper.c Outdated Show resolved Hide resolved
@lyakh
Copy link
Collaborator

lyakh commented Apr 3, 2024

@lyakh The buildinfo structure is not propagated up because there is no need for it. For llext modules it is retrieved in the llext_manager_link function and checked in llext_manager_allocate_module (see: https://github.com/thesofproject/sof/pull/8935/files#diff-105bb3747dadc76f4ae373fd79ca6aba210883d29b7caee205f4adda6f6d6dccR256) . For other modules types, obtaining and checking is done in lib_manager_register_module (https://github.com/thesofproject/sof/pull/8935/files#diff-957336c9ebdbe16dab94f6e49620e9b112d3b373d3de4d1035cdf289f745a00dR666).

@softwarecki ah, you're right, now I get it! And tested - worked in a short test. It looks good in general, but a double-use test just has caused a DSP panic with this PR - investigating, removing the approval for now

@lyakh lyakh dismissed their stale review April 3, 2024 08:28

a more thorough test caused a DSP panic, removing the approval temporarily

@lyakh
Copy link
Collaborator

lyakh commented Apr 3, 2024

@softwarecki please merge this diff with your "lib_manager: modules: move native lib support to lib_manager" (and also add a description, it certainly deserves one)
20240403-1-sof-ldmod.gitdiff.txt
then I'll be able to restore my approval

@softwarecki
Copy link
Collaborator Author

Rebased and applied @lyakh patch.

@lyakh
Copy link
Collaborator

lyakh commented Apr 12, 2024

@softwarecki @kv2019i @lgirdwood can we merge this one instead of #8974 - the first 3 commits are identical and the fourth one looks good to me too

@kv2019i
Copy link
Collaborator

kv2019i commented Apr 12, 2024

Sorry @lyakh , I was too quick with #8974. @softwarecki can you update this and we can merge this as well?

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@softwarecki softwarecki force-pushed the modules-unload branch 2 times, most recently from e27ea44 to b96b913 Compare April 12, 2024 15:15
Moved module type identification to lib_manager. Since llext modules place
the buildinfo structure in a separate section, API version verification has
been moved to llext_manager. Thanks to these changes, the Processing Module
Adapter is used only by IADK modules as intended. This commit also fixes an
issue with the modules_free function not being called for native modules.

Signed-off-by: Adrian Warecki <adrian.warecki@intel.com>
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lgirdwood
Copy link
Member

@softwarecki @wszypelt good to merge or real issue reported by CI ?

@wszypelt
Copy link

wszypelt commented Apr 16, 2024

@lgirdwood I'm afraid that the PR may contain a sporadic issue, I'm taking this PR for full scope tests, I should have the results tomorrow :)

@wszypelt
Copy link

@lgirdwood @softwarecki After careful checking, I don't see any problems, CI also passed correctly

@kv2019i kv2019i merged commit 902b1e5 into thesofproject:main Apr 17, 2024
44 of 45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants