| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
doc:it_IT: add some process/* translations This patch does not translate entirely the subfolder "process/" but only part of it (to begin with). In order to avoid broken links, I included empty documents for those which are not yet translated. In order to be able to refer to all documents in "process/", I added a sphinx label to those which had not one. Translated documents: - howto - 1.Intro - clang-format - coding-style - kernel-driver-statement - magic-number - volatile-considered-harmful - development-process Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 7 年前 | |
Documentation: process: Also mention Sasha Levin as stable tree maintainer stable inclusion from stable-v6.6.120 commit 46c73ff89d73de579632c905e5b8f512ea8ee0f8 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8839 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=46c73ff89d73de579632c905e5b8f512ea8ee0f8 -------------------------------- commit ba2457109d5b47a90fe565b39524f7225fc23e60 upstream. Sasha has also maintaining stable branch in conjunction with Greg since cb5d21946d2a2f ("MAINTAINERS: Add Sasha as a stable branch maintainer"). Mention him in 2.Process.rst. Cc: stable@vger.kernel.org Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251022034336.22839-1-bagasdotme@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 46c73ff89d73de579632c905e5b8f512ea8ee0f8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> | 3 个月前 | |
Documentation/process: use scripts/get_maintainer.pl on patches Explain that, when collecting list of people to Cc the patch, scripts/get_maintainer.pl should be used on patches, not on the directories. The behavior is quite different, because with "-f" on a directory, the maintainers of individual files will not be shown. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220427185645.677039-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 4 年前 | |
doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line You should use KCFLAGS to pass additional compiler flags from the command line. Using EXTRA_CFLAGS is wrong. EXTRA_CFLAGS is supposed to specify flags applied only to the current Makefile (and now deprecated in favor of ccflags-y). It is still used in arch/mips/kvm/Makefile (and possibly in external modules too). Passing EXTRA_CFLAGS from the command line overwrites it and breaks the build. I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7 ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS") was based on the same misunderstanding. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it> Link: https://lore.kernel.org/r/20210221152524.197693-1-masahiroy@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 5 年前 | |
docs: process: allow Closes tags with links Since v6.3, checkpatch.pl now complains about the use of "Closes:" tags followed by a link [1]. It also complains if a "Reported-by:" tag is followed by a "Closes:" one [2]. As detailed in the first patch, this "Closes:" tag is used for a bit of time, mainly by DRM and MPTCP subsystems. It is used by some bug trackers to automate the closure of issues when a patch is accepted. It is even planned to use this tag with bugzilla.kernel.org [3]. The first patch updates the documentation to explain what is this "Closes:" tag and how/when to use it. The second patch modifies checkpatch.pl to stop complaining about it. The DRM maintainers and their mailing list have been added in Cc as they are probably interested by these two patches as well. [1] https://lore.kernel.org/all/3b036087d80b8c0e07a46a1dbaaf4ad0d018f8d5.1674217480.git.linux@leemhuis.info/ [2] https://lore.kernel.org/all/bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info/ [3] https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ This patch (of 5): Making sure a bug tracker is up to date is not an easy task. For example, a first version of a patch fixing a tracked issue can be sent a long time after having created the issue. But also, it can take some time to have this patch accepted upstream in its final form. When it is done, someone -- probably not the person who accepted the patch -- has to remember about closing the corresponding issue. This task of closing and tracking the patch can be done automatically by bug trackers like GitLab [1], GitHub [2] and hopefully soon [3] bugzilla.kernel.org when the appropriated tag is used. The two first ones accept multiple tags but it is probably better to pick one. According to commit 76f381bb77a0 ("checkpatch: warn when unknown tags are used for links"), the "Closes" tag seems to have been used in the past by a few people and it is supported by popular bug trackers. Here is how it has been used in the past: $ git log --no-merges --format=email -P --grep='^Closes: http' | \ grep '^Closes: http' | cut -d/ -f3-5 | sort | uniq -c | sort -rn 391 gitlab.freedesktop.org/drm/intel 79 github.com/multipath-tcp/mptcp_net-next 8 gitlab.freedesktop.org/drm/msm 3 gitlab.freedesktop.org/drm/amd 2 gitlab.freedesktop.org/mesa/mesa 1 patchwork.freedesktop.org/series/73320 1 gitlab.freedesktop.org/lima/linux 1 gitlab.freedesktop.org/drm/nouveau 1 github.com/ClangBuiltLinux/linux 1 bugzilla.netfilter.org/show_bug.cgi?id=1579 1 bugzilla.netfilter.org/show_bug.cgi?id=1543 1 bugzilla.netfilter.org/show_bug.cgi?id=1436 1 bugzilla.netfilter.org/show_bug.cgi?id=1427 1 bugs.debian.org/625804 Likely here, the "Closes" tag was only properly used with GitLab and GitHub. We can also see that it has been used quite a few times (and still used recently) and this is then not a "random tag that makes no sense" like it was the case with "BugLink" recently [4]. It has also been misused but that was a long time ago, when it was common to use many different random tags. checkpatch.pl script should then stop complaining about this "Closes" tag. As suggested by Thorsten [5], if this tag is accepted, it should first be described in the documentation. This is what is done here in this patch. To avoid confusion, the "Closes" should be used with any public bug report. No need to check if the underlying bug tracker supports automations. Having this tag with any kind of public bug reports allows bots like regzbot to clearly identify patches fixing a specific bug and avoid false-positives, e.g. patches mentioning it is related to an issue but not fixing it. As suggested by Thorsten [6] again, if we follow the same logic, the "Closes" tag should then be used after a "Reported-by" one. Note that thanks to this "Closes" tag, the mentioned bug trackers can also locate where a patch has been applied in different branches and repositories. If only the "Link" tag is used, the tracking can also be done but the ticket will not be closed and a manual operation will be needed. Also, these bug trackers have some safeguards: the closure is only done if a commit having the "Closes:" tag is applied in a specific branch. It will then not be closed if a random commit having the same tag is published elsewhere. Also in case of closure, a notification is sent to the owners. Link: https://lkml.kernel.org/r/20230314-doc-checkpatch-closes-tag-v4-0-d26d1fa66f9f@tessares.net Link: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#default-closing-pattern [1] Link: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests [2] Link: https://lore.kernel.org/linux-doc/20230315181205.f3av7h6owqzzw64p@meerkat.local/ [3] Link: https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ [4] Link: https://lore.kernel.org/all/688cd6cb-90ab-6834-a6f5-97080e39ca8e@leemhuis.info/ [5] Link: https://lore.kernel.org/linux-doc/2194d19d-f195-1a1e-41fc-7827ae569351@leemhuis.info/ [6] Link: https://github.com/multipath-tcp/mptcp_net-next/issues/373 Link: https://lkml.kernel.org/r/20230314-doc-checkpatch-closes-tag-v4-1-d26d1fa66f9f@tessares.net Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Suggested-by: Thorsten Leemhuis <linux@leemhuis.info> Acked-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Acked-by: Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Bagas Sanjaya <bagasdotme@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kai Wasserbäch <kai@dev.carbon-project.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> | 3 年前 | |
docs: remove the tips on how to submit patches from MAINTAINERS Having "how to submit patches" in MAINTAINTERS seems out of place. We have a whole section of documentation about it, duplication is harmful and a lot of the text looks really out of date. Sections 1, 2 and 4 look really, really old and not applicable to the modern process. Section 3 is obvious but also we have build bots now. Section 5 is a bit outdated (diff -u?!). But I like the part about factoring out shared code, so add that to process docs. Section 6 is unnecessary? Section 7 is covered by more appropriate docs. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20230630171550.128296-1-kuba@kernel.org> | 3 年前 | |
Replace HTTP links with HTTPS ones: documentation Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: For each line: If doesn't contain \bxmlns\b: For each link, \bhttp://[^# \t\r\n]*(?:\w|/): If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Link: https://lore.kernel.org/r/20200526060544.25127-1-grandmaster@al2klimov.de Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 6 年前 | |
docs: process: remove outdated submitting-drivers.rst Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst") in October 2016 already warns "This (...) should maybe just be deleted, but I'm not quite ready to do that yet". Maybe, six years ago, we were not ready but let us remove old content for the better now and structure and maintain less content in the kernel documentation with a better result. Drop this already outdated document and adjust all textual references. Here is an argument why deleting the content will not remove any useful information to the existing kernel documentation, individually broken down for each section. Section "Allocating Device Numbers" refers to https://www.lanana.org/, and then refers to Documentation/admin-guide/devices.rst. However, the devices.rst clearly states: "The version of this document at lanana.org is no longer maintained." Everything needed for submitting drivers is already stated in devices.rst and the reference to https://www.lanana.org/ is outdated, and should be just deleted. Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before the new release version scheme; the mentioned developers are still around, but actually not the first developers to contact anymore. Section "What Criteria Determine Acceptance" has a few bullet points: Licensing and Copyright is well-covered in process/kernel-license.rst. Interfaces, Code, Portability, Clarity state some obvious things about ensuring kernel code quality. Control suggests to add a MAINTAINERS entry, which is already mentioned in 6.Followthrough.rst: "... added yourself to the MAINTAINERS file..." PM support states a bit about implementing and testing power management of a driver, it remains an open question where to place that in the process documents. Driver developers interested in power management will find the corresponding part on power management in the kernel documentation anyway. In section "What Criteria Do Not Determine Acceptance", the points Vendor and Author states something basic consequence of the kernel being an open-source community software development. Probably no need to mention it nowadays. Section "Resources" lists resources that are also mentioned elsewhere more central. - Linux kernel tree and mailing list is mentioned in many places. - https://lwn.net/Kernel/LDD3/ is mentioned in Documentation/process/kernel-docs.rst. - https://lwn.net/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - https://kernelnewbies.org/ is mentioned in: - Documentation/process/8.Conclusion.rst - Documentation/process/kernel-docs.rst - http://www.linux-usb.org/ is mentioned in Documentation/driver-api/usb/usb.rst - https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf is mentioned in Documentation/process/kernel-docs.rst - https://kernelnewbies.org/KernelJanitors is mentioned in Documentation/process/howto.rst - https://git-scm.com/ is mentioned in - Documentation/process/2.Process.rst - Documentation/process/7.AdvancedTopics.rst - Documentation/process/howto.rst Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20220704122537.3407-7-lukas.bulwahn@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
docs: Make syscalls' helpers naming consistent The documentation explains the need to create internal syscalls' helpers, and that they should be called kern_xyzzy(). However, the comment at include/linux/syscalls.h says that they should be named as ksys_xyzzy(), and so are all the helpers declared bellow it. Change the documentation to reflect this. Fixes: 819671ff849b ("syscalls: define and explain goal to not call syscalls in the kernel") Signed-off-by: André Almeida <andrealmeid@collabora.com> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net> Link: https://lore.kernel.org/r/20210130014547.123006-1-andrealmeid@collabora.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 5 年前 | |
Documentation: describe how to apply incremental stable patches The applying patches document (Documentation/process/applying-patches.rst) mentions incremental stable patches, but there is no example of how to apply them. Describe the process. While at it, remove note about incremental patches and move the external link of 5.x.y incremental patches to "Where can I download patches?" section. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20220307063340.256671-1-bagasdotme@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 4 年前 | |
Documentation: Fix typos Fix typos in Documentation. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 2 年前 | |
rust: upgrade to Rust 1.73.0 stable inclusion from stable-v6.6.17 commit 73596f5ab35f07bd94010c28aa48f303e5f1a71f bugzilla: https://gitee.com/openeuler/kernel/issues/I99TJK Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=73596f5ab35f07bd94010c28aa48f303e5f1a71f -------------------------------- commit e08ff622c91af997cb89bc47e90a1a383e938bd0 upstream. This is the next upgrade to the Rust toolchain, from 1.72.1 to 1.73.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). # Unstable features No unstable features (that we use) were stabilized. Therefore, the only unstable feature allowed to be used outside the kernel crate is still new_uninit, though other code to be upstreamed may increase the list. Please see [3] for details. # Required changes For the upgrade, the following changes are required: - Allow internal_features for feature(compiler_builtins) since now Rust warns about using internal compiler and standard library features (similar to how it also warns about incomplete ones) [4]. - A cleanup for a documentation link thanks to a new rustdoc lint. See previous commits for details. - A need to make an intra-doc link to a macro explicit, due to a change in behavior in rustdoc. See previous commits for details. # alloc upgrade and reviewing The vast majority of changes are due to our alloc fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream alloc and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of alloc we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the new.patch to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1730-2023-10-05 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://github.com/Rust-for-Linux/linux/issues/2 [3] Link: https://github.com/rust-lang/compiler-team/issues/596 [4] Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20231005210556.466856-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: ZhangPeng <zhangpeng362@huawei.com> | 2 年前 | |
Documentation: fix typos found in process, dev-tools, and doc-guide subdirectories Fix four typos in kcov.rst, sphinx.rst, clang-format.rst, and embargoed-hardware-issues.rst Signed-off-by: Andrew Klychkov <andrew.a.klychkov@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20201202075438.GA35516@spblnx124.lan Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 5 年前 | |
docs: update mediator contact information in CoC doc Update mediator contact information in CoC interpretation document. Cc: <stable@vger.kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20221011171417.34286-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
Code of Conduct: Change the contact email address The contact point for the kernel's Code of Conduct should now be the Code of Conduct Committee, not the full TAB. Change the email address in the file to properly reflect this. Acked-by: Chris Mason <clm@fb.com> Acked-by: Olof Johansson <olof@lixom.net> Acked-by: Theodore Ts'o <tytso@mit.edu> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 7 年前 | |
coding-style: fix title of Greg K-H's talk The talk title was inadvertently mangled in 8c27ceff3604 ("docs: fix locations of several documents that got moved"). Signed-off-by: Jakub Wilk <jwilk@jwilk.net> Link: https://lore.kernel.org/r/20230322215311.6579-1-jwilk@jwilk.net Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
Documentation/process: Add Linux Kernel Contribution Maturity Model As a follow-up to a discussion at the 2021 Maintainer's Summit on the topic of maintainer recruitment and retention, the TAB took on the task of creating a document which to help companies and other organizations to grow in their ability to engage with the Linux Kernel development community, using the Maturity Model[2] framework. The goal is to encourage, in a management-friendly way, companies to allow their engineers to contribute with the upstream Linux Kernel development community, so we can grow the "talent pipeline" for contributors to become respected leaders, and eventually kernel maintainers. [1] https://lwn.net/Articles/870581/ [2] https://en.wikipedia.org/wiki/Maturity_model Signed-off-by: Theodore Ts'o <tytso@mit.edu> Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Co-developed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230308190403.2157046-1-tytso@mit.edu Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
docs: deprecated.rst: Update an example vmalloc() has a 2-factor form. It is vmalloc_array(). So use another function as an example. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/3484e46180dd2cf05d993ff1a78b481bc2ad1f71.1687723931.git.christophe.jaillet@wanadoo.fr | 2 年前 | |
docs: rename development-process/ to process/ As we'll type this a lot, after adding CodingStyle & friends, let's rename the directory name to a shorter one. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> | 9 年前 | |
Documentation: process: Document suitability of Proton Mail for kernel development Proton Mail automatically picks up PGP keys for those with kernel.org accounts (and other domains!) which provide WKD for their users & uses them to encrypt emails, including patches. Document the behaviour & Proton Mail's unsuitability for kernel development. Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221231152320.1340874-1-conor@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
Documentation: embargoed-hardware-issues.rst: Clarify prenotifaction There has been a repeated misunderstanding about what the hardware embargo list is for. Clarify the language in the process so that it is clear that only fixes are coordinated. There is explicitly no prenotification process. The list members are also expected to keep total radio silence during embargoes. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: workflows@vger.kernel.org Cc: linux-doc@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231004004959.work.258-kees@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
docs: handling-regressions: rework section about fixing procedures This basically rewrites the 'Prioritize work on fixing regressions' section of Documentation/process/handling-regressions.rst for various reasons. Among them: some things were too demanding, some didn't align well with the usual workflows, and some apparently were not clear enough -- and of course a few things were missing that would be good to have in there. Linus for example recently stated that regressions introduced during the past year should be handled similarly to regressions from the current cycle, if it's a clear fix with no semantic subtlety. His exact wording[1] didn't fit well into the text structure, but the author tried to stick close to the apparent intention. It was a noble goal from the original author to state "[prevent situations that might force users to] continue running an outdated and thus potentially insecure kernel version for more than two weeks after a regression's culprit was identified"; this directly led to the goal "fix regression in mainline within one week, if the issue made it into a stable/longterm kernel", because the stable team needs time to pick up and prepare a new release. But apparently all that was a bit too demanding. That "one week" target for example doesn't align well with the usual habits of the subsystem maintainers, which normally send their fixes to Linus once a week; and it doesn't align too well with stable/longterm releases either, which often enter a -rc phase on Mondays or Tuesdays and then are released two to three days later. And asking developers to create, review, and mainline fixes within one week might be too much to ask for in general. Hence tone the general goal down to three weeks and use an approach that better aligns with the usual merging and release habits. While at it, also make the rules of thumb a bit easier to follow by grouping them by topic (e.g. generic things, timing, procedures, ...). Also add text for a few cases where recent discussions showed they need covering. Among them are multiple points that better explain the relations to stable and longterm kernels and the team that manages them; they and the group seperators are the primary reason why this whole section sadly grew somewhat in the rewrite. The group about those relations led to one addition the author came up with without any precedent from Linus: the text now tells developers to add a stable tag for any regression that made it into a proper mainline release during the past 12 months. This is meant to ensure the stable team will definitely notice any fixes for recent regressions. That includes those introduced shortly before a new mainline release and found right after it; without such a rule the stable team might miss the fix, which then would only reach users after weeks or months with later releases. Note, the aspect "Do not consider regressions from the current cycle as something that can wait till the cycle's end [...]" might look like an addition, but was kinda was in the old text as well -- but only indirectly. That apparently was too subtle, as many developers seem to assume waiting till the end of the cycle is fine (even for build fixes). In practice this was especially problematic when a cause of a regression made it into a proper release (either directly or through a backport). A revert performed by Linus shortly before the 6.3 release illustrated that[2], as the developer of the culprit had been willing to revert the culprit about three weeks earlier already -- but didn't do so when a fix came into sight and a maintainer suggested it can wait. Due to that the issue in the end plagued users of 6.2.y at least two weeks longer than necessary, as the fix in the end didn't become ready in time. This issue in fact could have been resolved one or two additional weeks earlier, if the developer had reverted the culprit shortly after it had been identified (which even the old version of the text suggest to do in such cases). [1] https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ [2] https://lore.kernel.org/all/CAHk-=wgD98pmSK3ZyHk_d9kZ2bhgN6DuNZMAJaV0WTtbkf=RDw@mail.gmail.com/ CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg KH <gregkh@linuxfoundation.org> CC: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/6971680941a5b7b9cb0c2839c75b5cc4ddb2d162.1684139586.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
Documentation/security-bugs: move from admin-guide/ to process/ Jiri Kosina, Jonathan Corbet, and Willy Tarreau all expressed a desire to move this document under process/. Create a new section for security issues in the index and group it with embargoed-hardware-issues. I'm doing this at the start of the series to make all the subsequent changes show up in 'git blame'. Existing references were updated using: git grep -l security-bugs ':!Documentation/translations/' | xargs sed -i 's|admin-guide/security-bugs|process/security-bugs|g' git grep -l security-bugs Documentation/translations/ | xargs sed -i 's|Documentation/admin-guide/security-bugs|Documentation/process/security-bugs|g' git grep -l security-bugs Documentation/translations/ | xargs sed -i '/Original:/s|\.\./admin-guide/security-bugs|\.\./process/security-bugs|g' Notably, the page is not moved in the translations (due to my lack of knowledge of these languages), but the translations have been updated to point to the new location of the original document where these references exist. Link: https://lore.kernel.org/all/nycvar.YFH.7.76.2206062326230.10851@cbobk.fhfr.pm/ Suggested-by: Jiri Kosina <jikos@kernel.org> Cc: Alex Shi <alexs@kernel.org> Cc: Yanteng Si <siyanteng@loongson.cn> Cc: Hu Haowen <src.res@email.cn> Cc: Federico Vaga <federico.vaga@vaga.pv.it> Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Jeimi Lee <jamee.lee@samsung.com> Cc: Carlos Bilbao <carlos.bilbao@amd.com> Cc: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Acked-by: Carlos Bilbao <carlos.bilbao@amd.com> Reviewed-by: Yanteng Si <siyanteng@loongson.cn> Reviewed-by: Akira Yokosawa <akiyks@gmail.com> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20230305220010.20895-2-vegard.nossum@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
Merge tag 'docs-6.4' of git://git.lwn.net/linux Pull documentation updates from Jonathan Corbet: "Commit volume in documentation is relatively low this time, but there is still a fair amount going on, including: - Reorganize the architecture-specific documentation under Documentation/arch This makes the structure match the source directory and helps to clean up the mess that is the top-level Documentation directory a bit. This work creates the new directory and moves x86 and most of the less-active architectures there. The current plan is to move the rest of the architectures in 6.5, with the patches going through the appropriate subsystem trees. - Some more Spanish translations and maintenance of the Italian translation - A new "Kernel contribution maturity model" document from Ted - A new tutorial on quickly building a trimmed kernel from Thorsten Plus the usual set of updates and fixes" * tag 'docs-6.4' of git://git.lwn.net/linux: (47 commits) media: Adjust column width for pdfdocs media: Fix building pdfdocs docs: clk: add documentation to log which clocks have been disabled docs: trace: Fix typo in ftrace.rst Documentation/process: always CC responsible lists docs: kmemleak: adjust to config renaming ELF: document some de-facto PT_* ABI quirks Documentation: arm: remove stih415/stih416 related entries docs: turn off "smart quotes" in the HTML build Documentation: firmware: Clarify firmware path usage docs/mm: Physical Memory: Fix grammar Documentation: Add document for false sharing dma-api-howto: typo fix docs: move m68k architecture documentation under Documentation/arch/ docs: move parisc documentation under Documentation/arch/ docs: move ia64 architecture docs under Documentation/arch/ docs: Move arc architecture docs under Documentation/arch/ docs: move nios2 documentation under Documentation/arch/ docs: move openrisc documentation under Documentation/arch/ docs: move superh documentation under Documentation/arch/ ... | 3 年前 | |
Documentation: Fix typos Fix typos in Documentation. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 2 年前 | |
doc:it_IT: add some process/* translations This patch does not translate entirely the subfolder "process/" but only part of it (to begin with). In order to avoid broken links, I included empty documents for those which are not yet translated. In order to be able to refer to all documents in "process/", I added a sphinx label to those which had not one. Translated documents: - howto - 1.Intro - clang-format - coding-style - kernel-driver-statement - magic-number - volatile-considered-harmful - development-process Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 7 年前 | |
Documentation: drop optional BOMs A few of the Documentation .rst files begin with a Unicode byte order mark (BOM). The BOM may signify endianess for 16-bit or 32-bit encodings or indicate that the text stream is indeed Unicode. We don't need it for either of those uses. It may also interfere with (confuse) some software. Since we don't need it and its use is optional, just delete the uses of it in Documentation/. https://en.wikipedia.org/wiki/Byte_order_mark Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Link: https://lore.kernel.org/r/20210506231907.14359-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 5 年前 | |
LICENSES: Rename other to deprecated Make it clear in the directory name that these are not intended for new code. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 7 年前 | |
char: pcmcia: remove all the drivers These char PCMCIA drivers are buggy[1] and receive only minimal care. It was concluded[2], that we should try to remove most pcmcia drivers completely. Let's start with these char broken one. Note that I also removed a UAPI header: include/uapi/linux/cm4000_cs.h. I found only coccinelle tests mentioning some ioctl constants from that file. But they are not actually used. Anyway, should someone complain, we may reintroduce the header (or its parts). [1] https://lore.kernel.org/all/f41c2765-80e0-48bc-b1e4-8cfd3230fd4a@www.fastmail.com/ [2] https://lore.kernel.org/all/c5b39544-a4fb-4796-a046-0b9be9853787@app.fastmail.com/ Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: "Hyunwoo Kim" <imv4bel@gmail.com> Cc: Harald Welte <laforge@gnumonks.org> Cc: Lubomir Rintel <lkundrak@v3.sk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230222092302.6348-2-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 3 年前 | |
Documentation/process: maintainer-soc: add clean platforms profile Some SoC platforms require that commits must not bring any new dtbs_check warnings. Maintainers of such platforms usually have some automation set, so any new warning will be spotted sooner or later. Worst case: they run the tests themselves. Document requirements for such platforms, so contributors can expect their patches being dropped or ignored, if they bring new warnings for existing boards. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230723131924.78190-2-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> | 2 年前 | |
Documentation/process: Add a maintainer handbook for KVM x86 Add a KVM x86 doc to the subsystem/maintainer handbook section to explain how KVM x86 (currently) operates as a sub-subsystem, and to soapbox on the rules and expectations for contributing to KVM x86. Reviewed-by: Like Xu <likexu@tencent.com> Link: https://lore.kernel.org/r/20230411171651.1067966-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> | 3 年前 | |
docs: netdev: update the netdev infra URLs Some corporate proxies block our current NIPA URLs because they use a free / shady DNS domain. As suggested by Jesse we got a new DNS entry from Konstantin - netdev.bots.linux.dev, use it. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> | 2 年前 | |
docs: maintainer-pgp-guide: update for latest gnupg defaults It is finally becoming increasingly rare to find a distribution that still ships with gnupg-1.x, so remove the last vestiges of "gpg" vs "gpg2" from documentation. Similarly, starting with GnuPG 2.2 and above, the default --gen-key operation creates ed25519/cv25519 keypairs, so update all example command outputs to use that combination instead of rsa2048. Lastly, add a few wording tweaks and remove links that lead to stale information (e.g. hardware tokens overview from 2017). Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Link: https://lore.kernel.org/r/20221220-docs-pgp-guide-v1-1-9b0c0bf974fb@linuxfoundation.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
Documentation/process: maintainer-soc: add clean platforms profile Some SoC platforms require that commits must not bring any new dtbs_check warnings. Maintainers of such platforms usually have some automation set, so any new warning will be spotted sooner or later. Worst case: they run the tests themselves. Document requirements for such platforms, so contributors can expect their patches being dropped or ignored, if they bring new warnings for existing boards. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230723131924.78190-2-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> | 2 年前 | |
Documentation/process: maintainer-soc: document dtbs_check requirement for Samsung Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to bring any new dtbs_check warnings. In fact this have been already enforced and tested since few release. Cc: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230712084131.127982-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> | 2 年前 | |
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm updates from Paolo Bonzini: "ARM64: - Eager page splitting optimization for dirty logging, optionally allowing for a VM to avoid the cost of hugepage splitting in the stage-2 fault path. - Arm FF-A proxy for pKVM, allowing a pKVM host to safely interact with services that live in the Secure world. pKVM intervenes on FF-A calls to guarantee the host doesn't misuse memory donated to the hyp or a pKVM guest. - Support for running the split hypervisor with VHE enabled, known as 'hVHE' mode. This is extremely useful for testing the split hypervisor on VHE-only systems, and paves the way for new use cases that depend on having two TTBRs available at EL2. - Generalized framework for configurable ID registers from userspace. KVM/arm64 currently prevents arbitrary CPU feature set configuration from userspace, but the intent is to relax this limitation and allow userspace to select a feature set consistent with the CPU. - Enable the use of Branch Target Identification (FEAT_BTI) in the hypervisor. - Use a separate set of pointer authentication keys for the hypervisor when running in protected mode, as the host is untrusted at runtime. - Ensure timer IRQs are consistently released in the init failure paths. - Avoid trapping CTR_EL0 on systems with Enhanced Virtualization Traps (FEAT_EVT), as it is a register commonly read from userspace. - Erratum workaround for the upcoming AmpereOne part, which has broken hardware A/D state management. RISC-V: - Redirect AMO load/store misaligned traps to KVM guest - Trap-n-emulate AIA in-kernel irqchip for KVM guest - Svnapot support for KVM Guest s390: - New uvdevice secret API - CMM selftest and fixes - fix racy access to target CPU for diag 9c x86: - Fix missing/incorrect #GP checks on ENCLS - Use standard mmu_notifier hooks for handling APIC access page - Drop now unnecessary TR/TSS load after VM-Exit on AMD - Print more descriptive information about the status of SEV and SEV-ES during module load - Add a test for splitting and reconstituting hugepages during and after dirty logging - Add support for CPU pinning in demand paging test - Add support for AMD PerfMonV2, with a variety of cleanups and minor fixes included along the way - Add a "nx_huge_pages=never" option to effectively avoid creating NX hugepage recovery threads (because nx_huge_pages=off can be toggled at runtime) - Move handling of PAT out of MTRR code and dedup SVM+VMX code - Fix output of PIC poll command emulation when there's an interrupt - Add a maintainer's handbook to document KVM x86 processes, preferred coding style, testing expectations, etc. - Misc cleanups, fixes and comments Generic: - Miscellaneous bugfixes and cleanups Selftests: - Generate dependency files so that partial rebuilds work as expected" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (153 commits) Documentation/process: Add a maintainer handbook for KVM x86 Documentation/process: Add a label for the tip tree handbook's coding style KVM: arm64: Fix misuse of KVM_ARM_VCPU_POWER_OFF bit index RISC-V: KVM: Remove unneeded semicolon RISC-V: KVM: Allow Svnapot extension for Guest/VM riscv: kvm: define vcpu_sbi_ext_pmu in header RISC-V: KVM: Expose IMSIC registers as attributes of AIA irqchip RISC-V: KVM: Add in-kernel virtualization of AIA IMSIC RISC-V: KVM: Expose APLIC registers as attributes of AIA irqchip RISC-V: KVM: Add in-kernel emulation of AIA APLIC RISC-V: KVM: Implement device interface for AIA irqchip RISC-V: KVM: Skeletal in-kernel AIA irqchip support RISC-V: KVM: Set kvm_riscv_aia_nr_hgei to zero RISC-V: KVM: Add APLIC related defines RISC-V: KVM: Add IMSIC related defines RISC-V: KVM: Implement guest external interrupt line management KVM: x86: Remove PRIx* definitions as they are solely for user space s390/uv: Update query for secret-UVCs s390/uv: replace scnprintf with sysfs_emit s390/uvdevice: Add 'Lock Secret Store' UVC ... | 3 年前 | |
doc-rst: Programmatically render MAINTAINERS into ReST 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 <keescook@chromium.org> Reviewer: Andy Lutomirski <luto@amacapital.net>, Will Drewry <wad@chromium.org> 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 <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 6 年前 | |
Documentation: management-style: Fix formatting of emphsized word Commit 7f2b3c65b9a1 ("Documentation/ManagementStyle: convert it to ReST markup") converted _underlined_ to *emphasized* words, but forgot about an underscore in this case. Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20200303192113.20761-1-j.neuschaefer@gmx.net Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 6 年前 | |
docs: programming-language: add Rust programming language section Following the C text in the file, add a mention about the Rust programming language, the currently supported compiler and the edition used (similar to the "dialect" mention for C). Similarly, add a mention about the unstable features used (similar to the "extensions" mentions for C). In addition, add some links to complement the information. Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20230306191712.230658-2-ojeda@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 3 年前 | |
docs: Add a section on surveys to the researcher guidelines It is common for university researchers to want to poll the community with online surveys, but that approach distracts developers while yielding little in the way of useful data. Encourage alternatives instead. Co-developed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/87il9v7u55.fsf@meer.lwn.net | 2 年前 | |
Documentation: security-bugs.rst: clarify CVE handling The kernel security team does NOT assign CVEs, so document that properly and provide the "if you want one, ask MITRE for it" response that we give on a weekly basis in the document, so we don't have to constantly say it to everyone who asks. Link: https://lore.kernel.org/r/2023063022-retouch-kerosene-7e4a@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
doc: process: GPL -> GPL-compatible Drivers under MIT, BSD-17-clause, or uncle-Bob's-newest-take-on-PD are all fine, not just GPL. Signed-off-by: Adam Borowski <kilobyte@angband.pl> [jc: fixed conflict and refilled paragraph] Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 7 年前 | |
docs: stable-kernel-rules: mention that regressions must be prevented Document that changes intended for a specific stable series have to be in all newer series still maintained, as otherwise users would run into regressions. CC: Greg KH <gregkh@linuxfoundation.org> CC: Sasha Levin <sashal@kernel.org> CC: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Link: https://lore.kernel.org/r/ddb5cb0d6b7aa4ef31642cd9657a0fb53d79cddb.1691219455.git.linux@leemhuis.info Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2 年前 | |
doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line You should use KCFLAGS to pass additional compiler flags from the command line. Using EXTRA_CFLAGS is wrong. EXTRA_CFLAGS is supposed to specify flags applied only to the current Makefile (and now deprecated in favor of ccflags-y). It is still used in arch/mips/kvm/Makefile (and possibly in external modules too). Passing EXTRA_CFLAGS from the command line overwrites it and breaks the build. I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7 ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in EXTRA_CFLAGS") was based on the same misunderstanding. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com> Acked-by: Federico Vaga <federico.vaga@vaga.pv.it> Link: https://lore.kernel.org/r/20210221152524.197693-1-masahiroy@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 5 年前 | |
docs: submitting-patches: Discuss interleaved replies Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230511184131.gonna.399-kees@kernel.org | 3 年前 | |
Replace HTTP links with HTTPS ones: documentation Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: For each line: If doesn't contain \bxmlns\b: For each link, \bhttp://[^# \t\r\n]*(?:\w|/): If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Link: https://lore.kernel.org/r/20200526060544.25127-1-grandmaster@al2klimov.de Signed-off-by: Jonathan Corbet <corbet@lwn.net> | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 7 年前 | ||
| 3 个月前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 9 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 7 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 6 年前 |