1.. _submitchecklist:
2
3=======================================
4Linux Kernel patch submission checklist
5=======================================
6
7Here are some basic things that developers should do if they want to see their
8kernel patch submissions accepted more quickly.
9
10These are all above and beyond the documentation that is provided in
11:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
12and elsewhere regarding submitting Linux kernel patches.
13
14Review your code
15================
16
171) If you use a facility then #include the file that defines/declares
18   that facility.  Don't depend on other header files pulling in ones
19   that you use.
20
212) Check your patch for general style as detailed in
22   :ref:`Documentation/process/coding-style.rst <codingstyle>`.
23
243) All memory barriers {e.g., ``barrier()``, ``rmb()``, ``wmb()``} need a
25   comment in the source code that explains the logic of what they are doing
26   and why.
27
28Review Kconfig changes
29======================
30
311) Any new or modified ``CONFIG`` options do not muck up the config menu and
32   default to off unless they meet the exception criteria documented in
33   ``Documentation/kbuild/kconfig-language.rst`` Menu attributes: default value.
34
352) All new ``Kconfig`` options have help text.
36
373) Has been carefully reviewed with respect to relevant ``Kconfig``
38   combinations.  This is very hard to get right with testing---brainpower
39   pays off here.
40
41Provide documentation
42=====================
43
441) Include :ref:`kernel-doc <kernel_doc>` to document global kernel APIs.
45   (Not required for static functions, but OK there also.)
46
472) All new ``/proc`` entries are documented under ``Documentation/``
48
493) All new kernel boot parameters are documented in
50   ``Documentation/admin-guide/kernel-parameters.rst``.
51
524) All new module parameters are documented with ``MODULE_PARM_DESC()``
53
545) All new userspace interfaces are documented in ``Documentation/ABI/``.
55   See ``Documentation/ABI/README`` for more information.
56   Patches that change userspace interfaces should be CCed to
57   linux-api@vger.kernel.org.
58
596) If any ioctl's are added by the patch, then also update
60   ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
61
62Check your code with tools
63==========================
64
651) Check for trivial violations with the patch style checker prior to
66   submission (``scripts/checkpatch.pl``).
67   You should be able to justify all violations that remain in
68   your patch.
69
702) Check cleanly with sparse.
71
723) Use ``make checkstack`` and fix any problems that it finds.
73   Note that ``checkstack`` does not point out problems explicitly,
74   but any one function that uses more than 512 bytes on the stack is a
75   candidate for change.
76
77Build your code
78===============
79
801) Builds cleanly:
81
82  a) with applicable or modified ``CONFIG`` options ``=y``, ``=m``, and
83     ``=n``.  No ``gcc`` warnings/errors, no linker warnings/errors.
84
85  b) Passes ``allnoconfig``, ``allmodconfig``
86
87  c) Builds successfully when using ``O=builddir``
88
89  d) Any Documentation/ changes build successfully without new warnings/errors.
90     Use ``make htmldocs`` or ``make pdfdocs`` to check the build and
91     fix any issues.
92
932) Builds on multiple CPU architectures by using local cross-compile tools
94   or some other build farm. Note that ppc64 is a good architecture for
95   cross-compilation checking because it tends to use ``unsigned long`` for
96   64-bit quantities.
97
983) Newly-added code has been compiled with ``gcc -W`` (use
99   ``make KCFLAGS=-W``).  This will generate lots of noise, but is good
100   for finding bugs like "warning: comparison between signed and unsigned".
101
1024) If your modified source code depends on or uses any of the kernel
103   APIs or features that are related to the following ``Kconfig`` symbols,
104   then test multiple builds with the related ``Kconfig`` symbols disabled
105   and/or ``=m`` (if that option is available) [not all of these at the
106   same time, just various/random combinations of them]:
107
108   ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
109   ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
110   ``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``).
111
112Test your code
113==============
114
1151) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
116   ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
117   ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
118   ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` all
119   simultaneously enabled.
120
1212) Has been build- and runtime tested with and without ``CONFIG_SMP`` and
122   ``CONFIG_PREEMPT.``
123
1243) All codepaths have been exercised with all lockdep features enabled.
125
1264) Has been checked with injection of at least slab and page-allocation
127   failures.  See ``Documentation/fault-injection/``.
128   If the new code is substantial, addition of subsystem-specific fault
129   injection might be appropriate.
130
1315) Tested with the most recent tag of linux-next to make sure that it still
132   works with all of the other queued patches and various changes in the VM,
133   VFS, and other subsystems.
134