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.
