Subject: Re: [PATCH next] Fix the build failed caused by -Wstringop-overflow

From: "Gustavo A. R. Silva" <[email-masked]>
Date: Thu, 30 Nov 2023 11:56:29 -0600

On 11/30/23 11:48, Andy Shevchenko wrote:
> On Thu, Nov 30, 2023 at 09:52:42AM -0600, Gustavo A. R. Silva wrote:
>> On 11/30/23 04:57, Wenyu Huang wrote:
> 
> ...
> 
>>> Fixes: 89741e7e42f6 ("Makefile: Enable -Wstringop-overflow globally")
>>
>> The commit ID is from a patch that's currently in linux-next, which
>> does not guarantee it's a stable commit. So, it shouldn't be used
>> for any tag in any changelog text. In fact, it has changed a couple
>> of times in the last couple of weeks.
> 
> I disagree on this in general.
> 
> The case in practice I have. I does something in new cycle that broke the
> enumeration of some devices. The patch is in the maintainer's tree pending
> for the next release (v6.8-rc1). There are I see two options:
> - revert patch completely and redo it properly
> - add a fix (which is one liner)
> 
> Now, what you are suggesting is to drop the Fixes tag on the grounds that
> the culprit and the fix are to be in the same release (as we go let's say
> with the latter approach). In case that the culprit will be backported
> (let's say to satisfy dependencies, as per se it's not a fix), it will
> bring a regression and become unnoticed for some time until first reports
> will appear. Additional resources would be need for all this.
> 
> So, I'm fully in favour of using Fixes tag as it makes clear if we have
> some broken changes in the kernel for which the fix is known and exists.

I'm fully in favor, as well. :)

I'm talking about patches in linux-next, exclusively.

--
Gustavo