All of lore.kernel.org
 help / color / mirror / Atom feed
From: Navaneeth K <knavaneeth786@gmail.com>
To: Abdun Nihaal <abdun.nihaal@gmail.com>
Cc: parthiban.veerasooran@microchip.com,
	christian.gromm@microchip.com, gregkh@linuxfoundation.org,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: most: dim2: fix missing cleanup on interface registration failure
Date: Tue, 25 Nov 2025 21:36:16 +0530	[thread overview]
Message-ID: <de76ebde-3453-4f4f-a0a4-d054121de553@gmail.com> (raw)
In-Reply-To: <sgvpvlvyjl2sd4ehwujuetrtzl5jvvwkk7yxmjourgduylqf2w@g3qosecznvic>

Hi Nihaal,
Thank you for the detailed explanation.
That makes perfect sense. I wasn’t aware that most_register_interface()
is intended to handle cleanup via the dev.release path even on failure.
I will analyze most_register_interface() and prepare a follow-up patch
to address the inconsistency in the early error paths where put_device()
is missing, as you suggested.

Greg, since this version of the patch would introduce a double-free,
could you please drop it from staging-testing?

Regards,
Navaneeth

On 25-11-2025 20:46, Abdun Nihaal wrote:
> nack.
>
> On Sat, Nov 22, 2025 at 06:56:56PM +0000, Navaneeth K wrote:
>> If most_register_interface() fails, the function returned immediately
>> without freeing the allocated 'dev' structure or resetting the hardware
>> state via dim_shutdown().
> Based on the commit message of the following commit,
> most_register_interface() is expected to free the passed interface using
> device release both on success and error.
> commit baadf2a5c26e ("most: usb: fix double free on late probe failure")
> https://lore.kernel.org/all/20251029093029.28922-1-johan@kernel.org/
>
>>   	dev->dev.release = dim2_release;
>>   
>> -	return most_register_interface(&dev->most_iface);
>> +	ret = most_register_interface(&dev->most_iface);
>> +	if (ret)
>> +		goto err_shutdown_dim;
>> +
>> +	return 0;
> Commit d445aa402d60 ("staging: most: dim2: use device release method")
> converted this code to use device release, where the function stored in
> dev.release (dim2_release() here) will be called to free the device
> when put_device() or device_unregister() is called on the device.
>
> dim2_release() does free and shut down the hardware correctly, so doing
> it again in the error path would lead to a double free.
>
> However, I do see that in most_register_interface() function, the first
> few error paths (before the device_register() call) are not calling
> put_device() to free the interface device, which is inconsistent with
> the later error paths in that function.
>
> Leave this code as it is, and fix the most_register_interface()
> to consistently release the device on error, by calling put_device()
> on those early error paths.
>
> Also, when sending bug fixes, add a Fixes tag.
>
> Regards,
> Nihaal

  reply	other threads:[~2025-11-25 16:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-22 18:56 [PATCH] staging: most: dim2: fix missing cleanup on interface registration failure Navaneeth K
2025-11-25 15:16 ` Abdun Nihaal
2025-11-25 16:06   ` Navaneeth K [this message]
2025-11-26 11:32     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de76ebde-3453-4f4f-a0a4-d054121de553@gmail.com \
    --to=knavaneeth786@gmail.com \
    --cc=abdun.nihaal@gmail.com \
    --cc=christian.gromm@microchip.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=parthiban.veerasooran@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.