https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Everything you ever wanted to know about Linux -stable releases
(Everything you want to know about the stable release of Linux)
Rules on what kind of patches are accepted, and which ones are not, into the “-stable” tree:
For the "-stable" tree, there are rules for accepted patch types and unacceptable ones.
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some “oh, that’s not good” issue. In short, something critical.
--It must be clearly correct and tested. ――No more than 100 lines at most, including context. ――Please solve only one thing. --You have to fix the actual bugs that are annoying people (not the kind of "this can be a problem ...") --A solution to build errors (but not marked with CONFIG_BROKEN), corrupted oops, hang data, real security issues, or issues that cause "oh, that's not good" issues. In short, something important.
- Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
An important issue reported to users distributing kernels that resolves performance and interactivity issues. These fixes obviously have a high risk of delicate regression and are only provided by the maintainer of the distribution kernel, and if it has additional information about the impact the user sees, it needs to include a link by bugzilla entry. there is.
- New device IDs and quirks are also accepted.
--Allows new device IDs and quirks (features). -It is not a matter of "theoretical race condition". Cases where no explanation is given as to how the race will be published. -Cannot include "trivial" fixes (spelling changes, Xiang Yu cleanup, etc.) --You must follow the rules in Documentation / process / submitting-patches.rst. --Or equivalent fixes must already exist in Linus's tree, which is upstream.
Procedure for submitting patches to the -stable tree
- If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.rst after first checking the stable networking queue at https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= to ensure the requested patch is not already queued up.
-If the patch is within the files of net / and drivers / net, then at https://patchwork.ozlabs.org/bundle/davem/stable/?series=1submitter=1state=*&q=1archive= After first checking the stable network queue, refer to the netdev stable submission guideline in Documentation / networking / netdev-FAQ.rst to make sure the requested patch is not yet in the queue. Please give me. --Security patches are not handled (alone) by -stable revice processes. You will need to follow the steps described in Documentation / admin-guide / security-bugs.rst.
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing