From: HariKrishna Sagala <hariconscious@gmail.com>

Documentation/process/deprecated.rst recommends to avoid the use of
kmalloc with dynamic size calculations due to the risk of them
overflowing. This could lead to values wrapping around and a
smaller allocation being made than the caller was expecting.

Replace kmalloc() with kmalloc_array()

Signed-off-by: HariKrishna Sagala <hariconscious@gmail.com>
---
 sound/soc/sof/ipc3-dtrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/ipc3-dtrace.c b/sound/soc/sof/ipc3-dtrace.c
index e5c8fec173c4..6ec391fd39a9 100644
--- a/sound/soc/sof/ipc3-dtrace.c
+++ b/sound/soc/sof/ipc3-dtrace.c
@@ -126,7 +126,7 @@ static int trace_filter_parse(struct snd_sof_dev *sdev, char *string,
 		capacity += TRACE_FILTER_ELEMENTS_PER_ENTRY;
 		entry = strchr(entry + 1, entry_delimiter[0]);
 	}
-	*out = kmalloc(capacity * sizeof(**out), GFP_KERNEL);
+	*out = kmalloc_array(capacity, sizeof(**out), GFP_KERNEL);
 	if (!*out)
 		return -ENOMEM;
 
-- 
2.43.0

On Tue, Sep 23, 2025 at 07:55:13PM +0530, hariconscious@gmail.com wrote:
> From: HariKrishna Sagala <hariconscious@gmail.com>
> 
> Documentation/process/deprecated.rst recommends to avoid the use of
> kmalloc with dynamic size calculations due to the risk of them
> overflowing. This could lead to values wrapping around and a

Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.

On Wed, 15 Oct 2025, Mark Brown wrote:

> On Tue, Sep 23, 2025 at 07:55:13PM +0530, hariconscious@gmail.com wrote:
> > From: HariKrishna Sagala <hariconscious@gmail.com>
> >
> > Documentation/process/deprecated.rst recommends to avoid the use of
> > kmalloc with dynamic size calculations due to the risk of them
> > overflowing. This could lead to values wrapping around and a
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
>
Just reminding for an opportunity to check this patch.
Thank you.

On Thu, 6 Nov 2025, HariKrishna Sagala wrote:

>
>
> On Wed, 15 Oct 2025, Mark Brown wrote:
>
> > On Tue, Sep 23, 2025 at 07:55:13PM +0530, hariconscious@gmail.com wrote:
> > > From: HariKrishna Sagala <hariconscious@gmail.com>
> > >
> > > Documentation/process/deprecated.rst recommends to avoid the use of
> > > kmalloc with dynamic size calculations due to the risk of them
> > > overflowing. This could lead to values wrapping around and a
> >
> > Please submit patches using subject lines reflecting the style for the
> > subsystem, this makes it easier for people to identify relevant patches.
> > Look at what existing commits in the area you're changing are doing and
> > make sure your subject lines visually resemble what they're doing.
> > There's no need to resubmit to fix this alone.
> >
> Just reminding for an opportunity to check this patch.
> Thank you.
>
Just checking in to see if you had a chance to review this.
If it is missed in the box, please let me know.
Thank you.

On Thu, Nov 27, 2025 at 10:35:34AM +0530, HariKrishna Sagala wrote:

> Just checking in to see if you had a chance to review this.
> If it is missed in the box, please let me know.

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.

On Thu, 27 Nov 2025, Mark Brown wrote:

> On Thu, Nov 27, 2025 at 10:35:34AM +0530, HariKrishna Sagala wrote:
>
> > Just checking in to see if you had a chance to review this.
> > If it is missed in the box, please let me know.
>
> Please don't send content free pings and please allow a reasonable time
> for review.  People get busy, go on holiday, attend conferences and so
> on so unless there is some reason for urgency (like critical bug fixes)
> please allow at least a couple of weeks for review.  If there have been
> review comments then people may be waiting for those to be addressed.
>
> Sending content free pings adds to the mail volume (if they are seen at
> all) which is often the problem and since they can't be reviewed
> directly if something has gone wrong you'll have to resend the patches
> anyway, so sending again is generally a better approach though there are
> some other maintainers who like them - if in doubt look at how patches
> for the subsystem are normally handled.
>

Thank you for the clarification and the expected review cadence.
I understand people will be busy with the commitments.
Sorry for reminding for a non-critical patch but I followed-up after 2
weeks.

I will resend the patch as per the subsystem style.
I didn't send this earlier as I followed as per suggestion not to send the
patch again for only a commit message change.
Going forward I will avoid this and allow reasonable time for review
unless a change is urgent.

Thank you for the guidance.