On Fri, May 07, 2021 at 04:40:15PM +0200, Pali Rohár wrote:
> On Thursday 06 May 2021 18:10:09 Bjorn Helgaas wrote:
> > On Thu, May 06, 2021 at 05:31:16PM +0200, Pali Rohár wrote:
> > > Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic")
> > > Cc: stable@xxxxxxxxxxxxxxx # e0d9d30b7354 ("PCI: pci-bridge-emul: Fix big-endian support")
> >
> > I'm not sure how people would deal with *two* SHA1s.
>
> I guess that this is fine per stable document as it mention such example:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Oh, I see what you mean: the SHA1 on the stable tag is a prerequisite.
I had forgotten that, but it makes sense. Thanks!
> > This patch adds functionality, so it's not really fixing a bug in
> > 23a5fba4d941.
>
> I'm not sure what is the correct meaning of Fixes tag. I included it to
> easily determinate in which commit was introduced member name "rsvd"
> which should have been named "rootcap".
IMO, the point of "Fixes: X" is to say that "if your kernel includes
commit X, you should consider also including this patch because it
fixes a problem with X."
In this case, the fact that your kernel includes 23a5fba4d941 is not
an indication that you should include this patch because this patch
doesn't fix a defect in 23a5fba4d941.
> Submitting patches document is not fully clear for me as I understood it
> that Fixes and CC:stable are two different things. E.g. it mention
> "Attaching a Fixes: tag does not subvert ... the requirement to Cc:
> stable@xxxxxxxxxxxxxxx on all stable patch candidates." which I
> understood that patch for backporting needs to have Cc:stable:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Yes, I think you're right. "Fixes:" by itself just indicates that
this fixes a defect in a previous patch. But the fix may not rise to
the level of being considered for stable, because historically we only
wanted small, critical fixes for stable kernels.
I think this patch should omit both Fixes: and the stable tag.
If a future patch that depends on this one is a candidate for stable,
*that patch* should have a stable tag with this patch as a
prerequisite.
Useful tidbit I found recently -- a URL like this:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=v5.12#n554
is more specific and won't become stale as the doc changes. (If you
follow that URL five years later, the doc will have changed so the
v5.12 version will be stale, but at least the URL still makes sense in
the context of this conversation.)
Bjorn
