linux-stable.git/scripts, branch v6.14.2

kbuild: deb-pkg: don't set KBUILD_BUILD_VERSION unconditionally

2025-04-10T12:44:42+00:00

[ Upstream commit 62604063621fb075c7966286bdddcb057d883fa8 ]

In ThinPro, we use the convention +hp for
the kernel package. This does not have a dash in the name or version.
This is built by editing ".version" before a build, and setting
EXTRAVERSION="+hp" and KDEB_PKGVERSION make variables:

    echo 68 > .version
    make -j EXTRAVERSION="+hp" bindeb-pkg KDEB_PKGVERSION=6.12.2+hp69

    .deb name: linux-image-6.12.2+hp_6.12.2+hp69_amd64.deb

Since commit 7d4f07d5cb71 ("kbuild: deb-pkg: squash
scripts/package/deb-build-option to debian/rules"), this no longer
works. The deb build logic changed, even though, the commit message
implies that the logic should be unmodified.

Before, KBUILD_BUILD_VERSION was not set if the KDEB_PKGVERSION did
not contain a dash. After the change KBUILD_BUILD_VERSION is always
set to KDEB_PKGVERSION. Since this determines UTS_VERSION, the uname
output to look off:

    (now)      uname -a: version 6.12.2+hp ... #6.12.2+hp69
    (expected) uname -a: version 6.12.2+hp ... #69

Update the debian/rules logic to restore the original behavior.

Fixes: 7d4f07d5cb71 ("kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules")
Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Nicolas Schier 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

scripts/gdb/linux/symbols.py: address changes to module_sect_attrs

2025-04-10T12:44:32+00:00

[ Upstream commit e0349c46cb4fbbb507fa34476bd70f9c82bad359 ]

When loading symbols from kernel modules we used to iterate
from 0 to module_sect_attrs::nsections, in order to
retrieve their name and address.

However module_sect_attrs::nsections has been removed from
the struct by a previous commit.

Re-arrange the iteration by accessing all items in
module_sect_attrs::grp::bin_attrs[] until NULL is found
(it's a NULL terminated array).

At the same time the symbol address cannot be extracted
from module_sect_attrs::attrs[]::address anymore because
it has also been deleted. Fetch it from
module_sect_attrs::grp::bin_attrs[]::private as described
in 4b2c11e4aaf7.

Link: https://lkml.kernel.org/r/20250221204034.4430-1-antonio@mandelbit.com
Fixes: d8959b947a8d ("module: sysfs: Drop member 'module_sect_attrs::nsections'")
Fixes: 4b2c11e4aaf7 ("module: sysfs: Drop member 'module_sect_attr::address'")
Signed-off-by: Antonio Quartulli 
Reviewed-by: Jan Kiszka 
Cc: Thomas Weißschuh 
Cc: Kieran Bingham 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

selinux: Chain up tool resolving errors in install_policy.sh

2025-04-10T12:43:57+00:00

[ Upstream commit 6ae0042f4d3f331e841495eb0a3d51598e593ec2 ]

Subshell evaluations are not exempt from errexit, so if a command is
not available, `which` will fail and exit the script as a whole.
This causes the helpful error messages to not be printed if they are
tacked on using a `$?` comparison.

Resolve the issue by using chains of logical operators, which are not
subject to the effects of errexit.

Fixes: e37c1877ba5b1 ("scripts/selinux: modernize mdp")
Signed-off-by: Tim Schumacher 
Signed-off-by: Paul Moore 
Signed-off-by: Sasha Levin

Merge tag 'rust-fixes-6.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux

2025-03-16T01:40:42+00:00

Pull rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

   - Disallow BTF generation with Rust + LTO

   - Improve rust-analyzer support

  'kernel' crate:

   - 'init' module: remove 'Zeroable' implementation for a couple types
     that should not have it

   - 'alloc' module: fix macOS failure in host test by satisfying POSIX
     alignment requirement

   - Add missing '\n's to 'pr_*!()' calls

  And a couple other minor cleanups"

* tag 'rust-fixes-6.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  scripts: generate_rust_analyzer: add uapi crate
  scripts: generate_rust_analyzer: add missing include_dirs
  scripts: generate_rust_analyzer: add missing macros deps
  rust: Disallow BTF generation with Rust + LTO
  rust: task: fix `SAFETY` comment in `Task::wake_up`
  rust: workqueue: add missing newline to pr_info! examples
  rust: sync: add missing newline in locked_by log example
  rust: init: add missing newline to pr_info! calls
  rust: error: add missing newline to pr_warn! calls
  rust: docs: add missing newline to printing macro examples
  rust: alloc: satisfy POSIX alignment requirement
  rust: init: fix `Zeroable` implementation for `Option>` and `Option>`
  rust: remove leftover mentions of the `alloc` crate

scripts: generate_rust_analyzer: add uapi crate

2025-03-11T23:13:07+00:00

Commit 4e1746656839 ("rust: uapi: Add UAPI crate") did not update
rust-analyzer to include the new crate.

Add the missing definition to improve the developer experience.

Fixes: 4e1746656839 ("rust: uapi: Add UAPI crate")
Signed-off-by: Tamir Duberstein 
Tested-by: Andreas Hindborg 
Link: https://lore.kernel.org/r/20250210-rust-analyzer-bindings-include-v2-2-23dff845edc3@gmail.com
[ Slightly reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda

scripts: generate_rust_analyzer: add missing include_dirs

2025-03-11T23:12:58+00:00

Commit 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`")
specified OBJTREE for the bindings crate, and `source.include_dirs` for
the kernel crate, likely in an attempt to support out-of-source builds
for those crates where the generated files reside in `objtree` rather
than `srctree`. This was insufficient because both bits of configuration
are required for each crate; the result is that rust-analyzer is unable
to resolve generated files for either crate in an out-of-source build.

[ Originally we were not using `OBJTREE` in the `kernel` crate, but
we did pass the variable anyway, so conceptually it could have been
there since then.

Regarding `include_dirs`, it started in `kernel` before being in
mainline because we included the bindings directly there (i.e.
there was no `bindings` crate). However, when that crate got
created, we moved the `OBJTREE` there but not the `include_dirs`.
Nowadays, though, we happen to need the `include_dirs` also in
the `kernel` crate for `generated_arch_static_branch_asm.rs` which
was not there back then -- Tamir confirms it is indeed required
for that reason. - Miguel ]

Add the missing bits to improve the developer experience.

Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`")
Signed-off-by: Tamir Duberstein
Tested-by: Andreas Hindborg
Link: https://lore.kernel.org/r/20250210-rust-analyzer-bindings-include-v2-1-23dff845edc3@gmail.com
[ Slightly reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda

scripts: generate_rust_analyzer: add missing macros deps

2025-03-11T22:37:45+00:00

The macros crate has depended on std and proc_macro since its
introduction in commit 1fbde52bde73 ("rust: add `macros` crate"). These
dependencies were omitted from commit 8c4555ccc55c ("scripts: add
`generate_rust_analyzer.py`") resulting in missing go-to-definition and
autocomplete, and false-positive warnings emitted from rust-analyzer
such as:

  [{
  	"resource": "/Users/tamird/src/linux/rust/macros/module.rs",
  	"owner": "_generated_diagnostic_collection_name_#1",
  	"code": {
  		"value": "non_snake_case",
  		"target": {
  			"$mid": 1,
  			"path": "/rustc/",
  			"scheme": "https",
  			"authority": "doc.rust-lang.org",
  			"query": "search=non_snake_case"
  		}
  	},
  	"severity": 4,
  	"message": "Variable `None` should have snake_case name, e.g. `none`",
  	"source": "rust-analyzer",
  	"startLineNumber": 123,
  	"startColumn": 17,
  	"endLineNumber": 123,
  	"endColumn": 21
  }]

Add the missing dependencies to improve the developer experience.

  [ Fiona had a different approach (thanks!) at:

        https://lore.kernel.org/rust-for-linux/20241205115438.234221-1-me@kloenk.dev/

    But Tamir and Fiona agreed to this one. - Miguel ]

Fixes: 8c4555ccc55c ("scripts: add `generate_rust_analyzer.py`")
Reviewed-by: Fiona Behrens 
Diagnosed-by: Chayim Refael Friedman 
Link: https://github.com/rust-lang/rust-analyzer/issues/17759#issuecomment-2646328275
Signed-off-by: Tamir Duberstein 
Tested-by: Andreas Hindborg 
Link: https://lore.kernel.org/r/20250210-rust-analyzer-macros-core-dep-v3-1-45eb4836f218@gmail.com
[ Removed `return`. Changed tag name. Added Link. Slightly
  reworded. - Miguel ]
Signed-off-by: Miguel Ojeda

kbuild: install-extmod-build: Fix build when specifying KBUILD_OUTPUT

2025-03-06T11:32:30+00:00

Since commit 5f73e7d0386d ("kbuild: refactor cross-compiling
linux-headers package"), the linux-headers pacman package fails
to build when "O=" is set. The build system complains:

/mnt/chroot/linux/scripts/Makefile.build:41: mnt/chroots/linux-mainline/pacman/linux-upstream/pkg/linux-upstream-headers/usr//lib/modules/6.14.0-rc3-00350-g771dba31fffc/build/scripts/Makefile: No such file or directory

This is because the "srcroot" variable is set to "." and the
"build" variable is set to the absolute path. This makes the
"src" variables point to wrong directory.

Change the "build" variable to a relative path to "." to
fix build.

Fixes: 5f73e7d0386d ("kbuild: refactor cross-compiling linux-headers package")
Signed-off-by: Inochi Amaoto 
Signed-off-by: Masahiro Yamada

rust: remove leftover mentions of the `alloc` crate

2025-03-05T22:55:56+00:00

In commit 392e34b6bc22 ("kbuild: rust: remove the `alloc` crate and
`GlobalAlloc`") we stopped using the upstream `alloc` crate.

Thus remove a few leftover mentions treewide.

Cc: stable@vger.kernel.org # Also to 6.12.y after the `alloc` backport lands
Fixes: 392e34b6bc22 ("kbuild: rust: remove the `alloc` crate and `GlobalAlloc`")
Reviewed-by: Danilo Krummrich 
Reviewed-by: Andreas Hindborg 
Link: https://lore.kernel.org/r/20250303171030.1081134-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

modpost: Fix a few typos in a comment

2025-02-15T18:10:58+00:00

Namely: s/becasue/because/ and s/wiht/with/ plus an added article.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Masahiro Yamada