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/admin-guide/abi.rst (or ``Documentation/ABI/README``) 56 for more information. 57 Patches that change userspace interfaces should be CCed to 58 linux-api@vger.kernel.org. 59 606) If any ioctl's are added by the patch, then also update 61 ``Documentation/userspace-api/ioctl/ioctl-number.rst``. 62 63Check your code with tools 64========================== 65 661) Check for trivial violations with the patch style checker prior to 67 submission (``scripts/checkpatch.pl``). 68 You should be able to justify all violations that remain in 69 your patch. 70 712) Check cleanly with sparse. 72 733) Use ``make checkstack`` and fix any problems that it finds. 74 Note that ``checkstack`` does not point out problems explicitly, 75 but any one function that uses more than 512 bytes on the stack is a 76 candidate for change. 77 78Build your code 79=============== 80 811) Builds cleanly: 82 83 a) with applicable or modified ``CONFIG`` options ``=y``, ``=m``, and 84 ``=n``. No ``gcc`` warnings/errors, no linker warnings/errors. 85 86 b) Passes ``allnoconfig``, ``allmodconfig`` 87 88 c) Builds successfully when using ``O=builddir`` 89 90 d) Any Documentation/ changes build successfully without new warnings/errors. 91 Use ``make htmldocs`` or ``make pdfdocs`` to check the build and 92 fix any issues. 93 942) Builds on multiple CPU architectures by using local cross-compile tools 95 or some other build farm. 96 Note that testing against architectures of different word sizes 97 (32- and 64-bit) and different endianness (big- and little-) is effective 98 in catching various portability issues due to false assumptions on 99 representable quantity range, data alignment, or endianness, among 100 others. 101 1023) Newly-added code has been compiled with ``gcc -W`` (use 103 ``make KCFLAGS=-W``). This will generate lots of noise, but is good 104 for finding bugs like "warning: comparison between signed and unsigned". 105 1064) If your modified source code depends on or uses any of the kernel 107 APIs or features that are related to the following ``Kconfig`` symbols, 108 then test multiple builds with the related ``Kconfig`` symbols disabled 109 and/or ``=m`` (if that option is available) [not all of these at the 110 same time, just various/random combinations of them]: 111 112 ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, 113 ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, 114 ``CONFIG_NET``, ``CONFIG_INET=n`` (but latter with ``CONFIG_NET=y``). 115 116Test your code 117============== 118 1191) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, 120 ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, 121 ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, 122 ``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` all 123 simultaneously enabled. 124 1252) Has been build- and runtime tested with and without ``CONFIG_SMP`` and 126 ``CONFIG_PREEMPT.`` 127 1283) All codepaths have been exercised with all lockdep features enabled. 129 1304) Has been checked with injection of at least slab and page-allocation 131 failures. See ``Documentation/fault-injection/``. 132 If the new code is substantial, addition of subsystem-specific fault 133 injection might be appropriate. 134 1355) Tested with the most recent tag of linux-next to make sure that it still 136 works with all of the other queued patches and various changes in the VM, 137 VFS, and other subsystems. 138