Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4833299iog; Wed, 22 Jun 2022 06:46:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vCPiKfQnYjTXMvT/wQr/N79dZqTLqQbyl95M33Ku3BYabHeLYt2Ua6z1RAUMQeN11AWTOa X-Received: by 2002:a63:7248:0:b0:40c:762e:c866 with SMTP id c8-20020a637248000000b0040c762ec866mr3087219pgn.558.1655905611410; Wed, 22 Jun 2022 06:46:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655905611; cv=none; d=google.com; s=arc-20160816; b=FVOTwdDc8bzcjqTxFKOikhbw3Oddh1Y6fMU9l4no6saMB2BAiDQVRuq75AmZ+hYhG5 TNxS9jyIHUk7JFhQJfvMOjcbROkUIyTdmW6WEgK9rUfSx+LkeEmYbPdMxk+8VC1fSsnq cWCuqCAx8D8ofACA0xrn6tHTCTz5mYJ1l4I6titzFZXYpQvCfyam5y/klG5sQ/37ubuM h4EEIbYLNAsQVDmQwip9lQLvHXua8SFbjd3g62ui2AMpvhc5cvMAFBifSR6vuyvdOQRi sgJ7mVeIpaL6PsNzJt8DraaeKckKYjc6sfSY9eXMYMP+I/HLJdks4nvmyMCoD/3tx/42 2hTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature:dkim-signature; bh=tL5R6CgcdLWhC5WLpBa844ixXg1BzecaMDlHfUxUCKo=; b=RxGpbAwnyVCVRxcEE9m49a7v354hLOgANYoa+nXlY0ByZ+3Tz5ZEP3LoZStm5HzxHq 677W6wF60BOB9CNVlD++40MB70IwpKO2IGfnikw33Y/pyDQvHd2Ufz+TjpVm68lCxLZa XmsfKkx5Uudf2VNgo1HzzLwat/KWH9L4KSIkmmn0tp9idGhU/P50r+zU4P8bFAU41oE0 Max0yP5JAoRG8mnVGmzKYMkJYTS4kXLCx5JN8iKFb/O+lTiYXqsANud7uHrOyU6q/Nj3 EioxEMUYwlVDDbxlnX06AYKYHUlp6jDdnu7gSPwHC7sAsfEbt62MTj/iFiJKA0z2kflv N3OA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oTFsweeR; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b17-20020a170902d51100b0016403c5eaa2si25501761plg.28.2022.06.22.06.46.36; Wed, 22 Jun 2022 06:46:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=oTFsweeR; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238207AbiFVNef (ORCPT + 99 others); Wed, 22 Jun 2022 09:34:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234570AbiFVNed (ORCPT ); Wed, 22 Jun 2022 09:34:33 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B112186DB for ; Wed, 22 Jun 2022 06:34:31 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 480641F9CB; Wed, 22 Jun 2022 13:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1655904870; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tL5R6CgcdLWhC5WLpBa844ixXg1BzecaMDlHfUxUCKo=; b=oTFsweeR2zWwsfHkFSd9fObMJoC1i/pkvs8e0E7OFgmHpd331ZU83Zxt4R4RefSx0GxPIF BO6V6YFa6282U50nlEDfrHQi96LUt6jC+Iv8sgbTBwdEPqIp8U4GeAj0Lv9TtQo4fLDh10 RcRxRi2ZYv2T/rHmb1xo9ue9MgoCtp8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1655904870; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tL5R6CgcdLWhC5WLpBa844ixXg1BzecaMDlHfUxUCKo=; b=h1klysAQHh0dlXwzG0fc0dEjn8xJqACVkGI5r38y5k8yipDNrlHDQ/sSB7a4YOwhXDYpjg JqhOk5hG1tbPYgDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 196B1134A9; Wed, 22 Jun 2022 13:34:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id htnbBGYas2KuNgAAMHmgww (envelope-from ); Wed, 22 Jun 2022 13:34:30 +0000 Date: Wed, 22 Jun 2022 15:34:29 +0200 Message-ID: <87wnd8n7oa.wl-tiwai@suse.de> From: Takashi Iwai To: Vitaly Rodionov Cc: Jaroslav Kysela , Takashi Iwai , Mark Brown , patches@opensource.cirrus.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Stefan Binding Subject: Re: [PATCH v7 01/14] ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls In-Reply-To: <20220622074653.179078-2-vitalyr@opensource.cirrus.com> References: <20220622074653.179078-1-vitalyr@opensource.cirrus.com> <20220622074653.179078-2-vitalyr@opensource.cirrus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 22 Jun 2022 09:46:40 +0200, Vitaly Rodionov wrote: > > +static int hda_cs_dsp_add_kcontrol(struct hda_cs_dsp_coeff_ctl *ctl) > +{ > + struct cs_dsp_coeff_ctl *cs_ctl = ctl->cs_ctl; > + struct snd_kcontrol_new *kcontrol; > + struct snd_kcontrol *kctl; > + int ret = 0; > + > + if (cs_ctl->len > ADSP_MAX_STD_CTRL_SIZE) { > + dev_err(cs_ctl->dsp->dev, "Control %s: length %zu exceeds maximum %d\n", ctl->name, > + cs_ctl->len, ADSP_MAX_STD_CTRL_SIZE); > + return -EINVAL; > + } > + > + kcontrol = kzalloc(sizeof(*kcontrol), GFP_KERNEL); > + if (!kcontrol) > + return -ENOMEM; > + > + kcontrol->name = ctl->name; > + kcontrol->info = hda_cs_dsp_coeff_info; > + kcontrol->iface = SNDRV_CTL_ELEM_IFACE_MIXER; > + kcontrol->private_value = (unsigned long)ctl; > + kcontrol->access = wmfw_convert_flags(cs_ctl->flags); > + > + kcontrol->get = hda_cs_dsp_coeff_get; > + kcontrol->put = hda_cs_dsp_coeff_put; > + > + kctl = snd_ctl_new1(kcontrol, NULL); > + if (!kctl) { > + ret = -ENOMEM; > + goto err; > + } > + ctl->kctl = kctl; > + > + ret = snd_ctl_add(ctl->card, kctl); > + if (ret) > + dev_err(cs_ctl->dsp->dev, "Failed to add KControl: %s - Ret: %d\n", kcontrol->name, > + ret); > + else > + dev_dbg(cs_ctl->dsp->dev, "Added KControl: %s\n", kcontrol->name); snd_ctl_add() releases the kctl automatically upon errors, hence assigning ctl->kctl may lead to a use-after-free. Therefore ctl->kctl should be assigned after the success of snd_ctl_add(). > +int hda_cs_dsp_control_add(struct cs_dsp_coeff_ctl *cs_ctl, struct hda_cs_dsp_ctl_info *info) > +{ > + struct cs_dsp *cs_dsp = cs_ctl->dsp; > + char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN]; > + struct hda_cs_dsp_coeff_ctl *ctl; > + const char *region_name; > + int ret; > + > + if (cs_ctl->flags & WMFW_CTL_FLAG_SYS) > + return 0; > + > + region_name = cs_dsp_mem_region_name(cs_ctl->alg_region.type); > + if (!region_name) { > + dev_err(cs_dsp->dev, "Unknown region type: %d\n", cs_ctl->alg_region.type); > + return -EINVAL; > + } > + > + ret = scnprintf(name, SNDRV_CTL_ELEM_ID_NAME_MAXLEN, "%s %s %.12s %x", info->device_name, > + cs_dsp->name, hda_cs_dsp_fw_text[info->fw_type], cs_ctl->alg_region.alg); > + > + if (cs_ctl->subname) { > + int avail = SNDRV_CTL_ELEM_ID_NAME_MAXLEN - ret - 2; > + int skip = 0; > + > + /* Truncate the subname from the start if it is too long */ > + if (cs_ctl->subname_len > avail) > + skip = cs_ctl->subname_len - avail; > + > + snprintf(name + ret, SNDRV_CTL_ELEM_ID_NAME_MAXLEN - ret, > + " %.*s", cs_ctl->subname_len - skip, cs_ctl->subname + skip); > + } > + > + ctl = kzalloc(sizeof(*ctl), GFP_KERNEL); > + if (!ctl) > + return -ENOMEM; > + ctl->cs_ctl = cs_ctl; > + ctl->card = info->card; > + > + ctl->name = kmemdup(name, strlen(name) + 1, GFP_KERNEL); This is kstrdup() :) But, we don't need to keep the name string persistently at all. It's copied onto kcontrol id field, and the original string is no longer needed after that point. So you can pass the name as is to hda_cs_dsp_add_kcontrol(). > + if (!ctl->name) { > + ret = -ENOMEM; > + dev_err(cs_dsp->dev, "Cannot save ctl name\n"); > + goto err_ctl; > + } > + > + cs_ctl->priv = ctl; > + > + return hda_cs_dsp_add_kcontrol(ctl); Hm, this leaves ctl even if it returns an error, i.e. some leaks? > +err_ctl: > + dev_err(cs_dsp->dev, "Error adding control: %s\n", name); > + kfree(ctl); > + return ret; > +} > +EXPORT_SYMBOL_NS_GPL(hda_cs_dsp_control_add, SND_HDA_CS_DSP_CONTROLS); > + > +void hda_cs_dsp_control_remove(struct cs_dsp_coeff_ctl *cs_ctl) > +{ > + struct hda_cs_dsp_coeff_ctl *ctl = cs_ctl->priv; > + > + snd_ctl_remove_id(ctl->card, &ctl->kctl->id); > + kfree(ctl->name); > + kfree(ctl); > +} > +EXPORT_SYMBOL_NS_GPL(hda_cs_dsp_control_remove, SND_HDA_CS_DSP_CONTROLS); Is hda_cs_dsp_control_remove() *always* called explicitly for all added controls at the device removal / unbind? ALSA control core also releases the remaining controls by itself, and if the objects are released there, it'll lead to memory leaks for ctl object. If the snd_kcontrol may be freed by itself without hda_cs_dsp_control_remove() call, it should have a proper private_free callback to free the assigned ctl object (also better to reset ctl->cs_ctl->priv field, too). Takashi