On Tue, Apr 14, 2026 at 01:40:33PM +0200, Quentin Schulz wrote: > Hi all, > > I would like to backport > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a7ac22d53d0990152b108c3f4fe30df45fcb0181 > to linux-6.12.y. It is not a conflict-less cherry-pick as many commits have > been made to that file between 6.12 and 6.19 when it was fixed, which makes > git-cherry-pick conflict. I believe I have a patch that implements the same > logic (moving code around, just that that code is different since it was > modified after 6.12) in linux-6.12.y that does the original commit in 6.19.
Then backport all of the needed fixes, that's the simplest way, just send a series of patches. > My understanding is that this means this patch fits Option 3: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3. > > 1) It is not specified there what to do with git trailer tags, e.g. > Reviewed-by, Acked-by, Tested-by. I'm assuming > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes You keep them as-is. See the many backports that are sent to the [email protected] list for many examples of this. > 2) I'm also wondering if we should strip the Signed-off-by tags used in the > original patch's delivery path to Linus. After all, it'll go through a > different path: to stable "directly". For this specific commit, it doesn't > matter as the Signed-off-by are for all authors including the maintainer as > last, but the question remains, I don't believe it's always the case the > last author Signed-off-by is the same as the maintainers' first and last > Signed-off-by in the delivery path. What should we do? Keep the originals please. > 3) Finally, the last question I have is whether it's required/recommended, > and if so, how, to tell maintainers of > https://git.kernel.org/pub/scm/linux/security/vulns.git that this patch is > for CVE X, in my case > https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-22986.dyad. > Maybe their tooling will automatically pick it up once merged, but I > couldn't find documentation either in Maintainers, and stable backports, don't care about CVEs, keep the wording in the changelog identical and properly mark what the commit id is that you are backporting. Again, there are many thousands of examples on the stable mailing list if you want to look in the archives. By keeping the original git id, the CVE scripts will properly pick this up when a commit that has been assigned to a CVE in the past is backported to older kernels, and then the json records will be automatically updated when the release happens, and pushed out to cve.org. There's nothing special you need to do here at all. Hope this helps, greg k-h
