Re: [PATCH v2] i2c: i801: fix cleanup code in remove() and error path of probe()

[Heiner Kallweit <hkallweit1@gmail.com>]

On 07.09.2023 07:45, Heiner Kallweit wrote:
> On 06.09.2023 20:25, Andi Shyti wrote:
>> Hi Jean,
>>
>>>>> I wouldn't cc stable. For one thing, this patch doesn't fix a bug that
>>>>> actually bothers people. Error paths are rarely taken, and driver
>>>>> removal isn't that frequent either. Consequences are also rather
>>>>> harmless (one-time resource leak, race condition which is quite
>>>>> unlikely to trigger).  
>>>>
>>>> we are having this same discussion in another thread: if a bug is
>>>> unlikely to happen, doesn't mean that there is no bug. A fix is a
>>>> fix and should be backported to stable kernels.
>>>
>>> No. Please read:
>>>
>>>   https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>>>
>>> There is clearly a list of conditions for a commit to be eligible for
>>> stable kernel trees. It's not "every fix".
>>
>> I think you are putting these fixes into the ""This could be a
>> problem..." type of things".
>>
>> But as I see these fixes don't belong to this category, as they
>> are clearing the exit path. This is a kind of fixes I want to see
>> going to stable.
>>
>> Which means that if we exit through that path, do we exit
>> cleanly, e.g., without leaking? If the answer is "no", then this
>> is a fix and should go to stable.
>>
>> It belongs to "This could be a problem..." type, things like
>> dev_err/dev_warn (first thing coming to my mind) or other non
>> functional fixes.
>>
>> Maybe this is a matter of opinion and different background. For
>> the i2c side I'm in peace :-)
>>
>> For the stable backport I'd love to hear another opinion.
>>
>> Thanks, Jean!
>> Andi
> 
> Please let me know once you come to an agreement, then I'll
> submit a (hopefully) final version.
> 
I think I'll split the patch, that should make dealing with it easier.