(Cc: Greg, Sasha)
On Sun Jan 4, 2026 at 1:45 PM CET, Miguel Ojeda wrote:
On Sat, Jan 3, 2026 at 10:16 PM Marko Turk mt@markoturk.info wrote:
The typo was introduced in the original commit where pci::Bar was added: Fixes: bf9651f84b4e ("rust: pci: implement I/O mappable `pci::Bar`")
Should I use that for the Fixes: tag?
I would add both, since it was added in both and thus different set of stable releases may need to fix it differently (i.e. before and after the move).
In general I prefer to only add a Fixes: tag for the commit that introduced the issue.
In this case, from a quick look, one is for the current release, so it doesn't need backport, and the other would need a custom one (since this commit wouldn't apply) if someone wants to do Option 3.
I could be wrong, but I think in trivial cases (such as code moves) the stable team does derive custom commits themselves.
@Greg, Sasha: Is this something you prefer to do or is it something you just do because it's easier / quicker than to get back and ask for a custom commit?
Again, I could also remember this wrongly, but I think I just recently reviewed such a commit from Sasha. :)
Should I do that in the same commit?
That seems reasonable in this case, please do so.
On Sun, Jan 4, 2026 at 3:08 PM Danilo Krummrich dakr@kernel.org wrote:
In general I prefer to only add a Fixes: tag for the commit that introduced the issue.
If their scripts track moves well, then it is great to avoid it, but I am not sure how well that works or not or in which cases, i.e. it could look like two different commits introduced the issue and thus one backport could be missed. Not sure.
Again, I could also remember this wrongly, but I think I just recently reviewed such a commit from Sasha. :)
Hmm... I also had a few cases where Sasha autoapplied, but in most cases, I had to provide custom patches when they didn't apply cleanly, even trivial ones.
Cheers, Miguel
On Sun, Jan 04, 2026 at 07:30:22PM +0100, Miguel Ojeda wrote:
On Sun, Jan 4, 2026 at 3:08 PM Danilo Krummrich dakr@kernel.org wrote:
In general I prefer to only add a Fixes: tag for the commit that introduced the issue.
If their scripts track moves well, then it is great to avoid it, but I am not sure how well that works or not or in which cases, i.e. it could look like two different commits introduced the issue and thus one backport could be missed. Not sure.
Again, I could also remember this wrongly, but I think I just recently reviewed such a commit from Sasha. :)
Hmm... I also had a few cases where Sasha autoapplied, but in most cases, I had to provide custom patches when they didn't apply cleanly, even trivial ones.
It all depends, sometimes we can handle file moves easily, sometimes we can not.
But really, why is a comment typo being needed in stable kernels?
thanks,
greg k-h
On Mon, Jan 5, 2026 at 7:25 AM Greg KH gregkh@linuxfoundation.org wrote:
It all depends, sometimes we can handle file moves easily, sometimes we can not.
But really, why is a comment typo being needed in stable kernels?
It isn't (well, it is not just a comment since it does end up in the rendered docs, so it is a bit more "visible" than in a comment, and I imagine some projects reasonably treat them as a fix, but still, it is just a typo).
We discussed this years ago when I noticed a typo being picked up by stable since I wondered why. On my side, I am happy either way -- what I currently do is explicitly tag the ones that appear in docs. That way you can decide on your side.
For the others (the ones in comments), I think it is not really worth it to even figure out a Fixes: tag etc.
Of course, this is for trivial typos -- for something that e.g. completely changes the requirements of a `# Safety` precondition the story is different.
Cheers, Miguel
On Mon Jan 5, 2026 at 11:39 AM CET, Miguel Ojeda wrote:
On my side, I am happy either way -- what I currently do is explicitly tag the ones that appear in docs. That way you can decide on your side.
This is how I handle it as well. For doc-comments I request a Fixes: tag to be added and leave it to the stable team to decide.
Unless explicitly requested by the stable team (which obviously did not happen so far) I do not send separate backport patches for typos when the upstream commit does not apply though.
linux-stable-mirror@lists.linaro.org