Searched +hist:3 +hist:fbb43df (Results 1 - 1 of 1) sorted by path

/linux-master/
H A DMakefilediff 50a33998 Fri Mar 01 04:21:07 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: fix inconsistent indentation in top Makefile

Commit 3b9ab248bc45 ("kbuild: use 4-space indentation when followed
by conditionals") introduced inconsistent indentation because it
deliberately touched only the conditional directives to minimize the
change set.

This commit reformats some blocks in the top Makefile so they are
consistently indented with 4 spaces.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
diff 3b9ab248 Thu Feb 01 18:31:42 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: use 4-space indentation when followed by conditionals

GNU Make manual [1] clearly forbids a tab at the beginning of the
conditional directive line:
"Extra spaces are allowed and ignored at the beginning of the
conditional directive line, but a tab is not allowed."

This will not work for the next release of GNU Make, hence commit
82175d1f9430 ("kbuild: Replace tabs with spaces when followed by
conditionals") replaced the inappropriate tabs with 8 spaces.

However, the 8-space indentation cannot be visually distinguished.
Linus suggested 2-4 spaces for those nested if-statements. [2]

This commit redoes the replacement with 4 spaces.

[1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax
[2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 56769ba4 Sat Oct 14 04:54:35 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Guo Ren <guoren@kernel.org>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
diff 9418e686 Sat Jul 29 16:03:17 MDT 2023 Miguel Ojeda <ojeda@kernel.org> rust: enable `no_mangle_with_rust_abi` Clippy lint

Introduced in Rust 1.69.0 [1], this lint prevents forgetting to set
the C ABI when using `#[no_mangle]` (or thinking it is implied).

For instance, it would have prevented the issue [2] fixed by commit
c682e4c37d2b ("rust: kernel: Mark rust_fmt_argument as extern "C"").

error: `#[no_mangle]` set on a function with the default (`Rust`) ABI
--> rust/kernel/print.rs:21:1
|
21 | / unsafe fn rust_fmt_argument(
22 | | buf: *mut c_char,
23 | | end: *mut c_char,
24 | | ptr: *const c_void,
25 | | ) -> *mut c_char {
| |________________^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#no_mangle_with_rust_abi
= note: requested on the command line with `-D clippy::no-mangle-with-rust-abi`
help: set an ABI
|
21 | unsafe extern "C" fn rust_fmt_argument(
| ++++++++++
help: or explicitly set the default
|
21 | unsafe extern "Rust" fn rust_fmt_argument(
| +++++++++++++

Thus enable it.

In rare cases, we may need to use the Rust ABI even with `#[no_mangle]`
(e.g. one case, before 1.71.0, would have been the `__rust_*`
functions). In those cases, we would need to `#[allow(...)]` the lint,
since using `extern "Rust"` explicitly (as the compiler suggests)
currently gets overwritten by `rustfmt` [3].

Link: https://github.com/rust-lang/rust-clippy/issues/10347 [1]
Link: https://github.com/Rust-for-Linux/linux/pull/967 [2]
Link: https://github.com/rust-lang/rustfmt/issues/5701 [3]
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Link: https://lore.kernel.org/r/20230729220317.416771-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
diff 9418e686 Sat Jul 29 16:03:17 MDT 2023 Miguel Ojeda <ojeda@kernel.org> rust: enable `no_mangle_with_rust_abi` Clippy lint

Introduced in Rust 1.69.0 [1], this lint prevents forgetting to set
the C ABI when using `#[no_mangle]` (or thinking it is implied).

For instance, it would have prevented the issue [2] fixed by commit
c682e4c37d2b ("rust: kernel: Mark rust_fmt_argument as extern "C"").

error: `#[no_mangle]` set on a function with the default (`Rust`) ABI
--> rust/kernel/print.rs:21:1
|
21 | / unsafe fn rust_fmt_argument(
22 | | buf: *mut c_char,
23 | | end: *mut c_char,
24 | | ptr: *const c_void,
25 | | ) -> *mut c_char {
| |________________^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#no_mangle_with_rust_abi
= note: requested on the command line with `-D clippy::no-mangle-with-rust-abi`
help: set an ABI
|
21 | unsafe extern "C" fn rust_fmt_argument(
| ++++++++++
help: or explicitly set the default
|
21 | unsafe extern "Rust" fn rust_fmt_argument(
| +++++++++++++

Thus enable it.

In rare cases, we may need to use the Rust ABI even with `#[no_mangle]`
(e.g. one case, before 1.71.0, would have been the `__rust_*`
functions). In those cases, we would need to `#[allow(...)]` the lint,
since using `extern "Rust"` explicitly (as the compiler suggests)
currently gets overwritten by `rustfmt` [3].

Link: https://github.com/rust-lang/rust-clippy/issues/10347 [1]
Link: https://github.com/Rust-for-Linux/linux/pull/967 [2]
Link: https://github.com/rust-lang/rustfmt/issues/5701 [3]
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Link: https://lore.kernel.org/r/20230729220317.416771-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
diff b5ec6fd2 Fri Jun 09 03:28:30 MDT 2023 Peter Zijlstra <peterz@infradead.org> kbuild: Drop -Wdeclaration-after-statement

With the advent on scope-based resource management it comes really
tedious to abide by the contraints of -Wdeclaration-after-statement.

It will still be recommeneded to place declarations at the start of a
scope where possible, but it will no longer be enforced.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/CAHk-%3Dwi-RyoUhbChiVaJZoZXheAwnJ7OO%3DGxe85BkPAd93TwDA%40mail.gmail.com
diff b5ec6fd2 Fri Jun 09 03:28:30 MDT 2023 Peter Zijlstra <peterz@infradead.org> kbuild: Drop -Wdeclaration-after-statement

With the advent on scope-based resource management it comes really
tedious to abide by the contraints of -Wdeclaration-after-statement.

It will still be recommeneded to place declarations at the start of a
scope where possible, but it will no longer be enforced.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/CAHk-%3Dwi-RyoUhbChiVaJZoZXheAwnJ7OO%3DGxe85BkPAd93TwDA%40mail.gmail.com
diff df8fc4e9 Wed May 17 17:18:11 MDT 2023 Kees Cook <keescook@chromium.org> kbuild: Enable -fstrict-flex-arrays=3

The -fstrict-flex-arrays=3 option is now available with the release
of GCC 13[1] and Clang 16[2]. This feature instructs the compiler to
treat only C99 flexible arrays as dynamically sized for the purposes of
object size calculations. In other words, the ancient practice of using
1-element arrays, or the GNU extension of using 0-sized arrays, as a
dynamically sized array is disabled. This allows CONFIG_UBSAN_BOUNDS,
CONFIG_FORTIFY_SOURCE, and other object-size aware features to behave
unambiguously in the face of trailing arrays: only C99 flexible arrays
are considered to be dynamically sized. For yet more detail, see:
https://people.kernel.org/kees/bounded-flexible-arrays-in-c

Enabling this will help track down any outstanding cases of fake
flexible arrays that need attention in kernel code.

[1] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fstrict-flex-arrays

Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Nicolas Schier <nicolas@fjasle.eu>
Cc: linux-kbuild@vger.kernel.org
Co-developed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
diff df8fc4e9 Wed May 17 17:18:11 MDT 2023 Kees Cook <keescook@chromium.org> kbuild: Enable -fstrict-flex-arrays=3

The -fstrict-flex-arrays=3 option is now available with the release
of GCC 13[1] and Clang 16[2]. This feature instructs the compiler to
treat only C99 flexible arrays as dynamically sized for the purposes of
object size calculations. In other words, the ancient practice of using
1-element arrays, or the GNU extension of using 0-sized arrays, as a
dynamically sized array is disabled. This allows CONFIG_UBSAN_BOUNDS,
CONFIG_FORTIFY_SOURCE, and other object-size aware features to behave
unambiguously in the face of trailing arrays: only C99 flexible arrays
are considered to be dynamically sized. For yet more detail, see:
https://people.kernel.org/kees/bounded-flexible-arrays-in-c

Enabling this will help track down any outstanding cases of fake
flexible arrays that need attention in kernel code.

[1] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#index-fstrict-flex-arrays
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fstrict-flex-arrays

Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Nicolas Schier <nicolas@fjasle.eu>
Cc: linux-kbuild@vger.kernel.org
Co-developed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
diff 05e96e96 Wed Mar 15 09:50:18 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: use git-archive for source package creation

Commit 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git")
added a new tool, scripts/list-gitignored. My intention was to create
source packages without cleaning the source tree, without relying on git.

Linus strongly objected to it, and suggested using 'git archive' instead.
[1] [2] [3]

This commit goes in that direction - Remove scripts/list-gitignored.c
and rewrites Makefiles and scripts to use 'git archive' for building
Debian and RPM source packages. It also makes 'make perf-tar*-src-pkg'
use 'git archive' again.

Going forward, building source packages is only possible in a git-managed
tree. Building binary packages does not require git.

[1]: https://lore.kernel.org/lkml/CAHk-=wi49sMaC7vY1yMagk7eqLK=1jHeHQ=yZ_k45P=xBccnmA@mail.gmail.com/
[2]: https://lore.kernel.org/lkml/CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com/
[3]: https://lore.kernel.org/lkml/CAHk-=wgM-W6Fu==EoAVCabxyX8eYBz9kNC88-tm9ExRQwA79UQ@mail.gmail.com/

Fixes: 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git")
Fixes: e0ca16749ac3 ("kbuild: make perf-tar*-src-pkg work without relying on git")
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 05e96e96 Wed Mar 15 09:50:18 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> kbuild: use git-archive for source package creation

Commit 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git")
added a new tool, scripts/list-gitignored. My intention was to create
source packages without cleaning the source tree, without relying on git.

Linus strongly objected to it, and suggested using 'git archive' instead.
[1] [2] [3]

This commit goes in that direction - Remove scripts/list-gitignored.c
and rewrites Makefiles and scripts to use 'git archive' for building
Debian and RPM source packages. It also makes 'make perf-tar*-src-pkg'
use 'git archive' again.

Going forward, building source packages is only possible in a git-managed
tree. Building binary packages does not require git.

[1]: https://lore.kernel.org/lkml/CAHk-=wi49sMaC7vY1yMagk7eqLK=1jHeHQ=yZ_k45P=xBccnmA@mail.gmail.com/
[2]: https://lore.kernel.org/lkml/CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com/
[3]: https://lore.kernel.org/lkml/CAHk-=wgM-W6Fu==EoAVCabxyX8eYBz9kNC88-tm9ExRQwA79UQ@mail.gmail.com/

Fixes: 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git")
Fixes: e0ca16749ac3 ("kbuild: make perf-tar*-src-pkg work without relying on git")
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Completed in 925 milliseconds