kernel/linux.git/Documentation/process/index.rst, branch v5.19

Documentation/process: Add Researcher Guidelines

2022-03-09T23:19:23+00:00

As a follow-up to the UMN incident[1], the TAB took the responsibility to document Researcher Guidelines so there would be a common place to point for describing our expectations as a developer community. Document best practices researchers should follow to participate successfully with the Linux developer community. [1] https://lore.kernel.org/lkml/202105051005.49BFABCE@keescook/ Co-developed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Co-developed-by: Jonathan Corbet Co-developed-by: Stefano Zacchiroli Signed-off-by: Stefano Zacchiroli Co-developed-by: Steven Rostedt Signed-off-by: Steven Rostedt Acked-by: Steve Rostedt Acked-by: Laura Abbott Reviewed-by: Julia Lawall Reviewed-by: Wenwen Wang Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220304181418.1692016-1-keescook@chromium.org Signed-off-by: Jonathan Corbet

docs: add two documents about regression handling

2022-02-24T19:57:25+00:00

Create two documents explaining various aspects around regression handling and tracking; one is aimed at users, the other targets developers. The texts among others describes the first rule of Linux kernel development and what it means in practice. They also explain what a regression actually is and how to report one properly. Both texts additionally provide a brief introduction to the bot the kernel's regression tracker uses to facilitate the work, but mention the use is optional. To sum things up, provide a few quotes from Linus in the document for developers to show how serious we take regressions. Signed-off-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/34e56d3588f22d7e0b4d635ef9c9c3b33ca4ac04.1644994117.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet

Documentation/process: Add maintainer handbooks section

2021-09-14T20:46:49+00:00

General rules for patch submission, coding style and related details are available, but most subsystems have their subsystem-specific extra rules which differ or go beyond the common rules. Mark suggested to add a subsystem/maintainer handbook section, where subsystem maintainers can explain their specific quirks. Add the section and link to it from the submitting-patches document. [ bp: Add a SPDX identifier. ] Suggested-by: Mark Brown Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20181107171149.074948887@linutronix.de Link: https://lore.kernel.org/r/20210913153942.15251-2-bp@alien8.de Signed-off-by: Jonathan Corbet

docs: process/index.rst: Fix reference to nonexistent document

2020-07-23T20:26:12+00:00

Fix the following warning: WARNING: toctree contains reference to nonexistent document 'process/unaligned-memory-access' The path to the document was wrong. Signed-off-by: Daniel W. S. Almeida Link: https://lore.kernel.org/r/20200718165107.625847-5-dwlsalmeida@gmail.com Signed-off-by: Jonathan Corbet

docs: sysctl/kernel: document unaligned controls

2020-05-26T00:59:59+00:00

This documents ignore-unaligned-usertrap, unaligned-dump-stack, and unaligned-trap, based on arch/arc/kernel/unaligned.c, arch/ia64/kernel/unaligned.c, and arch/parisc/kernel/unaligned.c. While we're at it, integrate unaligned-memory-access.txt into the docs tree. Signed-off-by: Stephen Kitt Link: https://lore.kernel.org/r/20200515212443.5012-1-steve@sk2.org Signed-off-by: Jonathan Corbet

Documentation: riscv: add patch acceptance guidelines

2020-01-05T05:49:01+00:00

Formalize, in kernel documentation, the patch acceptance policy for arch/riscv. In summary, it states that as maintainers, we plan to only accept patches for new modules or extensions that have been frozen or ratified by the RISC-V Foundation. We've been following these guidelines for the past few months. In the meantime, we've received quite a bit of feedback that it would be helpful to have these guidelines formally documented. Based on a suggestion from Matthew Wilcox, we also add a link to this file to Documentation/process/index.rst, to make this document easier to find. The format of this document has also been changed to align to the format outlined in the maintainer entry profiles, in accordance with comments from Jon Corbet and Dan Williams. Signed-off-by: Paul Walmsley Reviewed-by: Palmer Dabbelt Cc: Palmer Dabbelt Cc: Albert Ou Cc: Krste Asanovic Cc: Andrew Waterman Cc: Matthew Wilcox Cc: Dan Williams Cc: Jonathan Corbet

docs: move botching-up-ioctls.rst to the process guide

2019-10-10T17:21:48+00:00

This is overall information for kernel developers, and not part of the user-space API. Cc: Daniel Vetter Signed-off-by: Jonathan Corbet

doc-rst: Programmatically render MAINTAINERS into ReST

2019-10-02T16:03:17+00:00

In order to have the MAINTAINERS file visible in the rendered ReST output, this makes some small changes to the existing MAINTAINERS file to allow for better machine processing, and adds a new Sphinx directive "maintainers-include" to perform the rendering. Features include: - Per-subsystem reference links: subsystem maintainer entries can be trivially linked to both internally and external. For example: https://www.kernel.org/doc/html/latest/process/maintainers.html#secure-computing - Internally referenced .rst files are linked so they can be followed when browsing the resulting rendering. This allows, for example, the future addition of maintainer profiles to be automatically linked. - Field name expansion: instead of the short fields (e.g. "M", "F", "K"), use the indicated inline "full names" for the fields (which are marked with "*"s in MAINTAINERS) so that a rendered subsystem entry is more human readable. Email lists are additionally comma-separated. For example: SECURE COMPUTING Mail: Kees Cook Reviewer: Andy Lutomirski , Will Drewry SCM: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp Status: Supported Files: kernel/seccomp.c include/uapi/linux/seccomp.h include/linux/seccomp.h tools/testing/selftests/seccomp/* tools/testing/selftests/kselftest_harness.h userspace-api/seccomp_filter Content regex: \bsecure_computing \bTIF_SECCOMP\b Signed-off-by: Kees Cook Signed-off-by: Jonathan Corbet

Documentation/process: Embargoed hardware security issues

2019-08-28T20:36:07+00:00

To address the requirements of embargoed hardware issues, like Meltdown, Spectre, L1TF etc. it is necessary to define and document a process for handling embargoed hardware security issues. Following the discussion at the maintainer summit 2018 in Edinburgh (https://lwn.net/Articles/769417/) the volunteered people have worked out a process and a Memorandum of Understanding. The latter addresses the fact that the Linux kernel community cannot sign NDAs for various reasons. The initial contact point for hardware security issues is different from the regular kernel security contact to provide a known and neutral interface for hardware vendors and researchers. The initial primary contact team is proposed to be staffed by Linux Foundation Fellows, who are not associated to a vendor or a distribution and are well connected in the industry as a whole. The process is designed with the experience of the past incidents in mind and tries to address the remaining gaps, so future (hopefully rare) incidents can be handled more efficiently. It won't remove the fact, that most of this has to be done behind closed doors, but it is set up to avoid big bureaucratic hurdles for individual developers. The process is solely for handling hardware security issues and cannot be used for regular kernel (software only) security bugs. This memo can help with hardware companies who, and I quote, "[my manager] doesn't want to bet his job on the list keeping things secret." This despite numerous leaks directly from that company over the years, and none ever so far from the kernel security team. Cognitive dissidence seems to be a requirement to be a good manager. To accelerate the adoption of this process, we introduce the concept of ambassadors in participating companies. The ambassadors are there to guide people to comply with the process, but are not automatically involved in the disclosure of a particular incident. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Josh Poimboeuf Acked-by: Laura Abbott Acked-by: Ben Hutchings Reviewed-by: Tyler Hicks Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Jiri Kosina Link: https://lore.kernel.org/r/20190815212505.GC12041@kroah.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'compiler-attributes-for-linus-4.20-rc1' of https://github.com/ojeda/linux

2018-11-02T01:34:46+00:00

Pull compiler attribute updates from Miguel Ojeda: "This is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION), which are compiler-agnostic (so they can be shared, reducing the size of compiler-specific headers) and version-agnostic. Other related improvements have been performed in the headers as well, which on top of the use of __has_attribute it has amounted to a significant simplification of these headers (e.g. GCC_VERSION is now only guarding a few non-attribute macros). This series should also help the efforts to support compiling the kernel with clang and icc. A fair amount of documentation and comments have also been added, clarified or removed; and the headers are now more readable, which should help kernel developers in general. The series was triggered due to the move to gcc >= 4.6. In turn, this series has also triggered Sparse to gain the ability to recognize __has_attribute on its own. Finally, the __nonstring variable attribute series has been also applied on top; plus two related patches from Nick Desaulniers for unreachable() that came a bit afterwards" * tag 'compiler-attributes-for-linus-4.20-rc1' of https://github.com/ojeda/linux: compiler-gcc: remove comment about gcc 4.5 from unreachable() compiler.h: update definition of unreachable() Compiler Attributes: ext4: remove local __nonstring definition Compiler Attributes: auxdisplay: panel: use __nonstring Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8) Compiler Attributes: add support for __nonstring (gcc >= 8) Compiler Attributes: add MAINTAINERS entry Compiler Attributes: add Doc/process/programming-language.rst Compiler Attributes: remove uses of __attribute__ from compiler.h Compiler Attributes: KENTRY used twice the "used" attribute Compiler Attributes: use feature checks instead of version checks Compiler Attributes: add missing SPDX ID in compiler_types.h Compiler Attributes: remove unneeded sparse (__CHECKER__) tests Compiler Attributes: homogenize __must_be_array Compiler Attributes: remove unneeded tests Compiler Attributes: always use the extra-underscores syntax Compiler Attributes: remove unused attributes