Changes in Makefile

0ff41df1 - Linux 6.15

Sun, 25 May 2025 23:09:23 +0000

Linux 6.15 List of files: /linux-6.15/Makefile

a5806cd5 - Linux 6.15-rc7

Sun, 18 May 2025 20:57:29 +0000

Linux 6.15-rc7 List of files: /linux-6.15/Makefile

8cf5b3f8 - Revert "kbuild, rust: use -fremap-path-prefix to make paths relative"

Sun, 11 May 2025 06:02:28 +0000

Revert "kbuild, rust: use -fremap-path-prefix to make paths relative"This reverts commit dbdffaf50ff9cee3259a7cef8a7bd9e0f0ba9f13.--remap-path-prefix breaks the ability of debuggers to find the sourcefile corresponding to object files. As there is no simple or uniformway to specify the source directory explicitly, this breaks developersworkflows.Revert the unconditional usage of --remap-path-prefix, equivalent to thesame 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 Acked-by: Miguel Ojeda Signed-off-by: Masahiro Yamada List of files: /linux-6.15/Makefile

020d7f14 - Revert "kbuild: make all file references relative to source root"

Sun, 11 May 2025 06:02:27 +0000

Revert "kbuild: make all file references relative to source root"This reverts commit cacd22ce69585a91c386243cd662ada962431e63.-ffile-prefix-map breaks the ability of debuggers to find the sourcefile corresponding to object files. As there is no simple or uniformway to specify the source directory explicitly, this breaks developersworkflows.Revert the unconditional usage of -ffile-prefix-map.Reported-by: Matthieu Baerts Closes: https://lore.kernel.org/lkml/edc50aa7-0740-4942-8c15-96f12f2acc7e@kernel.org/Reported-by: Ville Syrjälä 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 Signed-off-by: Masahiro Yamada List of files: /linux-6.15/Makefile

82f2b0b9 - Linux 6.15-rc6

Sun, 11 May 2025 21:54:11 +0000

Linux 6.15-rc6 List of files: /linux-6.15/Makefile

92a09c47 - Linux 6.15-rc5

Sun, 04 May 2025 20:55:04 +0000

Linux 6.15-rc5 List of files: /linux-6.15/Makefile

4f79eaa2 - kbuild: Properly disable -Wunterminated-string-initialization for clang

Wed, 30 Apr 2025 22:56:34 +0000

kbuild: Properly disable -Wunterminated-string-initialization for clangClang and GCC have different behaviors around disabling warningsincluded in -Wall and -Wextra and the order in which flags arespecified, 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.cMove -Wextra up right below -Wall in Makefile.extrawarn to ensure theseflags are at the beginning of the warning options list. Move the coupleof warning options that have been added to the main Makefile sincecommit e88ca24319e4 ("kbuild: consolidate warning flags inscripts/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/10359Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds List of files: /linux-6.15/Makefile

b4432656 - Linux 6.15-rc4

Sun, 27 Apr 2025 22:19:23 +0000

Linux 6.15-rc4 List of files: /linux-6.15/Makefile

a79be02b - Fix mis-uses of 'cc-option' for warning disablement

Wed, 23 Apr 2025 17:08:29 +0000

Fix mis-uses of 'cc-option' for warning disablementThis was triggered by one of my mis-uses causing odd build warnings onsparc in linux-next, but while figuring out why the "obviously correct"use of cc-option caused such odd breakage, I found eight other cases ofthe same thing in the tree.The root cause is that 'cc-option' doesn't work for checking negativewarning options (ie things like '-Wno-stringop-overflow') because gccwill 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 isemitted. At that point the compiler will go "Hmm, maybe the userintended to disable this warning but used that wrong option that Ididn't recognize", and generate a warning for the unrecognized negativeoption.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 thetime it simply doesn't matter that ity doesn't work.The reason my recently added case caused problems on sparc was pointedout by Thomas Weißschuh: the sparc build had a previous explicit warningthat then triggered the new one.I think the best fix for this would be to make 'cc-option' a bit smarterabout this sitation, possibly by adding an intentional warning to thetest case that then triggers the unrecognized option warning reliably.But the short-term fix is to replace 'cc-option' with an existing helperdesigned for this exact case: 'cc-disable-warning', which picks thenegative warning but uses the positive form for testing the compilersupport.Reported-by: Stephen Rothwell Link: https://lore.kernel.org/all/20250422204718.0b4e3f81@canb.auug.org.au/Explained-by: Thomas Weißschuh Signed-off-by: Linus Torvalds List of files: /linux-6.15/Makefile

9d7a0577 - gcc-15: disable '-Wunterminated-string-initialization' entirely for now

Sun, 20 Apr 2025 22:30:53 +0000

gcc-15: disable '-Wunterminated-string-initialization' entirely for nowI had left the warning around but as a non-fatal error to get my gcc-15builds going, but fixed up some of the most annoying warning cases sothat it wouldn't be *too* verbose.Because I like the _concept_ of the warning, even if I detested theimplementation to shut it up.It turns out the implementation to shut it up is even more broken than Ithought, and my "shut up most of the warnings" patch just caused fatalerrors 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 systemsto 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'ttrigger the warning (see commit d5d45a7f2619: "gcc-15: make'unterminated string initialization' just a warning"), instead ofmarking 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 ofhow gcc doesn't like marking the types as having attributes, onlysymbols.There may be some trick to it, but I was already annoyed by the badattribute 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 astring".The obvious thing would be to distinguish between "char []" and anexplicitly signed "unsigned char []" (as opposed to an implicitlyunsigned char, which is typically an architecture-specific default, butfor the kernel is universal thanks to '-funsigned-char').But any "we can typedef a 8-bit type to not become a string just becauseit's an array" model would be fine.But "__attribute__((nonstring))" is sadly not that sane model.Reported-by: Chris Clayton 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 List of files: /linux-6.15/Makefile

9c32cda4 - Linux 6.15-rc3

Sun, 20 Apr 2025 20:43:47 +0000

Linux 6.15-rc3 List of files: /linux-6.15/Makefile

d5d45a7f - gcc-15: make 'unterminated string initialization' just a warning

Sun, 20 Apr 2025 17:33:23 +0000

gcc-15: make 'unterminated string initialization' just a warninggcc-15 enabling -Wunterminated-string-initialization in -Wextra bydefault was done with the best intentions, but the warning is stillquite broken.What annoys me about the warning is that this is a very traditional ANDCORRECT 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 gccdevelopers 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 makethat absolutely disgusting syntax more palatable (ie the kernel syntaxfor that monstrosity is just "__nonstring").But that attribute is misdesigned. What you'd typically want to do istell the compiler that you are using a type that isn't a string but abyte 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 eachinstance of that pattern.This is particularly noticeable in our ACPI code, because ACPI has thisnotion of a 4-byte "type name" that gets used all over, and is exactlythis kind of byte array.This is a sad oversight, because the warning is useful, but really wouldbe so much better if gcc had also given a sane way to indicate that wereally just want a byte array type at a type level, not the broken "eachand 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 thetypical initializers.This is annoying me mainly because I think the warning _is_ a goodwarning, which is why I'm not just turning it off in disgust. But it ishampered 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 List of files: /linux-6.15/Makefile

0866ee8e - rust: disable `clippy::needless_continue`

Thu, 03 Apr 2025 16:38:05 +0000

rust: disable `clippy::needless_continue`Starting with Rust 1.86.0, Clippy's `needless_continue` lint complainsabout 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 otherways to write the code either, in cases when that applies.In addition, the help text does not really apply in the new cases thelint 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 bepossible, 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 bydefault by Clippy.Thus disable the lint, at least for the time being.Feedback was submitted to upstream Clippy, in case this can be improvedor 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.orgReviewed-by: Alice Ryhl Signed-off-by: Miguel Ojeda List of files: /linux-6.15/Makefile

8ffd015d - Linux 6.15-rc2

Sun, 13 Apr 2025 18:54:49 +0000

Linux 6.15-rc2 List of files: /linux-6.15/Makefile

84ffc79b - kbuild: Add '-fno-builtin-wcslen'

Mon, 07 Apr 2025 23:22:12 +0000

kbuild: Add '-fno-builtin-wcslen'A recent optimization change in LLVM [1] aims to transform certain loopidioms into calls to strlen() or wcslen(). This change transforms thefirst while loop in UniStrcat() into a call to wcslen(), breaking thebuild 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 thecompiler from assuming that wcslen() is available in the kernel's Clibrary.[ 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.orgLink: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1]Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds List of files: /linux-6.15/Makefile

0af2f6be - Linux 6.15-rc1

Sun, 06 Apr 2025 20:11:33 +0000

Linux 6.15-rc1 List of files: /linux-6.15/Makefile

38fec10e - Linux 6.14

Mon, 24 Mar 2025 14:02:41 +0000

Linux 6.14 List of files: /linux-6.15/Makefile

cacd22ce - kbuild: make all file references relative to source root

Sat, 15 Mar 2025 13:20:14 +0000

kbuild: make all file references relative to source root-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 touse 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 necessaryanymore.Suggested-by: Ben Hutchings Link: https://lore.kernel.org/lkml/c49cc967294f9a3a4a34f69b6a8727a6d3959ed8.camel@decadent.org.uk/Signed-off-by: Thomas Weißschuh Signed-off-by: Masahiro Yamada List of files: /linux-6.15/Makefile

00e81f4f - kbuild: Add a help message for "headers"

Wed, 12 Mar 2025 03:34:21 +0000

kbuild: Add a help message for "headers"Meanwhile explicitly state that the headers are uapi headers.Suggested-by: Borislav Petkov Signed-off-by: Xin Li (Intel) Signed-off-by: Masahiro Yamada List of files: /linux-6.15/Makefile

4701f33a - Linux 6.14-rc7

Sun, 16 Mar 2025 22:55:17 +0000

Linux 6.14-rc7 List of files: /linux-6.15/Makefile