From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
To: Hans de Goede <hansg@kernel.org>,
sakari.ailus@linux.intel.com, mchehab@kernel.org
Cc: hverkuil+cisco@kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] media: i2c: gc0310: fix probe error handling and unwind resources properly
Date: Sun, 05 Apr 2026 15:46:39 +0530 [thread overview]
Message-ID: <DB5F4EC4-0754-483E-B59A-595A565E628A@gmail.com> (raw)
In-Reply-To: <38dc77ed-2427-44df-847d-4d41183e0df2@kernel.org>
On 2 April 2026 12:36:33 am IST, Hans de Goede <hansg@kernel.org> wrote:
>Hi,
>
>On 1-Apr-26 20:16, Sanjay Chitroda wrote:
>> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>>
>> The GC0310 probe path currently performs error cleanup by jumping to a
>> common label that mirrors the driver's remove() callback. This is unsafe,
>> as remove() assumes that the subdevice has been fully registered with
>> the V4L2 framework, media and control resources have been initialized.
>
>That is simply not true, all functions called in remove() internally
>check if their init counter-part has succeeded and if not are a no-op.
>
>If you're aware of any specific calls in remove() where this is not
>the case, please explicitly describe these cases and describe an
>example exit-error path from probe() where things actually go wrong.
>
Hi Hans,
Thanks for the clarification - agreed, the remove helpers are defensively implemented and the existing code is not incorrect for a functional point. I should not have stated gc0310_remov() from a probe failure is unsafe.
>> Calling remove() from probe can result in unregistering or cleaning up
>> subdevice, leading to resource leaks and subtle lifecycle bugs.
>>
>> Rewrite the probe() error handling to unwind resources explicitly, using
>> fine‑grained goto labels along with appropriate error logs. Each failure
>> path now frees only successfully acquired resource, without remove().
>>
>> This aligns the driver with standard V4L2 sensor lifecycle expectations
>> and avoids incorrect teardown during probe failures.
>
>The rest of this reads very much like this was AI generated.
>
>Did you use AI to generate these patches ? If so please:
>
>Make sure you actually understand what the patch is doing and
>very yourself that it actually is correct, which in this case
>I believe it is not.
>
>Regards,
>
>Hans
>
Yes, I did use AI assistance to help draft the commit message, but the patch logic itself was written and reviewed by me. However, your feedback makes it clear that i did not sufficiently validate internals of existing remove() based cleanup.
I would like to propose commit message that align with change and existing kernel internals:
-------
media: i2c: gc0310: make probe error unwinding explicit
The gc0310 probe path unwinds failures by jumping to a single label remove-style cleanup.
Refactor the probe error handling so that resources are unwound explicitly and in reverse order of initialization using fine-grained goto labels.
This improves clarity and maintains symmetry with the probe initialization path.
No functional change intended.
-------
Kindly share your input on the same, according I will plan to resend v2 with an updated commit message as above.
>
next prev parent reply other threads:[~2026-04-05 10:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 18:16 [PATCH 0/3] media: i2c: gc0310: cleanups and sensor clock handling improvements Sanjay Chitroda
2026-04-01 18:16 ` [PATCH 1/3] media: i2c: gc0310: fix probe error handling and unwind resources properly Sanjay Chitroda
2026-04-01 19:06 ` Hans de Goede
2026-04-05 10:16 ` Sanjay Chitroda [this message]
2026-04-06 16:09 ` Hans de Goede
2026-04-07 4:32 ` Sanjay Chitroda
2026-04-01 18:16 ` [PATCH 2/3] media: i2c: gc0310: use cached client and device pointers Sanjay Chitroda
2026-04-01 19:08 ` Hans de Goede
2026-04-05 11:01 ` Sanjay Chitroda
2026-04-01 18:16 ` [PATCH 3/3] media: i2c: gc0310: Use devm_v4l2_sensor_clk_get() Sanjay Chitroda
2026-04-01 19:20 ` Hans de Goede
2026-04-19 7:38 ` Sanjay Chitroda
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=DB5F4EC4-0754-483E-B59A-595A565E628A@gmail.com \
--to=sanjayembeddedse@gmail.com \
--cc=hansg@kernel.org \
--cc=hverkuil+cisco@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.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