From nobody Sun Feb 8 21:48:08 2026 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 231252DCF50; Sun, 26 Oct 2025 12:42:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.237.130.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761482559; cv=none; b=LsYCS4FtXFWPpHwIJj55sgPrb24vx6TfqDRpR175c+UVLLU5cilZ9y1rOCVcsilJsYLvtLrY4+VSorBs/8xHLZtLIDbG1j3A5j18kP66uDZRC5Akw40OH62jMe9VrDTArn7yExggy6XKwZEaUWeDCW//Rr2++Em2cdcMwXryAEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761482559; c=relaxed/simple; bh=YPmz9plxeC1YEcFAWI17S4yEgIf+VNJKzQ5SC6730bM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hIRzn0ar26uKSoN+2uaWzhubYfF2t4toJJO3cqKvyL0Ds3UoRiC43rSMsxQm+G0eOPFrByabsb8SL7tGuCMPQMGEX/9LRwm/1LXl68BXmfQTZYNFuYzM2F7v+WT67iZN6b39yJ2jWIue3hVCHRw5MO5IPXDgxbEBqhjqvruOkcU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info; spf=pass smtp.mailfrom=leemhuis.info; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b=AehCcECH; arc=none smtp.client-ip=80.237.130.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b="AehCcECH" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemhuis.info; s=he214686; h=Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:From:Sender: Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:In-Reply-To: References; bh=Xl7EbKxVssEXZJh8Rfnajk+ePVuHpmu9Mxi6gIB7sbs=; t=1761482554; x=1761914554; b=AehCcECHHGj7CGEj59Ae1dQLU2Ijx4/jffdmjsx/fPw+ERI4S5ZNiN8GhIVST pc6igRHKLLyD7czlsoeUucTe0AVXumx928Zb5prlvHi4APx+jDAhwQ8d+egcZbPFSOWSiU44sy0Yo me4LsdTq+uDBuPQHRpI1ks3iJ3hSkaQeF1Z4gL5P8N+gKRZTgUHC5t8jWppxDM1mI3PQSfpiPv1zP BGGwmVMSbGZCJovVRuz3/36JBB0vBOeuv2RjwtyovzjtfGqDALItZNV6DJYiktI5REWAbnoWGLY0m kwA02lDXOSwXMwHXJe0le7uIufLl5yvRRGEPyFSVIRZsVMG6hw==; Received: from [2a02:8108:8984:1d00:a8ad:ebd4:6fc6:160] (helo=luggage.fritz.box); authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1vD04u-001mZC-06; Sun, 26 Oct 2025 13:42:32 +0100 From: Thorsten Leemhuis To: Jonathan Corbet Cc: workflows@vger.kernel.org, linux-doc@vger.kernel.org, regressions@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v1 25/30] docs: reporting-issues: improve text on non-regressions in stable Date: Sun, 26 Oct 2025 13:42:16 +0100 Message-ID: <0a3548a6b5d8ca87c9d81838d84afeb619a6985e.1761481839.git.linux@leemhuis.info> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1761482554;2f8dc1da; X-HE-SMSGID: 1vD04u-001mZC-06 Content-Type: text/plain; charset="utf-8" Fine-tune the instructions about handling non-regressions only occurring in stable or longterm kernels. This removes the accompanying text in the reference section to shorten things somewhat: this case is rare and the instructions in the step-by-step guide cover all the important bits now. Signed-off-by: Thorsten Leemhuis --- .../admin-guide/reporting-issues.rst | 129 ++---------------- 1 file changed, 9 insertions(+), 120 deletions(-) diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation= /admin-guide/reporting-issues.rst index 9611514d10414e..a78060098c59f0 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -299,29 +299,29 @@ supported stable or longterm series that (b) you were= unable to reproduce in the current mainline and (c) is not a regression. If all of that holds tru= e, follow these steps: =20 -* Be aware: it is possible the issue will not be resolved, as the fix migh= t be +* Be aware: It is possible the issue will not be resolved, as the fix migh= t be too big or risky to backport. =20 -* Search Linux' mainline Git repository or `lore +* Search Linux's mainline Git repository or `lore `_ for the change resolving the issue. In = case - you have trouble locating it, consider using a bisection; alternatively = ask + you have trouble locating it, consider using a bisection; alternatively,= ask on the list of the affected subsystem for advice while CCing the relevant maintainers and developers. =20 * Check if the change is already scheduled to be backported by searching t= he - patch description for a 'stable tag' (a line like 'Cc: - ' and the patch's title in lore.kernel.org: + patch description for a 'stable tag' (e.g., a line like 'Cc: + ') and the patch's title in lore.kernel.org: =20 - * If the change is already scheduled for backporting, it usually will be - picked up within one or two weeks after being mainlined. Note though, = plans + * If the change is already scheduled for backporting, it will usually be + picked up within one or two weeks after being mainlined. Note, though,= plans sometimes change; a comment next to the stable tag might also limit ho= w far the fix is backported and thus exclude the series you care about. If t= here are good reasons for this, you are out of luck. If you can't spot any: =20 Send a reply asking the involved developers if backporting to the seri= es is - an option. Note though, the developers might greenlight backporting, b= ut + an option. Note, though, the developers might greenlight backporting, = but unwilling to handle the work themselves -- in which case you or somebo= dy - else must test and submit the fix and everything it depends on as expl= ained + else must test and submit the fix and everything it depends on, as exp= lained in Documentation/process/stable-kernel-rules.rst. =20 * If the change is not scheduled for backporting, search `lore @@ -1457,117 +1457,6 @@ easier. And with a bit of luck there might be someo= ne in the team that knows a bit about programming and might be able to write a fix. =20 =20 -Reference for "Reporting issues only occurring in older kernel version lin= es" ---------------------------------------------------------------------------= --- - -This section provides details for the steps you need to take if you could = not -reproduce your issue with a mainline kernel, but want to see it fixed in o= lder -version lines (aka stable and longterm kernels). - -Some fixes are too complex -~~~~~~~~~~~~~~~~~~~~~~~~~~ - - *Prepare yourself for the possibility that going through the next few = steps - might not get the issue solved in older releases: the fix might be too= big - or risky to get backported there.* - -Even small and seemingly obvious code-changes sometimes introduce new and -totally unexpected problems. The maintainers of the stable and longterm ke= rnels -are very aware of that and thus only apply changes to these kernels that a= re -within rules outlined in Documentation/process/stable-kernel-rules.rst. - -Complex or risky changes for example do not qualify and thus only get appl= ied -to mainline. Other fixes are easy to get backported to the newest stable a= nd -longterm kernels, but too risky to integrate into older ones. So be aware = the -fix you are hoping for might be one of those that won't be backported to t= he -version line your care about. In that case you'll have no other choice the= n to -live with the issue or switch to a newer Linux version, unless you want to -patch the fix into your kernels yourself. - -Common preparations -~~~~~~~~~~~~~~~~~~~ - - *Perform the first three steps in the section "Reporting issues only - occurring in older kernel version lines" above.* - -You need to carry out a few steps already described in another section of = this -guide. Those steps will let you: - - * Check if the kernel developers still maintain the Linux kernel version = line - you care about. - - * Search the Linux stable mailing list for exiting reports. - - * Check with the latest release. - - -Check code history and search for existing discussions -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - *Search the Linux kernel version control system for the change that fi= xed - the issue in mainline, as its commit message might tell you if the fix= is - scheduled for backporting already. If you don't find anything that way, - search the appropriate mailing lists for posts that discuss such an is= sue - or peer-review possible fixes; then check the discussions if the fix w= as - deemed unsuitable for backporting. If backporting was not considered at - all, join the newest discussion, asking if it's in the cards.* - -In a lot of cases the issue you deal with will have happened with mainline= , but -got fixed there. The commit that fixed it would need to get backported as = well -to get the issue solved. That's why you want to search for it or any -discussions abound it. - - * First try to find the fix in the Git repository that holds the Linux ke= rnel - sources. You can do this with the web interfaces `on kernel.org - `_ - or its mirror `on GitHub `_; if you = have - a local clone you alternatively can search on the command line with ``g= it - log --grep=3D``. - - If you find the fix, look if the commit message near the end contains a - 'stable tag' that looks like this: - - Cc: # 5.4+ - - If that's case the developer marked the fix safe for backporting to ver= sion - line 5.4 and later. Most of the time it's getting applied there within = two - weeks, but sometimes it takes a bit longer. - - * If the commit doesn't tell you anything or if you can't find the fix, l= ook - again for discussions about the issue. Search the net with your favorite - internet search engine as well as the archives for the `Linux kernel - developers mailing list `_. Also read the - section `Locate kernel area that causes the issue` above and follow the - instructions to find the subsystem in question: its bug tracker or mail= ing - list archive might have the answer you are looking for. - - * If you see a proposed fix, search for it in the version control system = as - outlined above, as the commit might tell you if a backport can be expec= ted. - - * Check the discussions for any indicators the fix might be too risky t= o get - backported to the version line you care about. If that's the case you= have - to live with the issue or switch to the kernel version line where the= fix - got applied. - - * If the fix doesn't contain a stable tag and backporting was not discu= ssed, - join the discussion: mention the version where you face the issue and= that - you would like to see it fixed, if suitable. - - -Ask for advice -~~~~~~~~~~~~~~ - - *One of the former steps should lead to a solution. If that doesn't wo= rk - out, ask the maintainers for the subsystem that seems to be causing the - issue for advice; CC the mailing list for the particular subsystem as = well - as the stable mailing list.* - -If the previous three steps didn't get you closer to a solution there is o= nly -one option left: ask for advice. Do that in a mail you sent to the maintai= ners -for the subsystem where the issue seems to have its roots; CC the mailing = list -for the subsystem as well as the stable mailing list (stable@vger.kernel.o= rg). - - Appendix: additional background information =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --=20 2.51.0