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 BB099C4332F for ; Thu, 10 Nov 2022 11:03:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbiKJLDD (ORCPT ); Thu, 10 Nov 2022 06:03:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229463AbiKJLC7 (ORCPT ); Thu, 10 Nov 2022 06:02:59 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CB8E62CE for ; Thu, 10 Nov 2022 03:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668078178; x=1699614178; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=QsXzk5C5epnb6EBB5ywup9HpoGDQrTmRBHEVnEeC6VY=; b=kAsk9GluEnWd1Vuc1i+CluJG2u1CQiRZ3amH13QcMATn/OEmzLrFeJFT nxB97kW7jxmObLjr+gciEFKeOftGd0929toQEvzoTGo65rUj2qKHTdbXT X/foZbGtxyyYY+0K0IFhuKPCaMWwJhTkxNBPET4Vyuum2KJLZcmptZCxe XPGgjJKBFMU8hjhgoRfmZW7+AxXYFekUg005ZQotti1jtSm0PhBD8+PzI iGEf/5aEb73yI6zBLKkxkYUmJle0oI6hDZKS6yOY/Nie4MOMqLoZo0eki 9/ZDvY6zor/ZXq65ML320zHN3U7MzfaWNGYgQLtx6IGDy8s31etgFvyb6 w==; X-IronPort-AV: E=McAfee;i="6500,9779,10526"; a="309995481" X-IronPort-AV: E=Sophos;i="5.96,153,1665471600"; d="scan'208";a="309995481" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2022 03:02:58 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10526"; a="726347003" X-IronPort-AV: E=Sophos;i="5.96,153,1665471600"; d="scan'208";a="726347003" Received: from aslawinx-mobl.ger.corp.intel.com (HELO [10.99.249.190]) ([10.99.249.190]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2022 03:02:56 -0800 Message-ID: <8039aad2-3d6f-153f-bf23-892c3804b0fa@linux.intel.com> Date: Thu, 10 Nov 2022 12:02:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] Asoc: core: fix wrong size kzalloc for rtd's components member Content-Language: en-US To: lishqchn , perex@perex.cz, tiwai@suse.com Cc: alsa-devel@alsa-project.org, broonie@kernel.org, lgirdwood@gmail.com, linux-kernel@vger.kernel.org References: From: =?UTF-8?Q?Amadeusz_S=c5=82awi=c5=84ski?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/8/2022 5:24 AM, lishqchn wrote: > The actual space for struct snd_soc_component has been allocated by > snd_soc_register_component, here rtd's components are pointers to > components, I replace the base size from *component to component. > > Signed-off-by: lishqchn > --- > sound/soc/soc-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c > index a6d6d10cd471..d21e0284b2aa 100644 > --- a/sound/soc/soc-core.c > +++ b/sound/soc/soc-core.c > @@ -459,7 +459,7 @@ static struct snd_soc_pcm_runtime *soc_new_pcm_runtime( > */ > rtd = devm_kzalloc(dev, > sizeof(*rtd) + > - sizeof(*component) * (dai_link->num_cpus + > + sizeof(component) * (dai_link->num_cpus + > dai_link->num_codecs + > dai_link->num_platforms), > GFP_KERNEL); Can't struct_size macro be used instead, it is meant to be used when calculating size of structs containing flexible arrays at the end?