summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
5 daysLinux 6.15.11v6.15.11Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250818124458.334548733@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250819122834.836683687@linuxfoundation.org Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <floria.fainelli@broadcom.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 daysLinux 6.15.10v6.15.10Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250812174357.281828096@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-By: Achill Gilgenast <achill@achill.org>= Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-01Linux 6.15.9v6.15.9Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250730093230.629234025@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-24Linux 6.15.8v6.15.8Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250722134345.761035548@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Pascal Ernster <git@hardfalcon.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-17Linux 6.15.7v6.15.7Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250715130814.854109770@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Dileep Malepu <dileep.debian@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Markus Reichelt <lkt+2023@mareichelt.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-10Linux 6.15.6v6.15.6Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250708162236.549307806@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Christian Heusel <christian@heusel.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-06Linux 6.15.5v6.15.5Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250703144004.276210867@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Pascal Ernster <git@hardfalcon.net> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Markus Reichelt <lkt+2023@mareichelt.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250704125604.759558342@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Markus Reichelt <lkt+2023@mareichelt.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Pascal Ernster <git@hardfalcon.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27Linux 6.15.4v6.15.4Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250623130700.210182694@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Link: https://lore.kernel.org/r/20250624121449.136416081@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250626105243.160967269@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19Linux 6.15.3v6.15.3Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250617152451.485330293@linuxfoundation.org Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-10Linux 6.15.2v6.15.2Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250607100719.711372213@linuxfoundation.org Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-04Linux 6.15.1v6.15.1Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250602134237.940995114@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-25Linux 6.15v6.15Linus Torvalds1-1/+1
2025-05-18Linux 6.15-rc7v6.15-rc7Linus Torvalds1-1/+1
2025-05-12Revert "kbuild, rust: use -fremap-path-prefix to make paths relative"Thomas Weißschuh1-1/+0
This reverts commit dbdffaf50ff9cee3259a7cef8a7bd9e0f0ba9f13. --remap-path-prefix breaks the ability of debuggers to find the source file corresponding to object files. As there is no simple or uniform way to specify the source directory explicitly, this breaks developers workflows. Revert the unconditional usage of --remap-path-prefix, equivalent to the same change for -ffile-prefix-map in KBUILD_CPPFLAGS. Fixes: dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-05-12Revert "kbuild: make all file references relative to source root"Thomas Weißschuh1-1/+1
This reverts commit cacd22ce69585a91c386243cd662ada962431e63. -ffile-prefix-map breaks the ability of debuggers to find the source file corresponding to object files. As there is no simple or uniform way to specify the source directory explicitly, this breaks developers workflows. Revert the unconditional usage of -ffile-prefix-map. Reported-by: Matthieu Baerts <matttbe@kernel.org> Closes: https://lore.kernel.org/lkml/edc50aa7-0740-4942-8c15-96f12f2acc7e@kernel.org/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/lkml/aBEttQH4kimHFScx@intel.com/ Fixes: cacd22ce6958 ("kbuild: make all file references relative to source root") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-05-11Linux 6.15-rc6v6.15-rc6Linus Torvalds1-1/+1
2025-05-04Linux 6.15-rc5v6.15-rc5Linus Torvalds1-1/+1
2025-04-30kbuild: Properly disable -Wunterminated-string-initialization for clangNathan Chancellor1-7/+0
Clang and GCC have different behaviors around disabling warnings included in -Wall and -Wextra and the order in which flags are specified, which is exposed by clang's new support for -Wunterminated-string-initialization. $ cat test.c const char foo[3] = "FOO"; const char bar[3] __attribute__((__nonstring__)) = "BAR"; $ clang -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ clang -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ clang -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.c test.c:1:21: warning: initializer-string for character array is too long, array size is 3 but initializer has size 4 (including the null terminating character); did you mean to use the 'nonstring' attribute? [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra test.c test.c:1:21: warning: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (4 chars into 3 available) [-Wunterminated-string-initialization] 1 | const char foo[3] = "FOO"; | ^~~~~ $ gcc -fsyntax-only -Wextra -Wno-unterminated-string-initialization test.c $ gcc -fsyntax-only -Wno-unterminated-string-initialization -Wextra test.c Move -Wextra up right below -Wall in Makefile.extrawarn to ensure these flags are at the beginning of the warning options list. Move the couple of warning options that have been added to the main Makefile since commit e88ca24319e4 ("kbuild: consolidate warning flags in scripts/Makefile.extrawarn") to scripts/Makefile.extrawarn after -Wall / -Wextra to ensure they get properly disabled for all compilers. Fixes: 9d7a0577c9db ("gcc-15: disable '-Wunterminated-string-initialization' entirely for now") Link: https://github.com/llvm/llvm-project/issues/10359 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-27Linux 6.15-rc4v6.15-rc4Linus Torvalds1-1/+1
2025-04-23Fix mis-uses of 'cc-option' for warning disablementLinus Torvalds1-2/+2
This was triggered by one of my mis-uses causing odd build warnings on sparc in linux-next, but while figuring out why the "obviously correct" use of cc-option caused such odd breakage, I found eight other cases of the same thing in the tree. The root cause is that 'cc-option' doesn't work for checking negative warning options (ie things like '-Wno-stringop-overflow') because gcc will silently accept options it doesn't recognize, and so 'cc-option' ends up thinking they are perfectly fine. And it all works, until you have a situation where _another_ warning is emitted. At that point the compiler will go "Hmm, maybe the user intended to disable this warning but used that wrong option that I didn't recognize", and generate a warning for the unrecognized negative option. Which explains why we have several cases of this in the tree: the 'cc-option' test really doesn't work for this situation, but most of the time it simply doesn't matter that ity doesn't work. The reason my recently added case caused problems on sparc was pointed out by Thomas Weißschuh: the sparc build had a previous explicit warning that then triggered the new one. I think the best fix for this would be to make 'cc-option' a bit smarter about this sitation, possibly by adding an intentional warning to the test case that then triggers the unrecognized option warning reliably. But the short-term fix is to replace 'cc-option' with an existing helper designed for this exact case: 'cc-disable-warning', which picks the negative warning but uses the positive form for testing the compiler support. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/all/20250422204718.0b4e3f81@canb.auug.org.au/ Explained-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-20gcc-15: disable '-Wunterminated-string-initialization' entirely for nowLinus Torvalds1-2/+2
I had left the warning around but as a non-fatal error to get my gcc-15 builds going, but fixed up some of the most annoying warning cases so that it wouldn't be *too* verbose. Because I like the _concept_ of the warning, even if I detested the implementation to shut it up. It turns out the implementation to shut it up is even more broken than I thought, and my "shut up most of the warnings" patch just caused fatal errors on gcc-14 instead. I had tested with clang, but when I upgrade my development environment, I try to do it on all machines because I hate having different systems to maintain, and hadn't realized that gcc-14 now had issues. The ACPI case is literally why I wanted to have a *type* that doesn't trigger the warning (see commit d5d45a7f2619: "gcc-15: make 'unterminated string initialization' just a warning"), instead of marking individual places as "__nonstring". But gcc-14 doesn't like that __nonstring location that shut gcc-15 up, because it's on an array of char arrays, not on one single array: drivers/acpi/tables.c:399:1: error: 'nonstring' attribute ignored on objects of type 'const char[][4]' [-Werror=attributes] 399 | static const char table_sigs[][ACPI_NAMESEG_SIZE] __initconst __nonstring = { | ^~~~~~ and my attempts to nest it properly with a type had failed, because of how gcc doesn't like marking the types as having attributes, only symbols. There may be some trick to it, but I was already annoyed by the bad attribute design, now I'm just entirely fed up with it. I wish gcc had a proper way to say "this type is a *byte* array, not a string". The obvious thing would be to distinguish between "char []" and an explicitly signed "unsigned char []" (as opposed to an implicitly unsigned char, which is typically an architecture-specific default, but for the kernel is universal thanks to '-funsigned-char'). But any "we can typedef a 8-bit type to not become a string just because it's an array" model would be fine. But "__attribute__((nonstring))" is sadly not that sane model. Reported-by: Chris Clayton <chris2553@googlemail.com> Fixes: 4b4bd8c50f48 ("gcc-15: acpi: sprinkle random '__nonstring' crumbles around") Fixes: d5d45a7f2619 ("gcc-15: make 'unterminated string initialization' just a warning") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-20Linux 6.15-rc3v6.15-rc3Linus Torvalds1-1/+1
2025-04-20gcc-15: make 'unterminated string initialization' just a warningLinus Torvalds1-0/+3
gcc-15 enabling -Wunterminated-string-initialization in -Wextra by default was done with the best intentions, but the warning is still quite broken. What annoys me about the warning is that this is a very traditional AND CORRECT way to initialize fixed byte arrays in C: unsigned char hex[16] = "0123456789abcdef"; and we use this all over the kernel. And the warning is fine, but gcc developers apparently never made a reasonable way to disable it. As is (sadly) tradition with these things. Yes, there's "__attribute__((nonstring))", and we have a macro to make that absolutely disgusting syntax more palatable (ie the kernel syntax for that monstrosity is just "__nonstring"). But that attribute is misdesigned. What you'd typically want to do is tell the compiler that you are using a type that isn't a string but a byte array, but that doesn't work at all: warning: ‘nonstring’ attribute does not apply to types [-Wattributes] and because of this fundamental mis-design, you then have to mark each instance of that pattern. This is particularly noticeable in our ACPI code, because ACPI has this notion of a 4-byte "type name" that gets used all over, and is exactly this kind of byte array. This is a sad oversight, because the warning is useful, but really would be so much better if gcc had also given a sane way to indicate that we really just want a byte array type at a type level, not the broken "each and every array definition" level. So now instead of creating a nice "ACPI name" type using something like typedef char acpi_name_t[4] __nonstring; we have to do things like char name[ACPI_NAMESEG_SIZE] __nonstring; in every place that uses this concept and then happens to have the typical initializers. This is annoying me mainly because I think the warning _is_ a good warning, which is why I'm not just turning it off in disgust. But it is hampered by this bad implementation detail. [ And obviously I'm doing this now because system upgrades for me are something that happen in the middle of the release cycle: don't do it before or during travel, or just before or during the busy merge window period. ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-19Merge tag 'rust-fixes-6.15' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Fix missing KASAN LLVM flags on first build (and fix spurious rebuilds) by skipping '--target' - Fix Make < 4.3 build error by using '$(pound)' - Fix UML build error by removing 'volatile' qualifier from io helpers - Fix UML build error by adding 'dma_{alloc,free}_attrs()' helpers - Clean gendwarfksyms warnings by avoiding to export '__pfx' symbols - Clean objtool warning by adding a new 'noreturn' function for 1.86.0 - Disable 'needless_continue' Clippy lint due to new 1.86.0 warnings - Add missing 'ffi' crate to 'generate_rust_analyzer.py' 'pin-init' crate: - Import a couple fixes from upstream" * tag 'rust-fixes-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: helpers: Add dma_alloc_attrs() and dma_free_attrs() rust: helpers: Remove volatile qualifier from io helpers rust: kbuild: use `pound` to support GNU Make < 4.3 objtool/rust: add one more `noreturn` Rust function for Rust 1.86.0 rust: kasan/kbuild: fix missing flags on first build rust: disable `clippy::needless_continue` rust: kbuild: Don't export __pfx symbols rust: pin-init: use Markdown autolinks in Rust comments rust: pin-init: alloc: restrict `impl ZeroableOption` for `Box` to `T: Sized` scripts: generate_rust_analyzer: Add ffi crate
2025-04-14rust: disable `clippy::needless_continue`Miguel Ojeda1-1/+0
Starting with Rust 1.86.0, Clippy's `needless_continue` lint complains about the last statement of a loop [1], including cases like: while ... { match ... { ... if ... => { ... return ...; } _ => continue, } } as well as nested `match`es in a loop. One solution is changing `continue` for `()` [2], but arguably using `continue` shows the intent better when it is alone in an arm like that. Moreover, I am not sure we want to force people to try to find other ways to write the code either, in cases when that applies. In addition, the help text does not really apply in the new cases the lint has introduced, e.g. here one cannot simply "drop" the expression: warning: this `continue` expression is redundant --> rust/macros/helpers.rs:85:18 | 85 | _ => continue, | ^^^^^^^^ | = help: consider dropping the `continue` expression = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_continue = note: requested on the command line with `-W clippy::needless-continue` The examples in the documentation do not show a case like this, either, so the second "help" line does not help. In addition, locally disabling the lint is not possible with `expect`, since the behavior differs across versions. Using `allow` would be possible, but, even then, an extra line just for this is a bit too much, especially if there are other ways to satisfy the lint. Finally, the lint is still in the "pedantic" category and disabled by default by Clippy. Thus disable the lint, at least for the time being. Feedback was submitted to upstream Clippy, in case this can be improved or perhaps the lint split into several [3]. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/13891 [1] Link: https://lore.kernel.org/rust-for-linux/20250401221205.52381-1-ojeda@kernel.org/ [2] Link: https://github.com/rust-lang/rust-clippy/issues/14536 [3] Link: https://lore.kernel.org/r/20250403163805.67770-1-ojeda@kernel.org Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-04-13Linux 6.15-rc2v6.15-rc2Linus Torvalds1-1/+1
2025-04-08kbuild: Add '-fno-builtin-wcslen'Nathan Chancellor1-0/+3
A recent optimization change in LLVM [1] aims to transform certain loop idioms into calls to strlen() or wcslen(). This change transforms the first while loop in UniStrcat() into a call to wcslen(), breaking the build when UniStrcat() gets inlined into alloc_path_with_tree_prefix(): ld.lld: error: undefined symbol: wcslen >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) >>> vmlinux.o:(alloc_path_with_tree_prefix) Disable this optimization with '-fno-builtin-wcslen', which prevents the compiler from assuming that wcslen() is available in the kernel's C library. [ More to the point - it's not that we couldn't implement wcslen(), it's that this isn't an optimization at all in the context of the kernel. Replacing a simple inlined loop with a function call to the same loop is just stupid and pointless if you don't have long strings and fancy libraries with vectorization support etc. For the regular 'strlen()' cases, we want the compiler to do this in order to handle the trivial case of constant strings. And we do have optimized versions of 'strlen()' on some architectures. But for wcslen? Just no. - Linus ] Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-06Linux 6.15-rc1v6.15-rc1Linus Torvalds1-2/+2
2025-04-05Merge tag 'kbuild-v6.15' of ↵Linus Torvalds1-7/+16
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Improve performance in gendwarfksyms - Remove deprecated EXTRA_*FLAGS and KBUILD_ENABLE_EXTRA_GCC_CHECKS - Support CONFIG_HEADERS_INSTALL for ARCH=um - Use more relative paths to sources files for better reproducibility - Support the loong64 Debian architecture - Add Kbuild bash completion - Introduce intermediate vmlinux.unstripped for architectures that need static relocations to be stripped from the final vmlinux - Fix versioning in Debian packages for -rc releases - Treat missing MODULE_DESCRIPTION() as an error - Convert Nios2 Makefiles to use the generic rule for built-in DTB - Add debuginfo support to the RPM package * tag 'kbuild-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (40 commits) kbuild: rpm-pkg: build a debuginfo RPM kconfig: merge_config: use an empty file as initfile nios2: migrate to the generic rule for built-in DTB rust: kbuild: skip `--remap-path-prefix` for `rustdoc` kbuild: pacman-pkg: hardcode module installation path kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally modpost: require a MODULE_DESCRIPTION() kbuild: make all file references relative to source root x86: drop unnecessary prefix map configuration kbuild: deb-pkg: add comment about future removal of KDEB_COMPRESS kbuild: Add a help message for "headers" kbuild: deb-pkg: remove "version" variable in mkdebian kbuild: deb-pkg: fix versioning for -rc releases Documentation/kbuild: Fix indentation in modules.rst example x86: Get rid of Makefile.postlink kbuild: Create intermediate vmlinux build with relocations preserved kbuild: Introduce Kconfig symbol for linking vmlinux with relocations kbuild: link-vmlinux.sh: Make output file name configurable kbuild: do not generate .tmp_vmlinux*.map when CONFIG_VMLINUX_MAP=y Revert "kheaders: Ignore silly-rename files" ...
2025-03-24Merge tag 'x86-core-2025-03-22' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull core x86 updates from Ingo Molnar: "x86 CPU features support: - Generate the <asm/cpufeaturemasks.h> header based on build config (H. Peter Anvin, Xin Li) - x86 CPUID parsing updates and fixes (Ahmed S. Darwish) - Introduce the 'setcpuid=' boot parameter (Brendan Jackman) - Enable modifying CPU bug flags with '{clear,set}puid=' (Brendan Jackman) - Utilize CPU-type for CPU matching (Pawan Gupta) - Warn about unmet CPU feature dependencies (Sohil Mehta) - Prepare for new Intel Family numbers (Sohil Mehta) Percpu code: - Standardize & reorganize the x86 percpu layout and related cleanups (Brian Gerst) - Convert the stackprotector canary to a regular percpu variable (Brian Gerst) - Add a percpu subsection for cache hot data (Brian Gerst) - Unify __pcpu_op{1,2}_N() macros to __pcpu_op_N() (Uros Bizjak) - Construct __percpu_seg_override from __percpu_seg (Uros Bizjak) MM: - Add support for broadcast TLB invalidation using AMD's INVLPGB instruction (Rik van Riel) - Rework ROX cache to avoid writable copy (Mike Rapoport) - PAT: restore large ROX pages after fragmentation (Kirill A. Shutemov, Mike Rapoport) - Make memremap(MEMREMAP_WB) map memory as encrypted by default (Kirill A. Shutemov) - Robustify page table initialization (Kirill A. Shutemov) - Fix flush_tlb_range() when used for zapping normal PMDs (Jann Horn) - Clear _PAGE_DIRTY for kernel mappings when we clear _PAGE_RW (Matthew Wilcox) KASLR: - x86/kaslr: Reduce KASLR entropy on most x86 systems, to support PCI BAR space beyond the 10TiB region (CONFIG_PCI_P2PDMA=y) (Balbir Singh) CPU bugs: - Implement FineIBT-BHI mitigation (Peter Zijlstra) - speculation: Simplify and make CALL_NOSPEC consistent (Pawan Gupta) - speculation: Add a conditional CS prefix to CALL_NOSPEC (Pawan Gupta) - RFDS: Exclude P-only parts from the RFDS affected list (Pawan Gupta) System calls: - Break up entry/common.c (Brian Gerst) - Move sysctls into arch/x86 (Joel Granados) Intel LAM support updates: (Maciej Wieczor-Retman) - selftests/lam: Move cpu_has_la57() to use cpuinfo flag - selftests/lam: Skip test if LAM is disabled - selftests/lam: Test get_user() LAM pointer handling AMD SMN access updates: - Add SMN offsets to exclusive region access (Mario Limonciello) - Add support for debugfs access to SMN registers (Mario Limonciello) - Have HSMP use SMN through AMD_NODE (Yazen Ghannam) Power management updates: (Patryk Wlazlyn) - Allow calling mwait_play_dead with an arbitrary hint - ACPI/processor_idle: Add FFH state handling - intel_idle: Provide the default enter_dead() handler - Eliminate mwait_play_dead_cpuid_hint() Build system: - Raise the minimum GCC version to 8.1 (Brian Gerst) - Raise the minimum LLVM version to 15.0.0 (Nathan Chancellor) Kconfig: (Arnd Bergmann) - Add cmpxchg8b support back to Geode CPUs - Drop 32-bit "bigsmp" machine support - Rework CONFIG_GENERIC_CPU compiler flags - Drop configuration options for early 64-bit CPUs - Remove CONFIG_HIGHMEM64G support - Drop CONFIG_SWIOTLB for PAE - Drop support for CONFIG_HIGHPTE - Document CONFIG_X86_INTEL_MID as 64-bit-only - Remove old STA2x11 support - Only allow CONFIG_EISA for 32-bit Headers: - Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI and non-UAPI headers (Thomas Huth) Assembly code & machine code patching: - x86/alternatives: Simplify alternative_call() interface (Josh Poimboeuf) - x86/alternatives: Simplify callthunk patching (Peter Zijlstra) - KVM: VMX: Use named operands in inline asm (Josh Poimboeuf) - x86/hyperv: Use named operands in inline asm (Josh Poimboeuf) - x86/traps: Cleanup and robustify decode_bug() (Peter Zijlstra) - x86/kexec: Merge x86_32 and x86_64 code using macros from <asm/asm.h> (Uros Bizjak) - Use named operands in inline asm (Uros Bizjak) - Improve performance by using asm_inline() for atomic locking instructions (Uros Bizjak) Earlyprintk: - Harden early_serial (Peter Zijlstra) NMI handler: - Add an emergency handler in nmi_desc & use it in nmi_shootdown_cpus() (Waiman Long) Miscellaneous fixes and cleanups: - by Ahmed S. Darwish, Andy Shevchenko, Ard Biesheuvel, Artem Bityutskiy, Borislav Petkov, Brendan Jackman, Brian Gerst, Dan Carpenter, Dr. David Alan Gilbert, H. Peter Anvin, Ingo Molnar, Josh Poimboeuf, Kevin Brodsky, Mike Rapoport, Lukas Bulwahn, Maciej Wieczor-Retman, Max Grobecker, Patryk Wlazlyn, Pawan Gupta, Peter Zijlstra, Philip Redkin, Qasim Ijaz, Rik van Riel, Thomas Gleixner, Thorsten Blum, Tom Lendacky, Tony Luck, Uros Bizjak, Vitaly Kuznetsov, Xin Li, liuye" * tag 'x86-core-2025-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (211 commits) zstd: Increase DYNAMIC_BMI2 GCC version cutoff from 4.8 to 11.0 to work around compiler segfault x86/asm: Make asm export of __ref_stack_chk_guard unconditional x86/mm: Only do broadcast flush from reclaim if pages were unmapped perf/x86/intel, x86/cpu: Replace Pentium 4 model checks with VFM ones perf/x86/intel, x86/cpu: Simplify Intel PMU initialization x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-UAPI headers x86/headers: Replace __ASSEMBLY__ with __ASSEMBLER__ in UAPI headers x86/locking/atomic: Improve performance by using asm_inline() for atomic locking instructions x86/asm: Use asm_inline() instead of asm() in clwb() x86/asm: Use CLFLUSHOPT and CLWB mnemonics in <asm/special_insns.h> x86/hweight: Use asm_inline() instead of asm() x86/hweight: Use ASM_CALL_CONSTRAINT in inline asm() x86/hweight: Use named operands in inline asm() x86/stackprotector/64: Only export __ref_stack_chk_guard on CONFIG_SMP x86/head/64: Avoid Clang < 17 stack protector in startup code x86/kexec: Merge x86_32 and x86_64 code using macros from <asm/asm.h> x86/runtime-const: Add the RUNTIME_CONST_PTR assembly macro x86/cpu/intel: Limit the non-architectural constant_tsc model checks x86/mm/pat: Replace Intel x86_model checks with VFM ones x86/cpu/intel: Fix fast string initialization for extended Families ...
2025-03-24Linux 6.14v6.14Linus Torvalds1-1/+1
2025-03-22kbuild: make all file references relative to source rootThomas Weißschuh1-1/+1
-fmacro-prefix-map only affects __FILE__ and __BASE_FILE__. Other references, for example in debug information, are not affected. This makes handling of file references in the compiler outputs harder to use and creates problems for reproducible builds. Switch to -ffile-prefix map which affects all references. Also drop the documentation section advising manual specification of -fdebug-prefix-map for reproducible builds, as it is not necessary anymore. Suggested-by: Ben Hutchings <ben@decadent.org.uk> Link: https://lore.kernel.org/lkml/c49cc967294f9a3a4a34f69b6a8727a6d3959ed8.camel@decadent.org.uk/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-22kbuild: Add a help message for "headers"Xin Li (Intel)1-1/+2
Meanwhile explicitly state that the headers are uapi headers. Suggested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Xin Li (Intel) <xin@zytor.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-19Merge tag 'v6.14-rc7' into x86/core, to pick up fixesIngo Molnar1-1/+6
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-03-16Linux 6.14-rc7v6.14-rc7Linus Torvalds1-1/+1
2025-03-17kbuild: Create intermediate vmlinux build with relocations preservedArd Biesheuvel1-1/+1
The imperative paradigm used to build vmlinux, extract some info from it or perform some checks on it, and subsequently modify it again goes against the declarative paradigm that is usually employed for defining make rules. In particular, the Makefile.postlink files that consume their input via an output rule result in some dodgy logic in the decompressor makefiles for RISC-V and x86, given that the vmlinux.relocs input file needed to generate the arch-specific relocation tables may not exist or be out of date, but cannot be constructed using the ordinary Make dependency based rules, because the info needs to be extracted while vmlinux is in its ephemeral, non-stripped form. So instead, for architectures that require the static relocations that are emitted into vmlinux when passing --emit-relocs to the linker, and are subsequently stripped out again, introduce an intermediate vmlinux target called vmlinux.unstripped, and organize the reset of the build logic accordingly: - vmlinux.unstripped is created only once, and not updated again - build rules under arch/*/boot can depend on vmlinux.unstripped without running the risk of the data disappearing or being out of date - the final vmlinux generated by the build is not bloated with static relocations that are never needed again after the build completes. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-17kbuild: Introduce Kconfig symbol for linking vmlinux with relocationsArd Biesheuvel1-0/+4
Some architectures build vmlinux with static relocations preserved, but strip them again from the final vmlinux image. Arch specific tools consume these static relocations in order to construct relocation tables for KASLR. The fact that vmlinux is created, consumed and subsequently updated goes against the typical, declarative paradigm used by Make, which is based on rules and dependencies. So as a first step towards cleaning this up, introduce a Kconfig symbol to declare that the arch wants to consume the static relocations emitted into vmlinux. This will be wired up further in subsequent patches. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild, rust: use -fremap-path-prefix to make paths relativeThomas Weißschuh1-0/+1
Remap source path prefixes in all output, including compiler diagnostics, debug information, macro expansions, etc. This removes a few absolute paths from the binary and also makes it possible to use core::panic::Location properly. Equivalent to the same configuration done for C sources in commit 1d3730f0012f ("kbuild: support -fmacro-prefix-map for external modules") and commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path"). Link: https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: implement CONFIG_HEADERS_INSTALL for Usermode LinuxThomas Weißschuh1-1/+4
userprogs sometimes need access to UAPI headers. This is currently not possible for Usermode Linux, as UM is only a pseudo architecture built on top of a regular architecture and does not have its own UAPI. Instead use the UAPI headers from the underlying regular architecture. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-03-15kbuild: remove KBUILD_ENABLE_EXTRA_GCC_CHECKS supportMasahiro Yamada1-3/+0
Commit e27128db6283 ("kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN") renamed KBUILD_ENABLE_EXTRA_GCC_CHECKS in 2019. The migration in downstream code should be complete. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
2025-03-15kbuild: move -fzero-init-padding-bits=all to the top-level MakefileMasahiro Yamada1-0/+3
The -fzero-init-padding-bits=all option is not a warning flag, so defining it in scripts/Makefile.extrawarn is inconsistent. Move it to the top-level Makefile for consistency. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org>
2025-03-09Linux 6.14-rc6v6.14-rc6Linus Torvalds1-1/+1
2025-03-05kbuild: userprogs: use correct lld when linking through clangThomas WeiÃ