On 2019-09-27 15:14, Pierre-Louis Bossart wrote:
On 9/26/19 9:55 PM, Navid Emamdoost wrote:
On Wed, Sep 25, 2019 at 12:05:28PM -0500, Pierre-Louis Bossart wrote:
On 9/25/19 11:19 AM, Navid Emamdoost wrote:
In snd_skl_parse_uuids if allocation for module->instance_id fails, the
allocated memory for module shoulde be released. I changes the
allocation for module to use devm_kzalloc to be resource_managed
allocation and avoid the release in error path.
if you use devm_, don't you need to fix the error path as well then,
I see a
kfree(uuid) in skl_freeup_uuid_list().
I am not very familiar with this code but the error seems to be that the
list_add_tail() is called after the module->instance_id is allocated, so
there is a risk that the module allocated earlier is not freed (since
it's
not yet added to the list). Freeing the module as done in patch 1 works,
using devm_ without fixing the error path does not seem correct to me.
Good catch, Pierre.
Thanks for the feedback, then it's your call if you can accept patch 1 as
fix.
Cezary, it's really your call.
Actually, not the best person to ask about "objective decisions" here as
my vision is clouded by changes done internally. This code no longer
exists in our internal repo. It's better for host to send MODULE_INFO
request rather than understanding firmware binary structure and parse it
directly.
I'm fine with solution #1 as I guess asking to wait for refactor is not
an option. Code deployment is delayed due to range of administrative
decisions, some of which should be uncovered on alsa-devel soon enough.
Czarek
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
