On Mon, Jul 29, 2024 at 10:09:39PM +0200, Helge Deller wrote:
> On 7/29/24 17:59, Dan Carpenter wrote:
> > On Mon, Jul 29, 2024 at 10:13:17AM +0200, Helge Deller wrote:
> > > On 7/28/24 20:29, Christophe JAILLET wrote:
> > > > If an error occurs after request_mem_region(), a corresponding
> > > > release_mem_region() should be called, as already done in the remove
> > > > function.
> > >
> > > True.
> > >
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > >
> > > I think we can drop this "Fixes" tag, as it gives no real info.
> >
> > If we're backporting patches then these tags really are useful. As
> > I've been doing more and more backporting, I've come to believe this
> > more firmly.
>
> Sure, "Fixes" tags are useful, but only if they really refer
> to another patch which introduced the specific issue.
>
> But the tag 1da177e4c3f4 ("Linux-2.6.12-rc2") isn't useful, as it's
> just the initial git commit. It has no relation to why release_mem_region()
> might have been initially missed. See:
In the last couple stable kernels we've backported some pretty serious
networking commits that have Linux-2.6.12-rc2 for the Fixes tag. So if
it's security related that's really important information.
For minor stuff like this, the commit will be backported as far back as
possible and until it ends up in a list of failed commits.
When I'm reviewing the list of failed patches and there is no Fixes tag
I think maybe it was backported to all the affected kernels? In that
case, I could have skipped the manual review if the patch was just
tagged correctly. Then I wonder, why wasn't it tagged? I just assume
it was sloppiness honestly. I'm probably not going to spend that much
time on it, but it's annoying.
When a commit lists Linux-2.6.12-rc2 as the Fixes then it still ends up
in the failed list. But it can't affect too many users if we're only
getting around to fixing it now. It's easier to ignore.
regards,
dan carpenter
