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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox