From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62F37C38145 for ; Wed, 7 Sep 2022 07:35:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229715AbiIGHfS (ORCPT ); Wed, 7 Sep 2022 03:35:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229609AbiIGHfO (ORCPT ); Wed, 7 Sep 2022 03:35:14 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4C1239B96 for ; Wed, 7 Sep 2022 00:35:11 -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-out1.suse.de (Postfix) with ESMTPS id 1A91933AF5; Wed, 7 Sep 2022 07:35:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1662536110; 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=37dfE1GaBFM9YPRfxf4bLjGrfUKhn0K6cN9Lp4z0Fdo=; b=lUqvTen91LbbGDUg43CG2Zzj6BAU1Xpv9hoL7ju6bwn51EGloRhOa6VZjDhyHwxlSJQ1KD i3RiU85P8rZlILNlZTF3voOqkO/lq8qy2xu3/jXLZ5xaXUYRhGHInO5koGTYvy9zLFcJdn ahoi8SYDPJMzGFI/RWZl4Uy44VBsOrk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1662536110; 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=37dfE1GaBFM9YPRfxf4bLjGrfUKhn0K6cN9Lp4z0Fdo=; b=t5p4GIePaPW98hM+6VjZztp9ZkXPbd3BgNaAu9kkbmvZBu8cpxo4xoF3Jl9g9xFDetMzPm kLtgCgjZ4Lv4uVCQ== 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 E8CEE13A66; Wed, 7 Sep 2022 07:35:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id kwwbOK1JGGNVfQAAMHmgww (envelope-from ); Wed, 07 Sep 2022 07:35:09 +0000 Date: Wed, 07 Sep 2022 09:35:08 +0200 Message-ID: <87illzeixf.wl-tiwai@suse.de> From: Takashi Iwai To: Jianglei Nie Cc: perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ALSA: hda/ca0132: fix potential memory leak in dspxfr_image() In-Reply-To: <20220907065917.55810-1-niejianglei2021@163.com> References: <20220907065917.55810-1-niejianglei2021@163.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 07 Sep 2022 08:59:17 +0200, Jianglei Nie wrote: > > dspxfr_image() allocates DSP ports for the download stream with > dsp_allocate_ports_format(). When gets some error, the allocated > DSP ports are not released, which will lead to a memory leak. Hmm, those allocate_* functions don't really allocate memories but rather allocate virtual ports on the hardware; i.e. it just flips some DSP registers. There should be no "memory leaks". > We can fix it by releasing DSP ports with dsp_free_ports() when > getting some error. > > Signed-off-by: Jianglei Nie > --- > sound/pci/hda/patch_ca0132.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c > index 208933792787..6b8f45e14075 100644 > --- a/sound/pci/hda/patch_ca0132.c > +++ b/sound/pci/hda/patch_ca0132.c > @@ -3455,6 +3455,7 @@ static int dspxfr_image(struct hda_codec *codec, > &port_map_mask); > if (status < 0) { > codec_dbg(codec, "alloc ports fail\n"); > + dsp_free_ports(codec); This is likely superfluous. When an allocation fails, you don't free, in general. thanks, Takashi