stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [PATCH 2/2] clk: bcm: rpi: Assign ->num before accessing ->hws
  2024-04-25 16:55 96% [PATCH 0/2] clk: bcm: Move a couple of __counted_by initializations Nathan Chancellor
  2024-04-25 16:55 93% ` [PATCH 1/2] clk: bcm: dvp: Assign ->num before accessing ->hws Nathan Chancellor
@ 2024-04-25 16:55 93% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-25 16:55 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Florian Fainelli
  Cc: Kees Cook, Gustavo A. R. Silva, bcm-kernel-feedback-list,
	linux-clk, linux-rpi-kernel, linux-arm-kernel, linux-hardening,
	patches, llvm, stable, Nathan Chancellor

Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
raspberrypi_discover_clocks() due to ->num being assigned after ->hws
has been accessed:

  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4
  index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')

Move the ->num initialization to before the first access of ->hws, which
clears up the warning.

Cc: stable@vger.kernel.org
Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 829406dc44a2..4d411408e4af 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -371,8 +371,8 @@ static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi,
 			if (IS_ERR(hw))
 				return PTR_ERR(hw);
 
-			data->hws[clks->id] = hw;
 			data->num = clks->id + 1;
+			data->hws[clks->id] = hw;
 		}
 
 		clks++;

-- 
2.44.0


^ permalink raw reply related	[relevance 93%]

* [PATCH 1/2] clk: bcm: dvp: Assign ->num before accessing ->hws
  2024-04-25 16:55 96% [PATCH 0/2] clk: bcm: Move a couple of __counted_by initializations Nathan Chancellor
@ 2024-04-25 16:55 93% ` Nathan Chancellor
  2024-04-25 16:55 93% ` [PATCH 2/2] clk: bcm: rpi: " Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-25 16:55 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Florian Fainelli
  Cc: Kees Cook, Gustavo A. R. Silva, bcm-kernel-feedback-list,
	linux-clk, linux-rpi-kernel, linux-arm-kernel, linux-hardening,
	patches, llvm, stable, Nathan Chancellor

Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with
__counted_by") annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
clk_dvp_probe() due to ->num being assigned after ->hws has been
accessed:

  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2
  index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')

Move the ->num initialization to before the first access of ->hws, which
clears up the warning.

Cc: stable@vger.kernel.org
Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/clk/bcm/clk-bcm2711-dvp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-bcm2711-dvp.c
index e4fbbf3c40fe..3cb235df9d37 100644
--- a/drivers/clk/bcm/clk-bcm2711-dvp.c
+++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
@@ -56,6 +56,8 @@ static int clk_dvp_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	data->num = NR_CLOCKS;
+
 	data->hws[0] = clk_hw_register_gate_parent_data(&pdev->dev,
 							"hdmi0-108MHz",
 							&clk_dvp_parent, 0,
@@ -76,7 +78,6 @@ static int clk_dvp_probe(struct platform_device *pdev)
 		goto unregister_clk0;
 	}
 
-	data->num = NR_CLOCKS;
 	ret = of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_onecell_get,
 				     data);
 	if (ret)

-- 
2.44.0


^ permalink raw reply related	[relevance 93%]

* [PATCH 0/2] clk: bcm: Move a couple of __counted_by initializations
@ 2024-04-25 16:55 96% Nathan Chancellor
  2024-04-25 16:55 93% ` [PATCH 1/2] clk: bcm: dvp: Assign ->num before accessing ->hws Nathan Chancellor
  2024-04-25 16:55 93% ` [PATCH 2/2] clk: bcm: rpi: " Nathan Chancellor
  0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2024-04-25 16:55 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Florian Fainelli
  Cc: Kees Cook, Gustavo A. R. Silva, bcm-kernel-feedback-list,
	linux-clk, linux-rpi-kernel, linux-arm-kernel, linux-hardening,
	patches, llvm, stable, Nathan Chancellor

Hi all,

This series addresses two UBSAN warnings I see on my Raspberry Pi 4 with
recent releases of clang that support __counted_by by moving the
initializations of the element count member before any accesses of the
flexible array member.

I marked these for stable because more distributions are enabling the
bounds sanitizer [1][2], so the warnings will show up when the kernel is
built with a compiler that supports __counted_by, so it seems worth
fixing this for future users.

[1]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1914685
[2]: https://src.fedoraproject.org/rpms/kernel/c/79a2207963b8fea452acfc5dea13ed54bd36c7e1

---
Nathan Chancellor (2):
      clk: bcm: dvp: Assign ->num before accessing ->hws
      clk: bcm: rpi: Assign ->num before accessing ->hws

 drivers/clk/bcm/clk-bcm2711-dvp.c | 3 ++-
 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)
---
base-commit: ed30a4a51bb196781c8058073ea720133a65596f
change-id: 20240424-cbl-bcm-assign-counted-by-val-before-access-cf19d630f2b4

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply	[relevance 96%]

* Re: Patch "configs/hardening: Fix disabling UBSAN configurations" has been added to the 6.8-stable tree
  @ 2024-04-23  0:00 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-23  0:00 UTC (permalink / raw)
  To: Sasha Levin; +Cc: stable, stable-commits, Kees Cook, Gustavo A. R. Silva

On Mon, Apr 22, 2024 at 07:12:21PM -0400, Sasha Levin wrote:
> On Mon, Apr 22, 2024 at 11:54:33AM -0700, Nathan Chancellor wrote:
> > On Sun, Apr 21, 2024 at 01:11:19PM -0400, Sasha Levin wrote:
> > > This is a note to let you know that I've just added the patch titled
> > > 
> > >     configs/hardening: Fix disabling UBSAN configurations
> > > 
> > > to the 6.8-stable tree which can be found at:
> > >     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > > 
> > > The filename of the patch is:
> > >      configs-hardening-fix-disabling-ubsan-configurations.patch
> > > and it can be found in the queue-6.8 subdirectory.
> > > 
> > > If you, or anyone else, feels it should not be added to the stable tree,
> > > please let <stable@vger.kernel.org> know about it.
> > > 
> > > 
> > > 
> > > commit a54fba0bb1f52707b423c908e153d6429d08db58
> > > Author: Nathan Chancellor <nathan@kernel.org>
> > > Date:   Thu Apr 11 11:11:06 2024 -0700
> > > 
> > >     configs/hardening: Fix disabling UBSAN configurations
> > > 
> > >     [ Upstream commit e048d668f2969cf2b76e0fa21882a1b3bb323eca ]
> > 
> > While I think backporting this makes sense, I don't know that
> > backporting 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") to
> > resolve the conflict with 6.8 is entirely necessary (or beneficial, I
> > don't know how Kees feels about it though). I've attached a version that
> > applies cleanly to 6.8, in case it is desirable.
> 
> I usually wouldn't do it, but 918327e9b7ff ("ubsan: Remove
> CONFIG_UBSAN_SANITIZE_ALL") indicated that it's mostly a noop rather
> than a change in behavior for existing config files.

It is a change in behavior for architectures that did not select
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL because CONFIG_UBSAN_SANITIZE_ALL
depends on that (for example, LoongArch). That change actually helped
expose an issue in LoongArch's LLVM backend because UBSAN was now
getting enabled on files in allmodconfig, which is good, but that shows
the change is not risk free. However, given that it makes CONFIG_UBSAN
perhaps work more expectedly (which could be considered a fix on its
own), we can probably keep this as is and just back out of it if it is
too disruptive to people.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: Patch "configs/hardening: Fix disabling UBSAN configurations" has been added to the 6.8-stable tree
       [not found]     <20240421171119.1444407-1-sashal@kernel.org>
@ 2024-04-22 18:54 91% ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-22 18:54 UTC (permalink / raw)
  To: stable; +Cc: stable-commits, Kees Cook, Gustavo A. R. Silva

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Sun, Apr 21, 2024 at 01:11:19PM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
> 
>     configs/hardening: Fix disabling UBSAN configurations
> 
> to the 6.8-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      configs-hardening-fix-disabling-ubsan-configurations.patch
> and it can be found in the queue-6.8 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
> 
> 
> 
> commit a54fba0bb1f52707b423c908e153d6429d08db58
> Author: Nathan Chancellor <nathan@kernel.org>
> Date:   Thu Apr 11 11:11:06 2024 -0700
> 
>     configs/hardening: Fix disabling UBSAN configurations
>     
>     [ Upstream commit e048d668f2969cf2b76e0fa21882a1b3bb323eca ]

While I think backporting this makes sense, I don't know that
backporting 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") to
resolve the conflict with 6.8 is entirely necessary (or beneficial, I
don't know how Kees feels about it though). I've attached a version that
applies cleanly to 6.8, in case it is desirable.

Cheers,
Nathan

[-- Attachment #2: e048d668f2969cf2b76e0fa21882a1b3bb323eca-6.8.patch --]
[-- Type: text/plain, Size: 2803 bytes --]

From 8990975f1a5b3042a51253d1be0a360fba38b43e Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Thu, 11 Apr 2024 11:11:06 -0700
Subject: [PATCH 6.8] configs/hardening: Fix disabling UBSAN configurations

commit e048d668f2969cf2b76e0fa21882a1b3bb323eca upstream.

The initial change that added kernel/configs/hardening.config attempted
to disable all UBSAN sanitizers except for the array bounds one while
turning on UBSAN_TRAP. Unfortunately, it only got the syntax for
CONFIG_UBSAN_SHIFT correct, so configurations that are on by default
with CONFIG_UBSAN=y such as CONFIG_UBSAN_{BOOL,ENUM} do not get disabled
properly.

  CONFIG_ARCH_HAS_UBSAN=y
  CONFIG_UBSAN=y
  CONFIG_UBSAN_TRAP=y
  CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
  CONFIG_UBSAN_BOUNDS=y
  CONFIG_UBSAN_BOUNDS_STRICT=y
  # CONFIG_UBSAN_SHIFT is not set
  # CONFIG_UBSAN_DIV_ZERO is not set
  # CONFIG_UBSAN_UNREACHABLE is not set
  CONFIG_UBSAN_SIGNED_WRAP=y
  CONFIG_UBSAN_BOOL=y
  CONFIG_UBSAN_ENUM=y
  # CONFIG_TEST_UBSAN is not set

Add the missing 'is not set' to each configuration that needs it so that
they get disabled as intended.

  CONFIG_ARCH_HAS_UBSAN=y
  CONFIG_UBSAN=y
  CONFIG_UBSAN_TRAP=y
  CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
  CONFIG_UBSAN_BOUNDS=y
  CONFIG_UBSAN_BOUNDS_STRICT=y
  # CONFIG_UBSAN_SHIFT is not set
  # CONFIG_UBSAN_DIV_ZERO is not set
  # CONFIG_UBSAN_UNREACHABLE is not set
  CONFIG_UBSAN_SIGNED_WRAP=y
  # CONFIG_UBSAN_BOOL is not set
  # CONFIG_UBSAN_ENUM is not set
  # CONFIG_TEST_UBSAN is not set

Fixes: 215199e3d9f3 ("hardening: Provide Kconfig fragments for basic options")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20240411-fix-ubsan-in-hardening-config-v1-1-e0177c80ffaa@kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
[nathan: Resolve conflicts due to lack of 006eac3fe20f and de2683e7fdac
         in earlier releases]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 kernel/configs/hardening.config | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/configs/hardening.config b/kernel/configs/hardening.config
index 95a400f042b1..cac20e001c5b 100644
--- a/kernel/configs/hardening.config
+++ b/kernel/configs/hardening.config
@@ -39,11 +39,11 @@ CONFIG_UBSAN=y
 CONFIG_UBSAN_TRAP=y
 CONFIG_UBSAN_BOUNDS=y
 # CONFIG_UBSAN_SHIFT is not set
-# CONFIG_UBSAN_DIV_ZERO
-# CONFIG_UBSAN_UNREACHABLE
-# CONFIG_UBSAN_BOOL
-# CONFIG_UBSAN_ENUM
-# CONFIG_UBSAN_ALIGNMENT
+# CONFIG_UBSAN_DIV_ZERO is not set
+# CONFIG_UBSAN_UNREACHABLE is not set
+# CONFIG_UBSAN_BOOL is not set
+# CONFIG_UBSAN_ENUM is not set
+# CONFIG_UBSAN_ALIGNMENT is not set
 CONFIG_UBSAN_SANITIZE_ALL=y
 
 # Linked list integrity checking.

base-commit: 12dadc409c2bd8538c6ee0e56e191efde6d92007
-- 
2.44.0


^ permalink raw reply related	[relevance 91%]

* Re: [PATCH] x86/purgatory: Switch to the position-independent small code model
  @ 2024-04-18 20:37 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-18 20:37 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: linux-kernel, x86, Ard Biesheuvel, Nick Desaulniers,
	Bill Wendling, Justin Stitt, Song Liu, Ricardo Ribalda,
	Fangrui Song, Arthur Eubanks, stable

On Thu, Apr 18, 2024 at 10:17:06PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> On x86, the ordinary, position dependent 'small' and 'kernel' code models only
> support placement of the executable in 32-bit addressable memory, due to
> the use of 32-bit signed immediates to generate references to global
> variables. For the kernel, this implies that all global variables must
> reside in the top 2 GiB of the kernel virtual address space, where the
> implicit address bits 63:32 are equal to sign bit 31.
> 
> This means the kernel code model is not suitable for other bare metal
> executables such as the kexec purgatory, which can be placed arbitrarily
> in the physical address space, where its address may no longer be
> representable as a sign extended 32-bit quantity. For this reason,
> commit
> 
>   e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
> 
> switched to the 'large' code model, which uses 64-bit immediates for all
> symbol references, including function calls, in order to avoid relying
> on any assumptions regarding proximity of symbols in the final
> executable.
> 
> The large code model is rarely used, clunky and the least likely to
> operate in a similar fashion when comparing GCC and Clang, so it is best
> avoided. This is especially true now that Clang 18 has started to emit
> executable code in two separate sections (.text and .ltext), which
> triggers an issue in the kexec loading code at runtime.
> 
> Instead, use the position independent small code model, which makes no
> assumptions about placement but only about proximity, where all
> referenced symbols must be within -/+ 2 GiB, i.e., in range for a
> RIP-relative reference. Use hidden visibility to suppress the use of a
> GOT, which carries absolute addresses that are not covered by static ELF
> relocations, and is therefore incompatible with the kexec loader's
> relocation logic.
> 
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Bill Wendling <morbo@google.com>
> Cc: Justin Stitt <justinstitt@google.com>
> Cc: Song Liu <song@kernel.org>
> Cc: Ricardo Ribalda <ribalda@kernel.org>
> Cc: Fangrui Song <maskray@google.com>
> Cc: Arthur Eubanks <aeubanks@google.com>
> Link: https://lore.kernel.org/all/20240417-x86-fix-kexec-with-llvm-18-v1-0-5383121e8fb7@kernel.org/
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>

This resolves the warning and relocation overflow error that I see with
LLVM 18.1.4 (the relocation error was fixed in LLVM but dropping
-mcmodel=large resolves it for toolchains without that fix).

> ---
>  arch/x86/purgatory/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index bc31863c5ee6..a18591f6e6d9 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -42,7 +42,8 @@ KCOV_INSTRUMENT := n
>  # make up the standalone purgatory.ro
>  
>  PURGATORY_CFLAGS_REMOVE := -mcmodel=kernel
> -PURGATORY_CFLAGS := -mcmodel=large -ffreestanding -fno-zero-initialized-in-bss -g0
> +PURGATORY_CFLAGS := -mcmodel=small -ffreestanding -fno-zero-initialized-in-bss -g0
> +PURGATORY_CFLAGS += -fpic -fvisibility=hidden
>  PURGATORY_CFLAGS += $(DISABLE_STACKLEAK_PLUGIN) -DDISABLE_BRANCH_PROFILING
>  PURGATORY_CFLAGS += -fno-stack-protector
>  
> -- 
> 2.44.0.769.g3c40516874-goog
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3] rust: make mutually exclusive with CFI_CLANG
  @ 2024-04-04 15:32 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-04 15:32 UTC (permalink / raw)
  To: Conor Dooley
  Cc: linux-riscv, Conor Dooley, stable, Miguel Ojeda, Alex Gaynor,
	Wedson Almeida Filho, linux-kernel, rust-for-linux,
	Sami Tolvanen, Kees Cook, llvm

On Thu, Apr 04, 2024 at 03:17:02PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> On RISC-V and arm64, and presumably x86, if CFI_CLANG is enabled,
> loading a rust module will trigger a kernel panic. Support for
> sanitisers, including kcfi (CFI_CLANG), is in the works, but for now
> they're nightly-only options in rustc. Make RUST depend on !CFI_CLANG
> to prevent configuring a kernel without symmetrical support for kfi.
> 
> Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
> cc: stable@vger.kernel.org
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

Acked-by: Nathan Chancellor <nathan@kernel.org>

It seems like this won't be forgotten about but if there is not already
an issue open for this somewhere, it would be good to have one, since we
obviously want this for both C and Rust code.

As a general meta comment not directed at anyone in particualr, I think
these 'depends on !' should all have some sort of comment or description
as to why they are disabled. I can infer from most of them but it would
still be good to be explicit, especially since someone might want to
work on fixing the ones that are due to missing support and such.

> ---
> Sending this one on its own, there's no explicit dep on this for the
> riscv enabling patch, v3 to continue the numbering from there. Nothing
> has changed since v2.
> 
> CC: Miguel Ojeda <ojeda@kernel.org>
> CC: Alex Gaynor <alex.gaynor@gmail.com>
> CC: Wedson Almeida Filho <wedsonaf@gmail.com>
> CC: linux-kernel@vger.kernel.org (open list)
> CC: rust-for-linux@vger.kernel.org
> CC: Sami Tolvanen <samitolvanen@google.com>
> CC: Kees Cook <keescook@chromium.org>
> CC: Nathan Chancellor <nathan@kernel.org>
> CC: llvm@lists.linux.dev
> ---
>  init/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index aa02aec6aa7d..ad9a2da27dc9 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1899,6 +1899,7 @@ config RUST
>  	bool "Rust support"
>  	depends on HAVE_RUST
>  	depends on RUST_IS_AVAILABLE
> +	depends on !CFI_CLANG
>  	depends on !MODVERSIONS
>  	depends on !GCC_PLUGINS
>  	depends on !RANDSTRUCT
> -- 
> 2.43.0
> 
> 

^ permalink raw reply	[relevance 99%]

* [PATCH bluetooth] Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
@ 2024-04-01 18:24 78% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-01 18:24 UTC (permalink / raw)
  To: marcel, johan.hedberg, luiz.dentz
  Cc: ndesaulniers, morbo, justinstitt, keescook, linux-bluetooth,
	llvm, patches, stable, Nathan Chancellor

After an innocuous optimization change in LLVM main (19.0.0), x86_64
allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to
build due to the checks in check_copy_size():

  In file included from net/bluetooth/sco.c:27:
  In file included from include/linux/module.h:13:
  In file included from include/linux/stat.h:19:
  In file included from include/linux/time.h:60:
  In file included from include/linux/time32.h:13:
  In file included from include/linux/timex.h:67:
  In file included from arch/x86/include/asm/timex.h:6:
  In file included from arch/x86/include/asm/tsc.h:10:
  In file included from arch/x86/include/asm/msr.h:15:
  In file included from include/linux/percpu.h:7:
  In file included from include/linux/smp.h:118:
  include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small
    244 |                         __bad_copy_from();
        |                         ^

The same exact error occurs in l2cap_sock.c. The copy_to_user()
statements that are failing come from l2cap_sock_getsockopt_old() and
sco_sock_getsockopt_old(). This does not occur with GCC with or without
KCSAN or Clang without KCSAN enabled.

len is defined as an 'int' because it is assigned from
'__user int *optlen'. However, it is clamped against the result of
sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
platforms). This is done with min_t() because min() requires compatible
types, which results in both len and the result of sizeof() being casted
to 'unsigned int', meaning len changes signs and the result of sizeof()
is truncated. From there, len is passed to copy_to_user(), which has a
third parameter type of 'unsigned long', so it is widened and changes
signs again. This excessive casting in combination with the KCSAN
instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
call, failing the build.

The official recommendation from LLVM developers is to consistently use
long types for all size variables to avoid the unnecessary casting in
the first place. Change the type of len to size_t in both
l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears
up the error while allowing min_t() to be replaced with min(), resulting
in simpler code with no casts and fewer implicit conversions. While len
is a different type than optlen now, it should result in no functional
change because the result of sizeof() will clamp all values of optlen in
the same manner as before.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/2007
Link: https://github.com/llvm/llvm-project/issues/85647
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 net/bluetooth/l2cap_sock.c | 7 ++++---
 net/bluetooth/sco.c        | 7 ++++---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 4287aa6cc988..81193427bf05 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -439,7 +439,8 @@ static int l2cap_sock_getsockopt_old(struct socket *sock, int optname,
 	struct l2cap_chan *chan = l2cap_pi(sk)->chan;
 	struct l2cap_options opts;
 	struct l2cap_conninfo cinfo;
-	int len, err = 0;
+	int err = 0;
+	size_t len;
 	u32 opt;
 
 	BT_DBG("sk %p", sk);
@@ -486,7 +487,7 @@ static int l2cap_sock_getsockopt_old(struct socket *sock, int optname,
 
 		BT_DBG("mode 0x%2.2x", chan->mode);
 
-		len = min_t(unsigned int, len, sizeof(opts));
+		len = min(len, sizeof(opts));
 		if (copy_to_user(optval, (char *) &opts, len))
 			err = -EFAULT;
 
@@ -536,7 +537,7 @@ static int l2cap_sock_getsockopt_old(struct socket *sock, int optname,
 		cinfo.hci_handle = chan->conn->hcon->handle;
 		memcpy(cinfo.dev_class, chan->conn->hcon->dev_class, 3);
 
-		len = min_t(unsigned int, len, sizeof(cinfo));
+		len = min(len, sizeof(cinfo));
 		if (copy_to_user(optval, (char *) &cinfo, len))
 			err = -EFAULT;
 
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 43daf965a01e..9a72d7f1946c 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -967,7 +967,8 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname,
 	struct sock *sk = sock->sk;
 	struct sco_options opts;
 	struct sco_conninfo cinfo;
-	int len, err = 0;
+	int err = 0;
+	size_t len;
 
 	BT_DBG("sk %p", sk);
 
@@ -989,7 +990,7 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname,
 
 		BT_DBG("mtu %u", opts.mtu);
 
-		len = min_t(unsigned int, len, sizeof(opts));
+		len = min(len, sizeof(opts));
 		if (copy_to_user(optval, (char *)&opts, len))
 			err = -EFAULT;
 
@@ -1007,7 +1008,7 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname,
 		cinfo.hci_handle = sco_pi(sk)->conn->hcon->handle;
 		memcpy(cinfo.dev_class, sco_pi(sk)->conn->hcon->dev_class, 3);
 
-		len = min_t(unsigned int, len, sizeof(cinfo));
+		len = min(len, sizeof(cinfo));
 		if (copy_to_user(optval, (char *)&cinfo, len))
 			err = -EFAULT;
 

---
base-commit: 7835fcfd132eb88b87e8eb901f88436f63ab60f7
change-id: 20240401-bluetooth-fix-len-type-getsockopt_old-73c4a8e60444

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 78%]

* Re: FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 5.10-stable tree
  @ 2024-03-27 15:16 91% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-27 15:16 UTC (permalink / raw)
  To: Sasha Levin; +Cc: stable, Michael Ellerman, linuxppc-dev, linux-kernel, llvm

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Wed, Mar 27, 2024 at 08:20:07AM -0400, Sasha Levin wrote:
> The patch below does not apply to the 5.10-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
...
> ------------------ original commit in Linus's tree ------------------
> 
> From 35f20786c481d5ced9283ff42de5c69b65e5ed13 Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Sat, 27 Jan 2024 11:07:43 -0700
> Subject: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS

I have attached a backport that will work for 5.15 and earlier. I think
you worked around this conflict in 5.15 by taking 04e85bbf71c9 but I am
not sure that is a smart idea. I think it might just be better to drop
that dependency and apply this version in 5.15.

Cheers,
Nathan

[-- Attachment #2: 0001-powerpc-xor_vmx-Add-mhard-float-to-CFLAGS.patch --]
[-- Type: text/plain, Size: 1984 bytes --]

From c6cb80d94871cbb4ff151f7eb2586cadeb364ef7 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Sat, 27 Jan 2024 11:07:43 -0700
Subject: [PATCH 4.19 to 5.15] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS

commit 35f20786c481d5ced9283ff42de5c69b65e5ed13 upstream.

arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
error when building with clang after a recent change in main:

  error: option '-msoft-float' cannot be specified with '-maltivec'
  make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1

Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
to override the previous inclusion of '-msoft-float' (as the last option
wins), which matches how other areas of the kernel use '-maltivec', such
as AMDGPU.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240127-ppc-xor_vmx-drop-msoft-float-v1-1-f24140e81376@kernel.org
[nathan: Fixed conflicts due to lack of 04e85bbf71c9 in older trees]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/lib/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 321cab5c3ea0..bd5012aa94e3 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -67,6 +67,6 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
 obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
 
 obj-$(CONFIG_ALTIVEC)	+= xor_vmx.o xor_vmx_glue.o
-CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
+CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec)
 
 obj-$(CONFIG_PPC64) += $(obj64-y)
-- 
2.44.0


^ permalink raw reply related	[relevance 91%]

* [PATCH] hexagon: vmlinux.lds.S: Handle attributes section
@ 2024-03-20  0:37 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-20  0:37 UTC (permalink / raw)
  To: akpm, bcain
  Cc: ndesaulniers, morbo, justinstitt, linux-hexagon, llvm, patches,
	stable, Nathan Chancellor

After the linked LLVM change, the build fails with
CONFIG_LD_ORPHAN_WARN_LEVEL="error", which happens with allmodconfig:

  ld.lld: error: vmlinux.a(init/main.o):(.hexagon.attributes) is being placed in '.hexagon.attributes'

Handle the attributes section in a similar manner as arm and riscv by
adding it after the primary ELF_DETAILS grouping in vmlinux.lds.S, which
fixes the error.

Cc: stable@vger.kernel.org
Fixes: 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN")
Link: https://github.com/llvm/llvm-project/commit/31f4b329c8234fab9afa59494d7f8bdaeaefeaad
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/hexagon/kernel/vmlinux.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/hexagon/kernel/vmlinux.lds.S b/arch/hexagon/kernel/vmlinux.lds.S
index 1140051a0c45..1150b77fa281 100644
--- a/arch/hexagon/kernel/vmlinux.lds.S
+++ b/arch/hexagon/kernel/vmlinux.lds.S
@@ -63,6 +63,7 @@ SECTIONS
 	STABS_DEBUG
 	DWARF_DEBUG
 	ELF_DETAILS
+	.hexagon.attributes 0 : { *(.hexagon.attributes) }
 
 	DISCARDS
 }

---
base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
change-id: 20240319-hexagon-handle-attributes-section-vmlinux-lds-s-2a14b14799c0

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 99%]

* Re: [PATCH] memtest: use {READ,WRITE}_ONCE in memory scanning
  @ 2024-03-13 17:21 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-13 17:21 UTC (permalink / raw)
  To: Qiang Zhang
  Cc: Andrew Morton, Nick Desaulniers, Bill Wendling, Justin Stitt,
	linux-mm, linux-kernel, llvm, Stable

On Tue, Mar 12, 2024 at 04:04:23PM +0800, Qiang Zhang wrote:
> memtest failed to find bad memory when compiled with clang. So use
> {WRITE,READ}_ONCE  to access memory to avoid compiler over optimization.

This commit message is severely lacking in details in my opinion,
especially for a patch marked for stable. Did a kernel or LLVM change
cause this (i.e., has this always been an issue or is it a recent
regression)? What is the transformation that LLVM does to break the test
and why is using READ_ONCE() or WRITE_ONCE() sufficient to resolve it?

> Cc: <Stable@vger.kernel.org>
> Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
> ---
>  mm/memtest.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memtest.c b/mm/memtest.c
> index 32f3e9dda837..c2c609c39119 100644
> --- a/mm/memtest.c
> +++ b/mm/memtest.c
> @@ -51,10 +51,10 @@ static void __init memtest(u64 pattern, phys_addr_t start_phys, phys_addr_t size
>  	last_bad = 0;
>  
>  	for (p = start; p < end; p++)
> -		*p = pattern;
> +		WRITE_ONCE(*p, pattern);
>  
>  	for (p = start; p < end; p++, start_phys_aligned += incr) {
> -		if (*p == pattern)
> +		if (READ_ONCE(*p) == pattern)
>  			continue;
>  		if (start_phys_aligned == last_bad + incr) {
>  			last_bad += incr;
> -- 
> 2.39.2
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.15 45/76] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
  @ 2024-03-13 17:12 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-13 17:12 UTC (permalink / raw)
  To: Sasha Levin; +Cc: linux-kernel, stable, Masahiro Yamada

Hi Sasha,

On Wed, Mar 13, 2024 at 12:41:52PM -0400, Sasha Levin wrote:
> From: Nathan Chancellor <nathan@kernel.org>
> 
> [ Upstream commit 397586506c3da005b9333ce5947ad01e8018a3be ]
> 
> After the linked LLVM change, building ARCH=um defconfig results in a
> segmentation fault in modpost. Prior to commit a23e7584ecf3 ("modpost:
> unify 'sym' and 'to' in default_mismatch_handler()"), there was a
> warning:
> 
>   WARNING: modpost: vmlinux.o(__ex_table+0x88): Section mismatch in reference to the .ltext:(unknown)
>   WARNING: modpost: The relocation at __ex_table+0x88 references
>   section ".ltext" which is not in the list of
>   authorized sections.  If you're adding a new section
>   and/or if this reference is valid, add ".ltext" to the
>   list of authorized sections to jump to on fault.
>   This can be achieved by adding ".ltext" to
>   OTHER_TEXT_SECTIONS in scripts/mod/modpost.c.
> 
> The linked LLVM change moves global objects to the '.ltext' (and
> '.ltext.*' with '-ffunction-sections') sections with '-mcmodel=large',
> which ARCH=um uses. These sections should be handled just as '.text'
> and '.text.*' are, so add them to TEXT_SECTIONS.
> 
> Cc: stable@vger.kernel.org
> Closes: https://github.com/ClangBuiltLinux/linux/issues/1981
> Link: https://github.com/llvm/llvm-project/commit/4bf8a688956a759b7b6b8d94f42d25c13c7af130
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>

This causes a warning when building with HOSTCC=clang:

  scripts/mod/modpost.c:1123:37: warning: excess elements in array initializer [-Wexcess-initializers]
   1123 |         .good_tosec = {ALL_TEXT_SECTIONS , NULL},
        |                                            ^~~~
  .../lib/clang/17/include/stddef.h:89:16: note: expanded from macro 'NULL'
     89 | #  define NULL ((void*)0)
        |                ^~~~~~~~~~
  1 warning generated.

Same comment as on the other UML clang-18 patch, I do not think this is
necessary right now in 5.15 and earlier. The other modpost patch can go
as well, as it is only a prerequisite change.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
  @ 2024-03-06 16:48 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-06 16:48 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: npiggin, christophe.leroy, aneesh.kumar, naveen.n.rao, morbo,
	justinstitt, linuxppc-dev, patches, llvm, stable

On Wed, Mar 06, 2024 at 12:01:42PM +1100, Michael Ellerman wrote:
> Nathan Chancellor <nathan@kernel.org> writes:
> > Ping? We have been applying this in our CI since it was sent, it would
> > be nice to have this upstream soon so it can start filtering through the
> > stable trees.
> 
> Sorry, I was away in January and missed this. Will pick it up.

No worries, I've done that more times than I would like to admit. Thanks
a lot for the quick response and picking it up!

Cheers,
Nathan

> > On Sat, Jan 27, 2024 at 11:07:43AM -0700, Nathan Chancellor wrote:
> >> arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
> >> powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
> >> error when building with clang after a recent change in main:
> >> 
> >>   error: option '-msoft-float' cannot be specified with '-maltivec'
> >>   make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1
> >> 
> >> Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
> >> to override the previous inclusion of '-msoft-float' (as the last option
> >> wins), which matches how other areas of the kernel use '-maltivec', such
> >> as AMDGPU.
> >> 
> >> Cc: stable@vger.kernel.org
> >> Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
> >> Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c
> >> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> >> ---
> >>  arch/powerpc/lib/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> >> index 6eac63e79a89..0ab65eeb93ee 100644
> >> --- a/arch/powerpc/lib/Makefile
> >> +++ b/arch/powerpc/lib/Makefile
> >> @@ -76,7 +76,7 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
> >>  obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
> >>  
> >>  obj-$(CONFIG_ALTIVEC)	+= xor_vmx.o xor_vmx_glue.o
> >> -CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
> >> +CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec)
> >>  # Enable <altivec.h>
> >>  CFLAGS_xor_vmx.o += -isystem $(shell $(CC) -print-file-name=include)
> >>  
> >> 
> >> ---
> >> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> >> change-id: 20240127-ppc-xor_vmx-drop-msoft-float-ad68b437f86c
> >> 
> >> Best regards,
> >> -- 
> >> Nathan Chancellor <nathan@kernel.org>
> >> 
> 

^ permalink raw reply	[relevance 99%]

* [PATCH v2] media: mxl5xx: Move xpt structures off stack
@ 2024-03-05 22:49 83% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-05 22:49 UTC (permalink / raw)
  To: mchehab
  Cc: ndesaulniers, morbo, justinstitt, linux-media, llvm, patches,
	stable, Miguel Ojeda, Nathan Chancellor

When building for LoongArch with clang 18.0.0, the stack usage of
probe() is larger than the allowed 2048 bytes:

  drivers/media/dvb-frontends/mxl5xx.c:1698:12: warning: stack frame size (2368) exceeds limit (2048) in 'probe' [-Wframe-larger-than]
   1698 | static int probe(struct mxl *state, struct mxl5xx_cfg *cfg)
        |            ^
  1 warning generated.

This is the result of the linked LLVM commit, which changes how the
arrays of structures in config_ts() get handled with
CONFIG_INIT_STACK_ZERO and CONFIG_INIT_STACK_PATTERN, which causes the
above warning in combination with inlining, as config_ts() gets inlined
into probe().

This warning can be easily fixed by moving the array of structures off
of the stack via 'static const', which is a better location for these
variables anyways because they are static data that is only ever read
from, never modified, so allocating the stack space is wasteful.

This drops the stack usage from 2368 bytes to 256 bytes with the same
compiler and configuration.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1978
Link: https://github.com/llvm/llvm-project/commit/afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Changes in v2:
- Rebase on latest media tree
- Fix typo and link in the commit message (Miguel)
- Pick up Miguel's reviewed-by and tested-by tags
- Link to v1: https://lore.kernel.org/r/20240111-dvb-mxl5xx-move-structs-off-stack-v1-1-ca4230e67c11@kernel.org
---
 drivers/media/dvb-frontends/mxl5xx.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/mxl5xx.c b/drivers/media/dvb-frontends/mxl5xx.c
index 4ebbcf05cc09..91e9c378397c 100644
--- a/drivers/media/dvb-frontends/mxl5xx.c
+++ b/drivers/media/dvb-frontends/mxl5xx.c
@@ -1381,57 +1381,57 @@ static int config_ts(struct mxl *state, enum MXL_HYDRA_DEMOD_ID_E demod_id,
 	u32 nco_count_min = 0;
 	u32 clk_type = 0;
 
-	struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 8, 1}, {0x90700010, 9, 1},
 		{0x90700010, 10, 1}, {0x90700010, 11, 1},
 		{0x90700010, 12, 1}, {0x90700010, 13, 1},
 		{0x90700010, 14, 1}, {0x90700010, 15, 1} };
-	struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 16, 1}, {0x90700010, 17, 1},
 		{0x90700010, 18, 1}, {0x90700010, 19, 1},
 		{0x90700010, 20, 1}, {0x90700010, 21, 1},
 		{0x90700010, 22, 1}, {0x90700010, 23, 1} };
-	struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700014, 0, 1}, {0x90700014, 1, 1},
 		{0x90700014, 2, 1}, {0x90700014, 3, 1},
 		{0x90700014, 4, 1}, {0x90700014, 5, 1},
 		{0x90700014, 6, 1}, {0x90700014, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700018, 0, 3}, {0x90700018, 4, 3},
 		{0x90700018, 8, 3}, {0x90700018, 12, 3},
 		{0x90700018, 16, 3}, {0x90700018, 20, 3},
 		{0x90700018, 24, 3}, {0x90700018, 28, 3} };
-	struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 16, 1}, {0x9070000C, 17, 1},
 		{0x9070000C, 18, 1}, {0x9070000C, 19, 1},
 		{0x9070000C, 20, 1}, {0x9070000C, 21, 1},
 		{0x9070000C, 22, 1}, {0x9070000C, 23, 1} };
-	struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 0, 1}, {0x90700010, 1, 1},
 		{0x90700010, 2, 1}, {0x90700010, 3, 1},
 		{0x90700010, 4, 1}, {0x90700010, 5, 1},
 		{0x90700010, 6, 1}, {0x90700010, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 0, 1}, {0x9070000C, 1, 1},
 		{0x9070000C, 2, 1}, {0x9070000C, 3, 1},
 		{0x9070000C, 4, 1}, {0x9070000C, 5, 1},
 		{0x9070000C, 6, 1}, {0x9070000C, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 24, 1}, {0x9070000C, 25, 1},
 		{0x9070000C, 26, 1}, {0x9070000C, 27, 1},
 		{0x9070000C, 28, 1}, {0x9070000C, 29, 1},
 		{0x9070000C, 30, 1}, {0x9070000C, 31, 1} };
-	struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700014, 8, 1}, {0x90700014, 9, 1},
 		{0x90700014, 10, 1}, {0x90700014, 11, 1},
 		{0x90700014, 12, 1}, {0x90700014, 13, 1},
 		{0x90700014, 14, 1}, {0x90700014, 15, 1} };
-	struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
 		{0x907001D4, 0, 1}, {0x907001D4, 1, 1},
 		{0x907001D4, 2, 1}, {0x907001D4, 3, 1},
 		{0x907001D4, 4, 1}, {0x907001D4, 5, 1},
 		{0x907001D4, 6, 1}, {0x907001D4, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700044, 16, 80}, {0x90700044, 16, 81},
 		{0x90700044, 16, 82}, {0x90700044, 16, 83},
 		{0x90700044, 16, 84}, {0x90700044, 16, 85},

---
base-commit: 8c64f4cdf4e6cc5682c52523713af8c39c94e6d5
change-id: 20240111-dvb-mxl5xx-move-structs-off-stack-e12172b1ef02

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 83%]

* Re: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
  2024-01-27 18:07 96% [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS Nathan Chancellor
@ 2024-03-05 22:43 99% ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-05 22:43 UTC (permalink / raw)
  To: mpe
  Cc: npiggin, christophe.leroy, aneesh.kumar, naveen.n.rao, morbo,
	justinstitt, linuxppc-dev, patches, llvm, stable

Ping? We have been applying this in our CI since it was sent, it would
be nice to have this upstream soon so it can start filtering through the
stable trees.

On Sat, Jan 27, 2024 at 11:07:43AM -0700, Nathan Chancellor wrote:
> arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
> powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
> error when building with clang after a recent change in main:
> 
>   error: option '-msoft-float' cannot be specified with '-maltivec'
>   make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1
> 
> Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
> to override the previous inclusion of '-msoft-float' (as the last option
> wins), which matches how other areas of the kernel use '-maltivec', such
> as AMDGPU.
> 
> Cc: stable@vger.kernel.org
> Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
> Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/powerpc/lib/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 6eac63e79a89..0ab65eeb93ee 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -76,7 +76,7 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
>  obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
>  
>  obj-$(CONFIG_ALTIVEC)	+= xor_vmx.o xor_vmx_glue.o
> -CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
> +CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec)
>  # Enable <altivec.h>
>  CFLAGS_xor_vmx.o += -isystem $(shell $(CC) -print-file-name=include)
>  
> 
> ---
> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> change-id: 20240127-ppc-xor_vmx-drop-msoft-float-ad68b437f86c
> 
> Best regards,
> -- 
> Nathan Chancellor <nathan@kernel.org>
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] kbuild: Disable two Clang specific enumeration warnings
  @ 2024-03-05 22:14 99%         ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-05 22:14 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Nick Desaulniers, Masahiro Yamada, Nicolas Schier, Bill Wendling,
	Justin Stitt, Yonghong Song, linux-kbuild, llvm, patches, stable

On Tue, Mar 05, 2024 at 10:52:54PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 5, 2024, at 20:30, Nathan Chancellor wrote:
> > On Tue, Mar 05, 2024 at 10:52:16AM -0800, Nick Desaulniers wrote:
> >> On Tue, Mar 5, 2024 at 10:50 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >> >
> >> > On Tue, Mar 5, 2024, at 18:42, Nathan Chancellor wrote:
> >> > >
> >> > > As the warnings do not appear to have a high signal to noise ratio and
> >> > > the source level silencing options are not sustainable, disable the
> >> > > warnings unconditionally, as they will be enabled with -Wenum-conversion
> >> > > and are supported in all versions of clang that can build the kernel.
> >> >
> >> > I took a look at a sample of warnings in an allmodconfig build
> >> > and found a number that need attention. I would much prefer to
> >> > leave these turned on at the W=1 level and only disable them
> >> > at the default warning level.
> >> 
> >> Sounds like these new diagnostics are very noisy. 0day bot sends
> >> people reports at W=1. Perhaps W=2?
> 
> It feels like this is not a great reason for moving it to W=2
> instead of W=1, but W=2 is still better than always disabling
> it I think.
> 
> Specifically, the 0day bot warns for newly added W=1 warnings
> but not for preexisting ones, and I think there are other warnings
> at the W=1 level that are similarly noisy to this one.
> 
> > A number of subsystems test with W=1 as well and while opting into W=1
> > means that you are potentially asking for new warnings across newer
> > compiler releases, a warning with this number of instances is going to
> > cause a lot of issues (I think of netdev for example).
> 
> I only see a handful of warnings in net (devlink, bpf) and
> drivers/net (ethernet/{3com,amd8111e,funeth,hns,idpf,jme,mlx4} and
> wireless/{iwlwifi,mt76,rtw88,rtw89}). 
> 
> These are also some of the ones that I think need a closer look.

Fair enough, I have sent v2 that just moves these warnings to W=1.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH v2] kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1
@ 2024-03-05 22:12 88% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-05 22:12 UTC (permalink / raw)
  To: masahiroy
  Cc: nicolas, ndesaulniers, morbo, justinstitt, arnd, yonghong.song,
	linux-kbuild, llvm, patches, stable, Nathan Chancellor

Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional
under -Wenum-conversion. A recent change in Clang strengthened these
warnings and they appear frequently in common builds, primarily due to
several instances in common headers but there are quite a few drivers
that have individual instances as well.

  include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
    508 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
        |                            ~~~~~~~~~~~~~~~~~~~~~ ^
    509 |                            item];
        |                            ~~~~

  drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
    955 |                 flags |= is_new_rate ? IWL_MAC_BEACON_CCK
        |                                      ^ ~~~~~~~~~~~~~~~~~~
    956 |                           : IWL_MAC_BEACON_CCK_V1;
        |                             ~~~~~~~~~~~~~~~~~~~~~
  drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
   1120 |                                                0) > 10 ?
        |                                                        ^
   1121 |                         IWL_MAC_BEACON_FILS :
        |                         ~~~~~~~~~~~~~~~~~~~
   1122 |                         IWL_MAC_BEACON_FILS_V1;
        |                         ~~~~~~~~~~~~~~~~~~~~~~

Doing arithmetic between or returning two different types of enums could
be a bug, so each of the instance of the warning needs to be evaluated.
Unfortunately, as mentioned above, there are many instances of this
warning in many different configurations, which can break the build when
CONFIG_WERROR is enabled.

To avoid introducing new instances of the warnings while cleaning up the
disruption for the majority of users, disable these warnings for the
default build while leaving them on for W=1 builds.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/2002
Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Changes in v2:
- Only disable the warning for the default build, leave it on for W=1 (Arnd)
- Add Yonghong's ack, as the warning is still disabled for the default
  build.
- Link to v1: https://lore.kernel.org/r/20240305-disable-extra-clang-enum-warnings-v1-1-6a93ef3d35ff@kernel.org
---
 scripts/Makefile.extrawarn | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index a9e552a1e910..2f25a1de129d 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -132,6 +132,8 @@ KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
 KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare
 KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
 KBUILD_CFLAGS += $(call cc-disable-warning, cast-function-type-strict)
+KBUILD_CFLAGS += -Wno-enum-compare-conditional
+KBUILD_CFLAGS += -Wno-enum-enum-conversion
 endif
 
 endif

---
base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
change-id: 20240304-disable-extra-clang-enum-warnings-bf574c7c99fd

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 88%]

* Re: [PATCH] kbuild: Disable two Clang specific enumeration warnings
  @ 2024-03-05 19:30 95%     ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-05 19:30 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Arnd Bergmann, Masahiro Yamada, Nicolas Schier, Bill Wendling,
	Justin Stitt, Yonghong Song, linux-kbuild, llvm, patches, stable

On Tue, Mar 05, 2024 at 10:52:16AM -0800, Nick Desaulniers wrote:
> On Tue, Mar 5, 2024 at 10:50 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Mar 5, 2024, at 18:42, Nathan Chancellor wrote:
> > >
> > > As the warnings do not appear to have a high signal to noise ratio and
> > > the source level silencing options are not sustainable, disable the
> > > warnings unconditionally, as they will be enabled with -Wenum-conversion
> > > and are supported in all versions of clang that can build the kernel.
> >
> > I took a look at a sample of warnings in an allmodconfig build
> > and found a number that need attention. I would much prefer to
> > leave these turned on at the W=1 level and only disable them
> > at the default warning level.
> 
> Sounds like these new diagnostics are very noisy. 0day bot sends
> people reports at W=1. Perhaps W=2?

A number of subsystems test with W=1 as well and while opting into W=1
means that you are potentially asking for new warnings across newer
compiler releases, a warning with this number of instances is going to
cause a lot of issues (I think of netdev for example).

I think if we are going to leave it enabled at W=2, we might as well
just take this change as is then have people who are developing the
fixes use 'KCFLAGS=-Wenum-conversion' when building to override it,
which is more targeted than using W=2. W=2 is not run by any CI as far
as I am aware, so there is not really any difference between disabled
altogether vs.  enabled at W=2 in terms of widespread testing. Once all
the fixes (or patches to hide instances) are picked up and merged into
Linus's tree, this change can just be reverted.

Fundamentally, I do not really care which avenue we take (either this
change or off by default, on at W=1), I am happy to do whatever.
Unfortunately, CONFIG_WERROR makes these decisions much more urgent
because it is either disable it and have other warnings creep in amongst
the sprawl of these warnings or leave it on and miss other errors for
the same reason.

Cheers,
Nathan

^ permalink raw reply	[relevance 95%]

* [PATCH] kbuild: Disable two Clang specific enumeration warnings
@ 2024-03-05 17:42 87% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-05 17:42 UTC (permalink / raw)
  To: masahiroy
  Cc: nicolas, ndesaulniers, morbo, justinstitt, arnd, yonghong.song,
	linux-kbuild, llvm, patches, stable, Nathan Chancellor

Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional
under -Wenum-conversion. A recent change in Clang strengthened these
warnings and they appear frequently in common builds, primarily due to
several instances in common headers but there are quite a few drivers
that have individual instances as well.

  include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
    508 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
        |                            ~~~~~~~~~~~~~~~~~~~~~ ^
    509 |                            item];
        |                            ~~~~

  drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
    955 |                 flags |= is_new_rate ? IWL_MAC_BEACON_CCK
        |                                      ^ ~~~~~~~~~~~~~~~~~~
    956 |                           : IWL_MAC_BEACON_CCK_V1;
        |                             ~~~~~~~~~~~~~~~~~~~~~
  drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
   1120 |                                                0) > 10 ?
        |                                                        ^
   1121 |                         IWL_MAC_BEACON_FILS :
        |                         ~~~~~~~~~~~~~~~~~~~
   1122 |                         IWL_MAC_BEACON_FILS_V1;
        |                         ~~~~~~~~~~~~~~~~~~~~~~

While doing arithmetic with different types of enums may be potentially
problematic, inspecting several instances of the warning does not reveal
any obvious problems. To silence the warnings at the source level, an
integral cast must be added to each mismatched enum (which is incredibly
ugly when done frequently) or the value must moved out of the enum to a
macro, which can remove the type safety offered by enums in other
places, such as assignments that would trigger -Wenum-conversion.

As the warnings do not appear to have a high signal to noise ratio and
the source level silencing options are not sustainable, disable the
warnings unconditionally, as they will be enabled with -Wenum-conversion
and are supported in all versions of clang that can build the kernel.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/2002
Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/Makefile.extrawarn | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index a9e552a1e910..6053aa22b8f5 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -81,6 +81,14 @@ KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init)
 
 # Warn if there is an enum types mismatch
 KBUILD_CFLAGS += $(call cc-option,-Wenum-conversion)
+ifdef CONFIG_CC_IS_CLANG
+# Clang enables these extra warnings under -Wenum-conversion but the kernel
+# performs arithmetic using or has conditionals returning enums of different
+# types in several different places, which is rarely a bug in the kernel's
+# case, so disable the warnings.
+KBUILD_CFLAGS += -Wno-enum-compare-conditional
+KBUILD_CFLAGS += -Wno-enum-enum-conversion
+endif
 
 #
 # W=1 - warnings which may be relevant and do not occur too often

---
base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
change-id: 20240304-disable-extra-clang-enum-warnings-bf574c7c99fd

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 87%]

* Re: 6.6.19 won't compile with " [*] Compile the kernel with warnings as errors"
  @ 2024-03-01 17:56 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-01 17:56 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, Rainer Fiebig

On Fri, Mar 01, 2024 at 03:42:17PM +0100, Rainer Fiebig wrote:
> fs/ntfs3/frecord.c: In Funktion »ni_read_frame«:
> fs/ntfs3/frecord.c:2460:16: Error: variable >>i_size<< is not used"
> [-Werror=unused-variable]
>  2460 |         loff_t i_size = i_size_read(&ni->vfs_inode);
>       |                ^~~~~~

This is a regression that was inherited from mainline because
commit 4fd6c08a16d7 ("fs/ntfs3: Use i_size_read and i_size_write") was
applied to stable without commit c8e314624a16 ("fs/ntfs3: fix build
without CONFIG_NTFS3_LZX_XPRESS").

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Please apply commit 5b750b22530fe53bf7fd6a30baacd53ada26911b to linux-6.1.y
@ 2024-02-28  1:45 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28  1:45 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: amd-gfx, stable, llvm

Hi Greg and Sasha,

Please apply upstream commit 5b750b22530f ("drm/amd/display: Increase
frame warning limit with KASAN or KCSAN in dml") to linux-6.1.y, as it
is needed to avoid instances of -Wframe-larger-than in allmodconfig,
which has -Werror enabled. It applies cleanly for me and it is already
in 6.6 and 6.7. The fixes tag is not entirely accurate and commit
e63e35f0164c ("drm/amd/display: Increase frame-larger-than for all
display_mode_vba files"), which was recently applied to that tree,
depends on it (I should have made that clearer in the patch).

If there are any issues, please let me know.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Please apply 56778b49c9a2cbc32c6b0fbd3ba1a9d64192d3af to linux-6.7.y
@ 2024-02-25 19:47 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-25 19:47 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: David Gow, Sami Tolvanen, Erhard Furtner, stable, llvm

Hi Greg and Sasha,

Please apply commit 56778b49c9a2 ("kunit: Add a macro to wrap a deferred
action function") to the 6.7 branch, as there are reported kCFI failures
that are resolved by that change:

https://github.com/ClangBuiltLinux/linux/issues/1998

It applies cleanly for me. We may want this in earlier branches as well
but there are some conflicts that I did not have too much time to look
at, we can always wait for other reports to come in before going further
back as well.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH net] xfrm: Avoid clang fortify warning in copy_to_user_tmpl()
@ 2024-02-21 21:46 92% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-21 21:46 UTC (permalink / raw)
  To: steffen.klassert, herbert, davem
  Cc: edumazet, kuba, pabeni, morbo, justinstitt, keescook, netdev,
	llvm, patches, stable, Nathan Chancellor

After a couple recent changes in LLVM, there is a warning (or error with
CONFIG_WERROR=y or W=e) from the compile time fortify source routines,
specifically the memset() in copy_to_user_tmpl().

  In file included from net/xfrm/xfrm_user.c:14:
  ...
  include/linux/fortify-string.h:438:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
    438 |                         __write_overflow_field(p_size_field, size);
        |                         ^
  1 error generated.

While ->xfrm_nr has been validated against XFRM_MAX_DEPTH when its value
is first assigned in copy_templates() by calling validate_tmpl() first
(so there should not be any issue in practice), LLVM/clang cannot really
deduce that across the boundaries of these functions. Without that
knowledge, it cannot assume that the loop stops before i is greater than
XFRM_MAX_DEPTH, which would indeed result a stack buffer overflow in the
memset().

To make the bounds of ->xfrm_nr clear to the compiler and add additional
defense in case copy_to_user_tmpl() is ever used in a path where
->xfrm_nr has not been properly validated against XFRM_MAX_DEPTH first,
add an explicit bound check and early return, which clears up the
warning.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1985
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 net/xfrm/xfrm_user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index f037be190bae..912c1189ba41 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2017,6 +2017,9 @@ static int copy_to_user_tmpl(struct xfrm_policy *xp, struct sk_buff *skb)
 	if (xp->xfrm_nr == 0)
 		return 0;
 
+	if (xp->xfrm_nr > XFRM_MAX_DEPTH)
+		return -ENOBUFS;
+
 	for (i = 0; i < xp->xfrm_nr; i++) {
 		struct xfrm_user_tmpl *up = &vec[i];
 		struct xfrm_tmpl *kp = &xp->xfrm_vec[i];

---
base-commit: 14dec56fdd4c70a0ebe40077368e367421ea6fef
change-id: 20240221-xfrm-avoid-clang-fortify-warning-copy_to_user_tmpl-40cb10b003e3

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 92%]

* Re: [PATCH 5.15 380/476] kbuild: Fix changing ELF file type for output of gen_btf for big endian
  @ 2024-02-21 16:54 98%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-21 16:54 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: stable, patches, Masahiro Yamada, Fangrui Song, Nicolas Schier,
	Kees Cook, Justin Stitt

Hi Greg,

On Wed, Feb 21, 2024 at 02:07:11PM +0100, Greg Kroah-Hartman wrote:
> 5.15-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Nathan Chancellor <nathan@kernel.org>
> 
> commit e3a9ee963ad8ba677ca925149812c5932b49af69 upstream.
> 
> Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
> changed the ELF type of .btf.vmlinux.bin.o to ET_REL via dd, which works
> fine for little endian platforms:
> 
>    00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
>   -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
>   +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
> 
> However, for big endian platforms, it changes the wrong byte, resulting
> in an invalid ELF file type, which ld.lld rejects:
> 
>    00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
>   -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
>   +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> 
>   Type:                              <unknown>: 103
> 
>   ld.lld: error: .btf.vmlinux.bin.o: unknown file type
> 
> Fix this by updating the entire 16-bit e_type field rather than just a
> single byte, so that everything works correctly for all platforms and
> linkers.
> 
>    00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
>   -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
>   +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> 
>   Type:                              REL (Relocatable file)
> 
> While in the area, update the comment to mention that binutils 2.35+
> matches LLD's behavior of rejecting an ET_EXEC input, which occurred
> after the comment was added.
> 
> Cc: stable@vger.kernel.org
> Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
> Link: https://github.com/llvm/llvm-project/pull/75643
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Reviewed-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Justin Stitt <justinstitt@google.com>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  scripts/link-vmlinux.sh |    9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -236,8 +236,13 @@ gen_btf()
>  	${OBJCOPY} --only-section=.BTF --set-section-flags .BTF=alloc,readonly \
>  		--strip-all ${1} ${2} 2>/dev/null
>  	# Change e_type to ET_REL so that it can be used to link final vmlinux.
> -	# Unlike GNU ld, lld does not allow an ET_EXEC input.
> -	printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> +	# GNU ld 2.35+ and lld do not allow an ET_EXEC input.
> +	if is_enabled CONFIG_CPU_BIG_ENDIAN; then

You may have missed my mail on the email saying this had been applied (I
didn't cc a lore list so no link):

I do not think this backport is correct for trees that do not have
commit 7d153696e5db ("kbuild: do not include include/config/auto.conf
from shell scripts"), even if it applies cleanly, as is_enabled() is not
available.

I think this diff should be squashed in to the patch for 5.15 and
earlier, you can add

  [nathan: Fix silent conflict due to lack of 7d153696e5db in older trees]
  Signed-off-by: Nathan Chancellor <nathan@kernel.org>

to the resulting patch if you would like.

Cheers,
Nathan

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 007bb773b222..5a5a0cfad69d 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -237,7 +237,7 @@ gen_btf()
 		--strip-all ${1} ${2} 2>/dev/null
 	# Change e_type to ET_REL so that it can be used to link final vmlinux.
 	# GNU ld 2.35+ and lld do not allow an ET_EXEC input.
-	if is_enabled CONFIG_CPU_BIG_ENDIAN; then
+	if [ -n "${CONFIG_CPU_BIG_ENDIAN}" ]; then
 		et_rel='\0\1'
 	else
 		et_rel='\1\0'

^ permalink raw reply related	[relevance 98%]

* [PATCH v2] kbuild: Fix changing ELF file type for output of gen_btf for big endian
@ 2024-02-13  2:05 85% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-13  2:05 UTC (permalink / raw)
  To: masahiroy
  Cc: nicolas, ndesaulniers, morbo, justinstitt, keescook, maskray,
	linux-kbuild, bpf, llvm, patches, stable, Nathan Chancellor

Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
changed the ELF type of .btf.vmlinux.bin.o to ET_REL via dd, which works
fine for little endian platforms:

   00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
  +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|

However, for big endian platforms, it changes the wrong byte, resulting
in an invalid ELF file type, which ld.lld rejects:

   00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
  +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|

  Type:                              <unknown>: 103

  ld.lld: error: .btf.vmlinux.bin.o: unknown file type

Fix this by updating the entire 16-bit e_type field rather than just a
single byte, so that everything works correctly for all platforms and
linkers.

   00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
  +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|

  Type:                              REL (Relocatable file)

While in the area, update the comment to mention that binutils 2.35+
matches LLD's behavior of rejecting an ET_EXEC input, which occurred
after the comment was added.

Cc: stable@vger.kernel.org
Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
Link: https://github.com/llvm/llvm-project/pull/75643
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Changes in v2:
- Rather than change the seek value for dd, update the entire e_type
  field (Masahiro). Due to this change, I did not carry forward the
  tags of v1.
- Slightly update commit message to remove mention of ET_EXEC, which
  does not match the dump (Masahiro).
- Update comment to mention binutils 2.35+ has the same behavior as LLD
  (Fangrui).
- Link to v1: https://lore.kernel.org/r/20240208-fix-elf-type-btf-vmlinux-bin-o-big-endian-v1-1-cb3112491edc@kernel.org
---
 scripts/link-vmlinux.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index a432b171be82..7862a8101747 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -135,8 +135,13 @@ gen_btf()
 	${OBJCOPY} --only-section=.BTF --set-section-flags .BTF=alloc,readonly \
 		--strip-all ${1} ${2} 2>/dev/null
 	# Change e_type to ET_REL so that it can be used to link final vmlinux.
-	# Unlike GNU ld, lld does not allow an ET_EXEC input.
-	printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
+	# GNU ld 2.35+ and lld do not allow an ET_EXEC input.
+	if is_enabled CONFIG_CPU_BIG_ENDIAN; then
+		et_rel='\0\1'
+	else
+		et_rel='\1\0'
+	fi
+	printf "${et_rel}" | dd of=${2} conv=notrunc bs=1 seek=16 status=none
 }
 
 # Create ${2} .S file with all symbols from the ${1} object file

---
base-commit: 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478
change-id: 20240208-fix-elf-type-btf-vmlinux-bin-o-big-endian-dbc55a1e1296

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 85%]

* Re: [PATCH] kbuild: Fix changing ELF file type for output of gen_btf for big endian
  @ 2024-02-13  1:43 96%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-13  1:43 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: nicolas, ndesaulniers, morbo, justinstitt, keescook, maskray,
	linux-kbuild, bpf, llvm, patches, stable

On Tue, Feb 13, 2024 at 09:55:07AM +0900, Masahiro Yamada wrote:
> On Fri, Feb 9, 2024 at 5:21 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
> > changed the ELF type of .btf.vmlinux.bin.o from ET_EXEC to ET_REL via
> > dd, which works fine for little endian platforms:
> >
> >    00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
> >   -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
> 
> I am afraid this dump is confusing.
> 
> The byte stream "03 00" is ET_DYN, as specified in ELF:
> 
>   Name        Value
>   ------------------
>   ET_REL        1
>   ET_EXEC       2
>   ET_DYN        3
> 
> It disagrees with your commit message "from ET_EXEC to ET_REL"
> 
> The dump for the old ELF was "02 00", wasn't it?

No, I have not manually edited or changed these diffs from hexdumping
the .o files. The little endian one was from arm64 and the big endian
one was from s390. Perhaps this is some difference between the
toolchains? I don't recall which one I used in this case, pretty sure it
was GNU though. I can just remove "from ET_EXEC" from the commit message
if that would help make it less confusing.

> >   +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
> >
> > However, for big endian platforms, it changes the wrong byte, resulting
> > in an invalid ELF file type, which ld.lld rejects:
> 
> Fangrui pointed out this is true for inutils >= 2.35

Not for this particular error, which occurs because e_type is not a
valid value. If it was true for binutils, we would have seen this issue
sooner.

> >
> >    00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
> >   -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> >   +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> 
>  -  00 02
>  +  01 02

See above.

> >
> >   Type:                              <unknown>: 103
> >
> >   ld.lld: error: .btf.vmlinux.bin.o: unknown file type
> >
> > Fix this by using a different seek value for dd when targeting big
> > endian, so that the correct byte gets changed and everything works
> > correctly for all linkers.
> >
> >    00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
> >   -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> 
> Ditto.

See above.

> >   +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
> >
> >   Type:                              REL (Relocatable file)
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
> > Link: https://github.com/llvm/llvm-project/pull/75643
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> >  scripts/link-vmlinux.sh | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> > index a432b171be82..8a9f48b3cb32 100755
> > --- a/scripts/link-vmlinux.sh
> > +++ b/scripts/link-vmlinux.sh
> > @@ -135,8 +135,15 @@ gen_btf()
> >         ${OBJCOPY} --only-section=.BTF --set-section-flags .BTF=alloc,readonly \
> >                 --strip-all ${1} ${2} 2>/dev/null
> >         # Change e_type to ET_REL so that it can be used to link final vmlinux.
> > -       # Unlike GNU ld, lld does not allow an ET_EXEC input.
> > -       printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> > +       # Unlike GNU ld, lld does not allow an ET_EXEC input. Make sure the correct
> > +       # byte gets changed with big endian platforms, otherwise e_type may be an
> > +       # invalid value.
> > +       if is_enabled CONFIG_CPU_BIG_ENDIAN; then
> > +               seek=17
> > +       else
> > +               seek=16
> > +       fi
> > +       printf '\1' | dd of=${2} conv=notrunc bs=1 seek=${seek} status=none
> >  }
> >
> >  # Create ${2} .S file with all symbols from the ${1} object file
> 
> Do you want to send v2 to update the commit description?
> 

I don't think a v2 is necessary for the commit description...

> The current code will work, but another approach might be to
> update both byte 16 and byte 17 because e_type is a 16-bit field.
> 
> It works without relying on the MSB of the previous e_type being zero.
> The comment does not need updating because the intention is obvious
> from the code.
> 
> if is_enabled CONFIG_CPU_BIG_ENDIAN; then
>         et_rel='\0\1'
> else
>         et_rel='\1\0'
> fi
> 
> printf "${et_rel}" | dd of=${2} conv=notrunc bs=1 seek=16 status=none

but I do like this suggested change because I was thinking that updating
the single bit could be fragile at some point. I'll send a v2 with that
and a slightly updated commit message shortly. Because it is
substantially different from v1, I won't carry forward all the tags I
received but I hope people will take a look at v2 and provide them
again.

Thanks a lot for taking a look!
Nathan

^ permalink raw reply	[relevance 96%]

* Re: [PATCH] media: mxl5xx: Move xpt structures off stack
  @ 2024-02-12 23:27 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-12 23:27 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: justinstitt, linux-media, llvm, mchehab, morbo, ndesaulniers,
	patches, stable

On Sat, Feb 10, 2024 at 05:26:04PM +0100, Miguel Ojeda wrote:
> > On Thu, 11 Jan 2024 17:40:36 -0700 Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1977
> 
> The next one: 1978 :)

This is probably the third link I have messed up in the past couple of
weeks :/ Mauro, do you want a v2 for these two minor issues or can you
fix them up during application?

> > of the stackvia 'static const', which is a better location for these
> 
> Nit: space.
> 
> Built-tested for loongarch64:
> 
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Tested-by: Miguel Ojeda <ojeda@kernel.org>
> 
> With this applied, I have a `WERROR`-clean `defconfig` build with a Rust-enabled
> kernel using LLVM 18 (using LLVM-provided apt pre-releases).

Thanks for taking a look, this is great to hear!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH] kbuild: Fix changing ELF file type for output of gen_btf for big endian
@ 2024-02-08 20:21 88% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-08 20:21 UTC (permalink / raw)
  To: masahiroy
  Cc: nicolas, ndesaulniers, morbo, justinstitt, keescook, maskray,
	linux-kbuild, bpf, llvm, patches, stable, Nathan Chancellor

Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
changed the ELF type of .btf.vmlinux.bin.o from ET_EXEC to ET_REL via
dd, which works fine for little endian platforms:

   00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
  +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|

However, for big endian platforms, it changes the wrong byte, resulting
in an invalid ELF file type, which ld.lld rejects:

   00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
  +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|

  Type:                              <unknown>: 103

  ld.lld: error: .btf.vmlinux.bin.o: unknown file type

Fix this by using a different seek value for dd when targeting big
endian, so that the correct byte gets changed and everything works
correctly for all linkers.

   00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
  -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
  +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|

  Type:                              REL (Relocatable file)

Cc: stable@vger.kernel.org
Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
Link: https://github.com/llvm/llvm-project/pull/75643
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/link-vmlinux.sh | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index a432b171be82..8a9f48b3cb32 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -135,8 +135,15 @@ gen_btf()
 	${OBJCOPY} --only-section=.BTF --set-section-flags .BTF=alloc,readonly \
 		--strip-all ${1} ${2} 2>/dev/null
 	# Change e_type to ET_REL so that it can be used to link final vmlinux.
-	# Unlike GNU ld, lld does not allow an ET_EXEC input.
-	printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
+	# Unlike GNU ld, lld does not allow an ET_EXEC input. Make sure the correct
+	# byte gets changed with big endian platforms, otherwise e_type may be an
+	# invalid value.
+	if is_enabled CONFIG_CPU_BIG_ENDIAN; then
+		seek=17
+	else
+		seek=16
+	fi
+	printf '\1' | dd of=${2} conv=notrunc bs=1 seek=${seek} status=none
 }
 
 # Create ${2} .S file with all symbols from the ${1} object file

---
base-commit: 54be6c6c5ae8e0d93a6c4641cb7528eb0b6ba478
change-id: 20240208-fix-elf-type-btf-vmlinux-bin-o-big-endian-dbc55a1e1296

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 88%]

* Re: [PATCH 1/6] tools/rtla: Fix Makefile compiler options for clang
  @ 2024-02-06 15:48 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-06 15:48 UTC (permalink / raw)
  To: Daniel Bristot de Oliveira
  Cc: Steven Rostedt, Masami Hiramatsu, Nick Desaulniers,
	Bill Wendling, Justin Stitt, Donald Zickus, stable,
	linux-trace-kernel, linux-kernel, llvm

On Tue, Feb 06, 2024 at 12:05:29PM +0100, Daniel Bristot de Oliveira wrote:
> The following errors are showing up when compiling rtla with clang:
> 
>  $ make HOSTCC=clang CC=clang LLVM_IAS=1
>  [...]
> 
>   clang -O -g -DVERSION=\"6.8.0-rc1\" -flto=auto -ffat-lto-objects
> 	-fexceptions -fstack-protector-strong
> 	-fasynchronous-unwind-tables -fstack-clash-protection  -Wall
> 	-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> 	-Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
> 	$(pkg-config --cflags libtracefs)    -c -o src/utils.o src/utils.c
> 
>   clang: warning: optimization flag '-ffat-lto-objects' is not supported [-Wignored-optimization-argument]

For what it's worth, this flag is supported in clang 17.0.0 and newer:

https://github.com/llvm/llvm-project/commit/610fc5cbcc8b68879c562f6458608afe2473ab7f

But if it is not critical, just dropping the flag like you have done
here rather than conditionally supporting it is probably easier.

>   warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
>   1 warning generated.
> 
>   clang -o rtla -ggdb  src/osnoise.o src/osnoise_hist.o src/osnoise_top.o
>   src/rtla.o src/timerlat_aa.o src/timerlat.o src/timerlat_hist.o
>   src/timerlat_top.o src/timerlat_u.o src/trace.o src/utils.o $(pkg-config --libs libtracefs)
> 
>   src/osnoise.o: file not recognized: file format not recognized
>   clang: error: linker command failed with exit code 1 (use -v to see invocation)
>   make: *** [Makefile:110: rtla] Error 1
> 
> Solve these issues by:
>   - removing -ffat-lto-objects and -Wno-maybe-uninitialized if using clang
>   - informing the linker about -flto=auto
> 
> Cc: stable@vger.kernel.org
> Fixes: 1a7b22ab15eb ("tools/rtla: Build with EXTRA_{C,LD}FLAGS")
> Suggested-by: Donald Zickus <dzickus@redhat.com>
> Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
> ---
>  tools/tracing/rtla/Makefile | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/tracing/rtla/Makefile b/tools/tracing/rtla/Makefile
> index 2456a399eb9a..afd18c678ff5 100644
> --- a/tools/tracing/rtla/Makefile
> +++ b/tools/tracing/rtla/Makefile
> @@ -28,10 +28,15 @@ FOPTS	:=	-flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong \
>  		-fasynchronous-unwind-tables -fstack-clash-protection
>  WOPTS	:= 	-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
>  
> +ifeq ($(CC),clang)
> +  FOPTS := $(filter-out -ffat-lto-objects, $(FOPTS))
> +  WOPTS := $(filter-out -Wno-maybe-uninitialized, $(WOPTS))
> +endif
> +
>  TRACEFS_HEADERS	:= $$($(PKG_CONFIG) --cflags libtracefs)
>  
>  CFLAGS	:=	-O -g -DVERSION=\"$(VERSION)\" $(FOPTS) $(MOPTS) $(WOPTS) $(TRACEFS_HEADERS) $(EXTRA_CFLAGS)
> -LDFLAGS	:=	-ggdb $(EXTRA_LDFLAGS)
> +LDFLAGS	:=	-flto=auto -ggdb $(EXTRA_LDFLAGS)
>  LIBS	:=	$$($(PKG_CONFIG) --libs libtracefs)
>  
>  SRC	:=	$(wildcard src/*.c)
> -- 
> 2.43.0
> 

^ permalink raw reply	[relevance 99%]

* [PATCH] drm/amd/display: Increase frame-larger-than for all display_mode_vba files
@ 2024-02-05 21:54 87% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-05 21:54 UTC (permalink / raw)
  To: harry.wentland, sunpeng.li, Rodrigo.Siqueira, alexander.deucher
  Cc: christian.koenig, Xinhui.Pan, morbo, justinstitt, amd-gfx,
	dri-devel, llvm, patches, stable, Nathan Chancellor

After a recent change in LLVM, allmodconfig (which has CONFIG_KCSAN=y
and CONFIG_WERROR=y enabled) has a few new instances of
-Wframe-larger-than for the mode support and system configuration
functions:

  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20v2.c:3393:6: error: stack frame size (2144) exceeds limit (2048) in 'dml20v2_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
   3393 | void dml20v2_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
        |      ^
  1 error generated.

  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_mode_vba_21.c:3520:6: error: stack frame size (2192) exceeds limit (2048) in 'dml21_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
   3520 | void dml21_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
        |      ^
  1 error generated.

  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_mode_vba_20.c:3286:6: error: stack frame size (2128) exceeds limit (2048) in 'dml20_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
   3286 | void dml20_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
        |      ^
  1 error generated.

Without the sanitizers enabled, there are no warnings.

This was the catalyst for commit 6740ec97bcdb ("drm/amd/display:
Increase frame warning limit with KASAN or KCSAN in dml2") and that same
change was made to dml in commit 5b750b22530f ("drm/amd/display:
Increase frame warning limit with KASAN or KCSAN in dml") but the
frame_warn_flag variable was not applied to all files. Do so now to
clear up the warnings and make all these files consistent.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issue/1990
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/dml/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 6042a5a6a44f..59ade76ffb18 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -72,11 +72,11 @@ CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn10/dcn10_fpu.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/dcn20_fpu.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags) $(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags) $(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags) $(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) $(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)

---
base-commit: 6813cdca4ab94a238f8eb0cef3d3f3fcbdfb0ee0
change-id: 20240205-amdgpu-raise-flt-for-dml-vba-files-ee5b5a9c5e43

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 87%]

* [PATCH 6.1] platform/x86: intel-uncore-freq: Fix types in sysfs callbacks
  @ 2024-01-27 22:57 72% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-27 22:57 UTC (permalink / raw)
  To: gregkh; +Cc: hdegoede, nathan, samitolvanen, srinivas.pandruvada, stable

commit 416de0246f35f43d871a57939671fe814f4455ee upstream.

When booting a kernel with CONFIG_CFI_CLANG, there is a CFI failure when
accessing any of the values under
/sys/devices/system/cpu/intel_uncore_frequency/package_00_die_00:

  $ cat /sys/devices/system/cpu/intel_uncore_frequency/package_00_die_00/max_freq_khz
  fish: Job 1, 'cat /sys/devices/system/cpu/int…' terminated by signal SIGSEGV (Address boundary error)

  $ sudo dmesg &| grep 'CFI failure'
  [  170.953925] CFI failure at kobj_attr_show+0x19/0x30 (target: show_max_freq_khz+0x0/0xc0 [intel_uncore_frequency_common]; expected type: 0xd34078c5

The sysfs callback functions such as show_domain_id() are written as if
they are going to be called by dev_attr_show() but as the above message
shows, they are instead called by kobj_attr_show(). kCFI checks that the
destination of an indirect jump has the exact same type as the prototype
of the function pointer it is called through and fails when they do not.

These callbacks are called through kobj_attr_show() because
uncore_root_kobj was initialized with kobject_create_and_add(), which
means uncore_root_kobj has a ->sysfs_ops of kobj_sysfs_ops from
kobject_create(), which uses kobj_attr_show() as its ->show() value.

The only reason there has not been a more noticeable problem until this
point is that 'struct kobj_attribute' and 'struct device_attribute' have
the same layout, so getting the callback from container_of() works the
same with either value.

Change all the callbacks and their uses to be compatible with
kobj_attr_show() and kobj_attr_store(), which resolves the kCFI failure
and allows the sysfs files to work properly.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1974
Fixes: ae7b2ce57851 ("platform/x86/intel/uncore-freq: Use sysfs API to create attributes")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20240104-intel-uncore-freq-kcfi-fix-v1-1-bf1e8939af40@kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[nathan: Fix conflicts due to lack of 9b8dea80e3cb in 6.1]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 .../uncore-frequency-common.c                 | 64 +++++++++----------
 .../uncore-frequency-common.h                 | 20 +++---
 2 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
index 9b12fe8e95c9..dd2e654daf4b 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.c
@@ -74,30 +74,30 @@ static ssize_t show_perf_status_freq_khz(struct uncore_data *data, char *buf)
 }
 
 #define store_uncore_min_max(name, min_max)				\
-	static ssize_t store_##name(struct device *dev,		\
-				     struct device_attribute *attr,	\
+	static ssize_t store_##name(struct kobject *kobj,		\
+				     struct kobj_attribute *attr,	\
 				     const char *buf, size_t count)	\
 	{								\
-		struct uncore_data *data = container_of(attr, struct uncore_data, name##_dev_attr);\
+		struct uncore_data *data = container_of(attr, struct uncore_data, name##_kobj_attr);\
 									\
 		return store_min_max_freq_khz(data, buf, count,	\
 					      min_max);		\
 	}
 
 #define show_uncore_min_max(name, min_max)				\
-	static ssize_t show_##name(struct device *dev,		\
-				    struct device_attribute *attr, char *buf)\
+	static ssize_t show_##name(struct kobject *kobj,		\
+				    struct kobj_attribute *attr, char *buf)\
 	{                                                               \
-		struct uncore_data *data = container_of(attr, struct uncore_data, name##_dev_attr);\
+		struct uncore_data *data = container_of(attr, struct uncore_data, name##_kobj_attr);\
 									\
 		return show_min_max_freq_khz(data, buf, min_max);	\
 	}
 
 #define show_uncore_perf_status(name)					\
-	static ssize_t show_##name(struct device *dev,		\
-				   struct device_attribute *attr, char *buf)\
+	static ssize_t show_##name(struct kobject *kobj,		\
+				   struct kobj_attribute *attr, char *buf)\
 	{                                                               \
-		struct uncore_data *data = container_of(attr, struct uncore_data, name##_dev_attr);\
+		struct uncore_data *data = container_of(attr, struct uncore_data, name##_kobj_attr);\
 									\
 		return show_perf_status_freq_khz(data, buf); \
 	}
@@ -111,11 +111,11 @@ show_uncore_min_max(max_freq_khz, 1);
 show_uncore_perf_status(current_freq_khz);
 
 #define show_uncore_data(member_name)					\
-	static ssize_t show_##member_name(struct device *dev,	\
-					   struct device_attribute *attr, char *buf)\
+	static ssize_t show_##member_name(struct kobject *kobj,	\
+					   struct kobj_attribute *attr, char *buf)\
 	{                                                               \
 		struct uncore_data *data = container_of(attr, struct uncore_data,\
-							  member_name##_dev_attr);\
+							  member_name##_kobj_attr);\
 									\
 		return sysfs_emit(buf, "%u\n",				\
 				 data->member_name);			\
@@ -126,29 +126,29 @@ show_uncore_data(initial_max_freq_khz);
 
 #define init_attribute_rw(_name)					\
 	do {								\
-		sysfs_attr_init(&data->_name##_dev_attr.attr);	\
-		data->_name##_dev_attr.show = show_##_name;		\
-		data->_name##_dev_attr.store = store_##_name;		\
-		data->_name##_dev_attr.attr.name = #_name;		\
-		data->_name##_dev_attr.attr.mode = 0644;		\
+		sysfs_attr_init(&data->_name##_kobj_attr.attr);	\
+		data->_name##_kobj_attr.show = show_##_name;		\
+		data->_name##_kobj_attr.store = store_##_name;		\
+		data->_name##_kobj_attr.attr.name = #_name;		\
+		data->_name##_kobj_attr.attr.mode = 0644;		\
 	} while (0)
 
 #define init_attribute_ro(_name)					\
 	do {								\
-		sysfs_attr_init(&data->_name##_dev_attr.attr);	\
-		data->_name##_dev_attr.show = show_##_name;		\
-		data->_name##_dev_attr.store = NULL;			\
-		data->_name##_dev_attr.attr.name = #_name;		\
-		data->_name##_dev_attr.attr.mode = 0444;		\
+		sysfs_attr_init(&data->_name##_kobj_attr.attr);	\
+		data->_name##_kobj_attr.show = show_##_name;		\
+		data->_name##_kobj_attr.store = NULL;			\
+		data->_name##_kobj_attr.attr.name = #_name;		\
+		data->_name##_kobj_attr.attr.mode = 0444;		\
 	} while (0)
 
 #define init_attribute_root_ro(_name)					\
 	do {								\
-		sysfs_attr_init(&data->_name##_dev_attr.attr);	\
-		data->_name##_dev_attr.show = show_##_name;		\
-		data->_name##_dev_attr.store = NULL;			\
-		data->_name##_dev_attr.attr.name = #_name;		\
-		data->_name##_dev_attr.attr.mode = 0400;		\
+		sysfs_attr_init(&data->_name##_kobj_attr.attr);	\
+		data->_name##_kobj_attr.show = show_##_name;		\
+		data->_name##_kobj_attr.store = NULL;			\
+		data->_name##_kobj_attr.attr.name = #_name;		\
+		data->_name##_kobj_attr.attr.mode = 0400;		\
 	} while (0)
 
 static int create_attr_group(struct uncore_data *data, char *name)
@@ -161,14 +161,14 @@ static int create_attr_group(struct uncore_data *data, char *name)
 	init_attribute_ro(initial_max_freq_khz);
 	init_attribute_root_ro(current_freq_khz);
 
-	data->uncore_attrs[index++] = &data->max_freq_khz_dev_attr.attr;
-	data->uncore_attrs[index++] = &data->min_freq_khz_dev_attr.attr;
-	data->uncore_attrs[index++] = &data->initial_min_freq_khz_dev_attr.attr;
-	data->uncore_attrs[index++] = &data->initial_max_freq_khz_dev_attr.attr;
+	data->uncore_attrs[index++] = &data->max_freq_khz_kobj_attr.attr;
+	data->uncore_attrs[index++] = &data->min_freq_khz_kobj_attr.attr;
+	data->uncore_attrs[index++] = &data->initial_min_freq_khz_kobj_attr.attr;
+	data->uncore_attrs[index++] = &data->initial_max_freq_khz_kobj_attr.attr;
 
 	ret = uncore_read_freq(data, &freq);
 	if (!ret)
-		data->uncore_attrs[index++] = &data->current_freq_khz_dev_attr.attr;
+		data->uncore_attrs[index++] = &data->current_freq_khz_kobj_attr.attr;
 
 	data->uncore_attrs[index] = NULL;
 
diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
index f5dcfa2fb285..2d9dc3151d6e 100644
--- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
+++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-common.h
@@ -23,11 +23,11 @@
  * @die_id:		Die id for this instance
  * @name:		Sysfs entry name for this instance
  * @uncore_attr_group:	Attribute group storage
- * @max_freq_khz_dev_attr: Storage for device attribute max_freq_khz
- * @mix_freq_khz_dev_attr: Storage for device attribute min_freq_khz
- * @initial_max_freq_khz_dev_attr: Storage for device attribute initial_max_freq_khz
- * @initial_min_freq_khz_dev_attr: Storage for device attribute initial_min_freq_khz
- * @current_freq_khz_dev_attr: Storage for device attribute current_freq_khz
+ * @max_freq_khz_dev_attr: Storage for kobject attribute max_freq_khz
+ * @mix_freq_khz_dev_attr: Storage for kobject attribute min_freq_khz
+ * @initial_max_freq_khz_dev_attr: Storage for kobject attribute initial_max_freq_khz
+ * @initial_min_freq_khz_dev_attr: Storage for kobject attribute initial_min_freq_khz
+ * @current_freq_khz_dev_attr: Storage for kobject attribute current_freq_khz
  * @uncore_attrs:	Attribute storage for group creation
  *
  * This structure is used to encapsulate all data related to uncore sysfs
@@ -44,11 +44,11 @@ struct uncore_data {
 	char name[32];
 
 	struct attribute_group uncore_attr_group;
-	struct device_attribute max_freq_khz_dev_attr;
-	struct device_attribute min_freq_khz_dev_attr;
-	struct device_attribute initial_max_freq_khz_dev_attr;
-	struct device_attribute initial_min_freq_khz_dev_attr;
-	struct device_attribute current_freq_khz_dev_attr;
+	struct kobj_attribute max_freq_khz_kobj_attr;
+	struct kobj_attribute min_freq_khz_kobj_attr;
+	struct kobj_attribute initial_max_freq_khz_kobj_attr;
+	struct kobj_attribute initial_min_freq_khz_kobj_attr;
+	struct kobj_attribute current_freq_khz_kobj_attr;
 	struct attribute *uncore_attrs[6];
 };
 

base-commit: 883d1a9562083922c6d293e9adad8cca4626adf3
-- 
2.43.0


^ permalink raw reply related	[relevance 72%]

* [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
@ 2024-01-27 18:07 96% Nathan Chancellor
  2024-03-05 22:43 99% ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-27 18:07 UTC (permalink / raw)
  To: mpe
  Cc: npiggin, christophe.leroy, aneesh.kumar, naveen.n.rao, morbo,
	justinstitt, linuxppc-dev, patches, llvm, stable,
	Nathan Chancellor

arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
error when building with clang after a recent change in main:

  error: option '-msoft-float' cannot be specified with '-maltivec'
  make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1

Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
to override the previous inclusion of '-msoft-float' (as the last option
wins), which matches how other areas of the kernel use '-maltivec', such
as AMDGPU.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/lib/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 6eac63e79a89..0ab65eeb93ee 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -76,7 +76,7 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
 obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
 
 obj-$(CONFIG_ALTIVEC)	+= xor_vmx.o xor_vmx_glue.o
-CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
+CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec)
 # Enable <altivec.h>
 CFLAGS_xor_vmx.o += -isystem $(shell $(CC) -print-file-name=include)
 

---
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
change-id: 20240127-ppc-xor_vmx-drop-msoft-float-ad68b437f86c

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 96%]

* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
  @ 2024-01-27  0:03 99%               ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-27  0:03 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
	llvm, keescook, arei.gonglei, mst, jasowang, virtualization,
	linux-crypto

On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
> Anyway, how did you find that ? Is there a magic trick to find the
> actual code causing the warning ? I am asking because we had seen
> similar warnings before, and it would help to know how to find the
> problematic code.

The easiest way I have found is figuring out what primitive is causing
the warning (memset, memcpy) then just commenting out the uses in the
particular file until the warning goes away. Sometimes it is quick like
in this case since there were only two instances of memcpy() in that
file but other cases it can definitely take time. There could be
potential issues with that approach if the problematic use is in a
header, at which point you could generate a preprocessed ('.i') file and
see where fortify_memcpy_chk() or fortify_memset_chk() come from in that
file.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
  @ 2024-01-26 22:35 92%           ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-26 22:35 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
	llvm, keescook, arei.gonglei, mst, jasowang, virtualization,
	linux-crypto

(slimming up the CC list, I don't think this is too relevant to the
wider stable community)

On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
> On 1/26/24 12:34, Nathan Chancellor wrote:
> > On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> > > On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > > > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > > > There are 286 patches in this series, all will be posted as a response
> > > > > > to this one.  If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > > 
> > > > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > > 
> > > > > [ ... ]
> > > > > 
> > > > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > > >        virtio-crypto: implement RSA algorithm
> > > > > > 
> > > > > 
> > > > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > > > have functionality in v5.10.y which is not in v5.15.y.
> > > > 
> > > > See the commit text, it was a dependency of a later fix and documented
> > > > as such.
> > > > 
> > > > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > > > gladly accepted :)
> > > > 
> > > 
> > > We reverted the entire series from the merge because it results in a build
> > > failure for us.
> > > 
> > > In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> > > /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> > >                          __read_overflow2_field(q_size_field, size);
> > 
> > For what it's worth, this is likely self inflicted for chromeos-5.10,
> > which carries a revert of commit eaafc590053b ("fortify: Explicitly
> > disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> > "fortify: Explicitly disable Clang support""). I don't see the series
> > that added proper support for clang to fortify in 5.18 that ended with
> > commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> > branch, so this seems somewhat expected.
> > 
> 
> That explains that ;-). I don't mind if the patches stay in v5.10.y,
> we have them reverted anyway.
> 
> The revert was a pure process issue, as you may see when looking into
> commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
> Still, that doesn't explain why the problem exists in 5.18+.
> 
> > > I also see that upstream (starting with 6.1) when trying to build it with clang,
> > > so I guess it is one of those bug-for-bug compatibility things. I really have
> > > no idea what causes it, or why we don't see the problem when building
> > > chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> > > merging 5.10.209 into it. Making things worse, the problem isn't _always_
> > > seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> > > I have no idea what triggers the problem.
> > 
> > Have a .config that reproduces it on upstream? I have not personally
> > seen this warning in my build matrix nor has our continuous-integration
> > matrix (I don't see it in the warning output at the bottom but that
> > could have missed something for some reason) in 6.1:
> > 
> 
> The following command sequence reproduces the problem for me with all stable
> branches starting with 5.18.y (plus mainline).
> 
> rm -rf /tmp/crypto-build
> mkdir /tmp/crypto-build
> make -j CC=clang-15 mrproper >/dev/null 2>&1
> make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
> make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
> 
> I tried clang versions 14, 15, and 16. This is with my home system running
> Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
> the version is
> 
> Ubuntu clang version 15.0.7
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin

Okay interesting, this warning is hidden behind W=1, which our CI does
not test with. Looks like it has been that way since the introduction of
these checks in f68f2ff91512 ("fortify: Detect struct member overflows
in memcpy() at compile-time").

I think this is a legitimate warning though. It is complaining about the
second memcpy() in virtio_crypto_alg_akcipher_init_session():

  memcpy(&ctrl->u, para, sizeof(ctrl->u));

where ctrl is:

  struct virtio_crypto_op_ctrl_req {
          struct virtio_crypto_ctrl_header header;         /*     0    16 */
          union {
                  struct virtio_crypto_sym_create_session_req sym_create_session; /*    16    56 */
                  struct virtio_crypto_hash_create_session_req hash_create_session; /*    16    56 */
                  struct virtio_crypto_mac_create_session_req mac_create_session; /*    16    56 */
                  struct virtio_crypto_aead_create_session_req aead_create_session; /*    16    56 */
                  struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /*    16    56 */
                  struct virtio_crypto_destroy_session_req destroy_session; /*    16    56 */
                  __u8               padding[56];          /*    16    56 */
          } u;                                             /*    16    56 */
          union {
                  struct virtio_crypto_sym_create_session_req sym_create_session; /*     0    56 */
                  struct virtio_crypto_hash_create_session_req hash_create_session; /*     0    56 */
                  struct virtio_crypto_mac_create_session_req mac_create_session; /*     0    56 */
                  struct virtio_crypto_aead_create_session_req aead_create_session; /*     0    56 */
                  struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /*     0    56 */
                  struct virtio_crypto_destroy_session_req destroy_session; /*     0    56 */
                  __u8                       padding[56];          /*     0    56 */
          };


          /* size: 72, cachelines: 2, members: 2 */
          /* last cacheline: 8 bytes */
  };

(so size and p_size_field should be 56) and the type of the para
parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
the para passed by reference to
virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
has a type of 'struct virtio_crypto_akcipher_session_para':

  struct virtio_crypto_akcipher_session_para {
          __le32                     algo;                 /*     0     4 */
          __le32                     keytype;              /*     4     4 */
          __le32                     keylen;               /*     8     4 */
          union {
                  struct virtio_crypto_rsa_session_para rsa; /*    12     8 */
                  struct virtio_crypto_ecdsa_session_para ecdsa; /*    12     8 */
          } u;                                             /*    12     8 */
          union {
                  struct virtio_crypto_rsa_session_para rsa;       /*     0     8 */
                  struct virtio_crypto_ecdsa_session_para ecdsa;   /*     0     8 */
          };


          /* size: 20, cachelines: 1, members: 4 */
          /* last cacheline: 20 bytes */
  };

(so q_size_field would be 20 if clang were able to do inlining to see
through the 'void *'...?), which would result in the

  __compiletime_lessthan(q_size_field, size)

check succeeding and triggering the warning because 20 < 56, so it does
seem like there is an overread of the source buffer here? Adding the
maintainers of the driver and subsystem in question.

Cheers,
Nathan

^ permalink raw reply	[relevance 92%]

* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
  @ 2024-01-26 20:34 96%       ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-26 20:34 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
	akpm, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
	sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, llvm,
	keescook

On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > There are 286 patches in this series, all will be posted as a response
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > > 
> > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > Anything received after that time might be too late.
> > > > 
> > > [ ... ]
> > > 
> > > > zhenwei pi <pizhenwei@bytedance.com>
> > > >       virtio-crypto: implement RSA algorithm
> > > > 
> > > 
> > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > have functionality in v5.10.y which is not in v5.15.y.
> > 
> > See the commit text, it was a dependency of a later fix and documented
> > as such.
> > 
> > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > gladly accepted :)
> > 
> 
> We reverted the entire series from the merge because it results in a build
> failure for us.
> 
> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
>                         __read_overflow2_field(q_size_field, size);

For what it's worth, this is likely self inflicted for chromeos-5.10,
which carries a revert of commit eaafc590053b ("fortify: Explicitly
disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
"fortify: Explicitly disable Clang support""). I don't see the series
that added proper support for clang to fortify in 5.18 that ended with
commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
branch, so this seems somewhat expected.

> I also see that upstream (starting with 6.1) when trying to build it with clang,
> so I guess it is one of those bug-for-bug compatibility things. I really have
> no idea what causes it, or why we don't see the problem when building
> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> merging 5.10.209 into it. Making things worse, the problem isn't _always_
> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> I have no idea what triggers the problem.

Have a .config that reproduces it on upstream? I have not personally
seen this warning in my build matrix nor has our continuous-integration
matrix (I don't see it in the warning output at the bottom but that
could have missed something for some reason) in 6.1:

https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/7662499796
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/7662534888

Reverting this series from 5.10 seems reasonable given your other
comments but if there is still something to sort out upstream, I
definitely want to.

> Of course, on top of all that, the error message is completely useless.

Indeed, outstanding papercut unfortunately:
https://github.com/ClangBuiltLinux/linux/issues/1571

Cheers,
Nathan

^ permalink raw reply	[relevance 96%]

* [PATCH 5.4] powerpc: Use always instead of always-y in for crtsavres.o
@ 2024-01-26 17:37 94% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-26 17:37 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: stable, linuxppc-dev, linux-kbuild, llvm, Nathan Chancellor

This commit is for linux-5.4.y only, it has no direct upstream
equivalent.

Prior to commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to
hostprogs/always-y"), always-y did not exist, making the backport of
mainline commit 1b1e38002648 ("powerpc: add crtsavres.o to always-y
instead of extra-y") to linux-5.4.y as commit 245da9eebba0 ("powerpc:
add crtsavres.o to always-y instead of extra-y") incorrect, breaking the
build with linkers that need crtsavres.o:

  ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory

Backporting the aforementioned kbuild commit is not suitable for stable
due to its size and number of conflicts, so transform the always-y usage
to an equivalent form using always, which resolves the build issues.

Fixes: 245da9eebba0 ("powerpc: add crtsavres.o to always-y instead of extra-y")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 7c603839fe28..841e6ed30f13 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -34,8 +34,8 @@ obj-$(CONFIG_FUNCTION_ERROR_INJECTION)	+= error-inject.o
 # 64-bit linker creates .sfpr on demand for final link (vmlinux),
 # so it is only needed for modules, and only for older linkers which
 # do not support --save-restore-funcs
-ifeq ($(call ld-ifversion, -lt, 225000000, y),y)
-always-$(CONFIG_PPC64)	+= crtsavres.o
+ifeq ($(call ld-ifversion, -lt, 225000000, y)$(CONFIG_PPC64),yy)
+always	+= crtsavres.o
 endif
 
 obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \

---
base-commit: f0602893f43a54097fcf22bd8c2f7b8e75ca643e
change-id: 20240126-5-4-fix-lib-powerpc-backport-9d577643dcfc

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 94%]

* [PATCH 4.19] powerpc: Use always instead of always-y in for crtsavres.o
@ 2024-01-26 17:36 94% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-26 17:36 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: stable, linuxppc-dev, linux-kbuild, llvm, Nathan Chancellor

This commit is for linux-4.19.y only, it has no direct upstream
equivalent.

Prior to commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to
hostprogs/always-y"), always-y did not exist, making the backport of
mainline commit 1b1e38002648 ("powerpc: add crtsavres.o to always-y
instead of extra-y") to linux-4.19.y as commit b7b85ec5ec15 ("powerpc:
add crtsavres.o to always-y instead of extra-y") incorrect, breaking the
build with linkers that need crtsavres.o:

  ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory

Backporting the aforementioned kbuild commit is not suitable for stable
due to its size and number of conflicts, so transform the always-y usage
to an equivalent form using always, which resolves the build issues.

Fixes: b7b85ec5ec15 ("powerpc: add crtsavres.o to always-y instead of extra-y")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/lib/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 6f1e57182876..f0aa6fc8c6b2 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -21,8 +21,8 @@ obj-$(CONFIG_PPC32)	+= div64.o copy_32.o crtsavres.o strlen_32.o
 # 64-bit linker creates .sfpr on demand for final link (vmlinux),
 # so it is only needed for modules, and only for older linkers which
 # do not support --save-restore-funcs
-ifeq ($(call ld-ifversion, -lt, 225000000, y),y)
-always-$(CONFIG_PPC64)	+= crtsavres.o
+ifeq ($(call ld-ifversion, -lt, 225000000, y)$(CONFIG_PPC64),yy)
+always	+= crtsavres.o
 endif
 
 obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \

---
base-commit: b060cfd3f707ad3c8ae8322e1b149ba7e2cf33e0
change-id: 20240126-4-19-fix-lib-powerpc-backport-6f4a823adf1a

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 94%]

* [PATCH 1/2] kbuild: Add -Wa,--fatal-warnings to as-instr invocation
  2024-01-25 17:32 95% [PATCH 0/2] RISC-V: Fix CONFIG_AS_HAS_OPTION_ARCH with tip of tree LLVM Nathan Chancellor
@ 2024-01-25 17:32 91% ` Nathan Chancellor
  2024-01-25 17:32 90% ` [PATCH 2/2] RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 17:32 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, masahiroy
  Cc: nicolas, andy.chiu, conor.dooley, linux-riscv, linux-kbuild,
	llvm, patches, stable, Eric Biggers, Nathan Chancellor

Certain assembler instruction tests may only induce warnings from the
assembler on an unsupported instruction or option, which causes as-instr
to succeed when it was expected to fail. Some tests workaround this
limitation by additionally testing that invalid input fails as expected.
However, this is fragile if the assembler is changed to accept the
invalid input, as it will cause the instruction/option to be unavailable
like it was unsupported even when it is.

Use '-Wa,--fatal-warnings' in the as-instr macro to turn these warnings
into hard errors, which avoids this fragility and makes tests more
robust and well formed.

Cc: stable@vger.kernel.org
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/Kconfig.include   | 2 +-
 scripts/Makefile.compiler | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 5a84b6443875..3ee8ecfb8c04 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -33,7 +33,7 @@ ld-option = $(success,$(LD) -v $(1))
 
 # $(as-instr,<instr>)
 # Return y if the assembler supports <instr>, n otherwise
-as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler-with-cpp -o /dev/null -)
+as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o /dev/null -)
 
 # check if $(CC) and $(LD) exist
 $(error-if,$(failure,command -v $(CC)),C compiler '$(CC)' not found)
diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
index 8fcb427405a6..92be0c9a13ee 100644
--- a/scripts/Makefile.compiler
+++ b/scripts/Makefile.compiler
@@ -38,7 +38,7 @@ as-option = $(call try-run,\
 # Usage: aflags-y += $(call as-instr,instr,option1,option2)
 
 as-instr = $(call try-run,\
-	printf "%b\n" "$(1)" | $(CC) -Werror $(CLANG_FLAGS) $(KBUILD_AFLAGS) -c -x assembler-with-cpp -o "$$TMP" -,$(2),$(3))
+	printf "%b\n" "$(1)" | $(CC) -Werror $(CLANG_FLAGS) $(KBUILD_AFLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" -,$(2),$(3))
 
 # __cc-option
 # Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586)

-- 
2.43.0


^ permalink raw reply related	[relevance 91%]

* [PATCH 2/2] RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH
  2024-01-25 17:32 95% [PATCH 0/2] RISC-V: Fix CONFIG_AS_HAS_OPTION_ARCH with tip of tree LLVM Nathan Chancellor
  2024-01-25 17:32 91% ` [PATCH 1/2] kbuild: Add -Wa,--fatal-warnings to as-instr invocation Nathan Chancellor
@ 2024-01-25 17:32 90% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 17:32 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, masahiroy
  Cc: nicolas, andy.chiu, conor.dooley, linux-riscv, linux-kbuild,
	llvm, patches, stable, Eric Biggers, Nathan Chancellor

Commit e4bb020f3dbb ("riscv: detect assembler support for .option arch")
added two tests, one for a valid value to '.option arch' that should
succeed and one for an invalid value that is expected to fail to make
sure that support for '.option arch' is properly detected because Clang
does not error when '.option arch' is not supported:

  $ clang --target=riscv64-linux-gnu -Werror -x assembler -c -o /dev/null <(echo '.option arch, +m')
  /dev/fd/63:1:9: warning: unknown option, expected 'push', 'pop', 'rvc', 'norvc', 'relax' or 'norelax'
  .option arch, +m
          ^
  $ echo $?
  0

Unfortunately, the invalid test started being accepted by Clang after
the linked llvm-project change, which causes CONFIG_AS_HAS_OPTION_ARCH
and configurations that depend on it to be silently disabled, even
though those versions do support '.option arch'.

The invalid test can be avoided altogether by using
'-Wa,--fatal-warnings', which will turn all assembler warnings into
errors, like '-Werror' does for the compiler:

  $ clang --target=riscv64-linux-gnu -Werror -Wa,--fatal-warnings -x assembler -c -o /dev/null <(echo '.option arch, +m')
  /dev/fd/63:1:9: error: unknown option, expected 'push', 'pop', 'rvc', 'norvc', 'relax' or 'norelax'
  .option arch, +m
          ^
  $ echo $?
  1

The as-instr macros have been updated to make use of this flag, so
remove the invalid test, which allows CONFIG_AS_HAS_OPTION_ARCH to work
for all compiler versions.

Cc: stable@vger.kernel.org
Fixes: e4bb020f3dbb ("riscv: detect assembler support for .option arch")
Link: https://github.com/llvm/llvm-project/commit/3ac9fe69f70a2b3541266daedbaaa7dc9c007a2a
Reported-by: Eric Biggers <ebiggers@kernel.org>
Closes: https://lore.kernel.org/r/20240121011341.GA97368@sol.localdomain/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/riscv/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index bffbd869a068..e3142ce531a0 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -315,7 +315,6 @@ config AS_HAS_OPTION_ARCH
 	# https://reviews.llvm.org/D123515
 	def_bool y
 	depends on $(as-instr, .option arch$(comma) +m)
-	depends on !$(as-instr, .option arch$(comma) -i)
 
 source "arch/riscv/Kconfig.socs"
 source "arch/riscv/Kconfig.errata"

-- 
2.43.0


^ permalink raw reply related	[relevance 90%]

* [PATCH 0/2] RISC-V: Fix CONFIG_AS_HAS_OPTION_ARCH with tip of tree LLVM
@ 2024-01-25 17:32 95% Nathan Chancellor
  2024-01-25 17:32 91% ` [PATCH 1/2] kbuild: Add -Wa,--fatal-warnings to as-instr invocation Nathan Chancellor
  2024-01-25 17:32 90% ` [PATCH 2/2] RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH Nathan Chancellor
  0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 17:32 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, masahiroy
  Cc: nicolas, andy.chiu, conor.dooley, linux-riscv, linux-kbuild,
	llvm, patches, stable, Eric Biggers, Nathan Chancellor

Hi all,

Eric reported that builds of LLVM with [1] (close to tip of tree) have
CONFIG_AS_HAS_OPTION_ARCH=n because the test for expected failure on
invalid input has started succeeding.

This Kconfig test was added because '.option arch' only causes an
assembler warning when it is unsupported, rather than a hard error,
which is what users of as-instr expect when something is unsupported.

This can be resolved by turning assembler warnings into errors with
'-Wa,--fatal-warnings' like we do with the compiler with '-Werror',
which is what the first patch does. The second patch removes the invalid
test, as the valid test is good enough with fatal warnings.

I have diffed several configurations for the different architectures
that use as-instr and I have found no issues.

I think this could go in through either the kbuild or RISC-V tree with
sufficient acks but I will let them fight over who takes it :)

[1]: https://github.com/llvm/llvm-project/commit/3ac9fe69f70a2b3541266daedbaaa7dc9c007a2a

---
Nathan Chancellor (2):
      kbuild: Add -Wa,--fatal-warnings to as-instr invocation
      RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH

 arch/riscv/Kconfig        | 1 -
 scripts/Kconfig.include   | 2 +-
 scripts/Makefile.compiler | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)
---
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
change-id: 20240124-fix-riscv-option-arch-llvm-18-3cbe7b09a216

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply	[relevance 95%]

* [PATCH 2/2] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
  2024-01-23 22:59 97% [PATCH 0/2] Fix UML build with clang-18 and newer Nathan Chancellor
  2024-01-23 22:59 89% ` [PATCH 1/2] um: Fix adding '-no-pie' for clang Nathan Chancellor
@ 2024-01-23 22:59 94% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-23 22:59 UTC (permalink / raw)
  To: richard, anton.ivanov, johannes, masahiroy
  Cc: nathan, nicolas, ndesaulniers, morbo, justinstitt, linux-um,
	linux-kbuild, llvm, patches, stable

After the linked LLVM change, building ARCH=um defconfig results in a
segmentation fault in modpost. Prior to commit a23e7584ecf3 ("modpost:
unify 'sym' and 'to' in default_mismatch_handler()"), there was a
warning:

  WARNING: modpost: vmlinux.o(__ex_table+0x88): Section mismatch in reference to the .ltext:(unknown)
  WARNING: modpost: The relocation at __ex_table+0x88 references
  section ".ltext" which is not in the list of
  authorized sections.  If you're adding a new section
  and/or if this reference is valid, add ".ltext" to the
  list of authorized sections to jump to on fault.
  This can be achieved by adding ".ltext" to
  OTHER_TEXT_SECTIONS in scripts/mod/modpost.c.

The linked LLVM change moves global objects to the '.ltext' (and
'.ltext.*' with '-ffunction-sections') sections with '-mcmodel=large',
which ARCH=um uses. These sections should be handled just as '.text'
and '.text.*' are, so add them to TEXT_SECTIONS.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1981
Link: https://github.com/llvm/llvm-project/commit/4bf8a688956a759b7b6b8d94f42d25c13c7af130
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/mod/modpost.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index cb6406f485a9..f7c4d3fe4381 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -807,7 +807,8 @@ static void check_section(const char *modname, struct elf_info *elf,
 
 #define DATA_SECTIONS ".data", ".data.rel"
 #define TEXT_SECTIONS ".text", ".text.*", ".sched.text", \
-		".kprobes.text", ".cpuidle.text", ".noinstr.text"
+		".kprobes.text", ".cpuidle.text", ".noinstr.text", \
+		".ltext", ".ltext.*"
 #define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
 		".fixup", ".entry.text", ".exception.text", \
 		".coldtext", ".softirqentry.text"

-- 
2.43.0


^ permalink raw reply related	[relevance 94%]

* [PATCH 1/2] um: Fix adding '-no-pie' for clang
  2024-01-23 22:59 97% [PATCH 0/2] Fix UML build with clang-18 and newer Nathan Chancellor
@ 2024-01-23 22:59 89% ` Nathan Chancellor
  2024-01-23 22:59 94% ` [PATCH 2/2] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-23 22:59 UTC (permalink / raw)
  To: richard, anton.ivanov, johannes, masahiroy
  Cc: nathan, nicolas, ndesaulniers, morbo, justinstitt, linux-um,
	linux-kbuild, llvm, patches, stable

The kernel builds with -fno-PIE, so commit 883354afbc10 ("um: link
vmlinux with -no-pie") added the compiler linker flag '-no-pie' via
cc-option because '-no-pie' was only supported in GCC 6.1.0 and newer.

While this works for GCC, this does not work for clang because cc-option
uses '-c', which stops the pipeline right before linking, so '-no-pie'
is unconsumed and clang warns, causing cc-option to fail just as it
would if the option was entirely unsupported:

  $ clang -Werror -no-pie -c -o /dev/null-x c /dev/null
  clang-16: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]

A recent version of clang exposes this because it generates a relocation
under '-mcmodel=large' that is not supported in PIE mode:

  /usr/sbin/ld: init/main.o: relocation R_X86_64_32 against symbol `saved_command_line' can not be used when making a PIE object; recompile with -fPIE
  /usr/sbin/ld: failed to set dynamic section sizes: bad value
  clang: error: linker command failed with exit code 1 (use -v to see invocation)

Remove the cc-option check altogether. It is wasteful to invoke the
compiler to check for '-no-pie' because only one supported compiler
version does not support it, GCC 5.x (as it is supported with the
minimum version of clang and GCC 6.1.0+). Use a combination of the
gcc-min-version macro and CONFIG_CC_IS_CLANG to unconditionally add
'-no-pie' with CONFIG_LD_SCRIPT_DYN=y, so that it is enabled with all
compilers that support this. Furthermore, using gcc-min-version can help
turn this back into

  LINK-$(CONFIG_LD_SCRIPT_DYN) += -no-pie

when the minimum version of GCC is bumped past 6.1.0.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1982
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/um/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/um/Makefile b/arch/um/Makefile
index 82f05f250634..34957dcb88b9 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -115,7 +115,9 @@ archprepare:
 	$(Q)$(MAKE) $(build)=$(HOST_DIR)/um include/generated/user_constants.h
 
 LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static
-LINK-$(CONFIG_LD_SCRIPT_DYN) += $(call cc-option, -no-pie)
+ifdef CONFIG_LD_SCRIPT_DYN
+LINK-$(call gcc-min-version, 60100)$(CONFIG_CC_IS_CLANG) += -no-pie
+endif
 LINK-$(CONFIG_LD_SCRIPT_DYN_RPATH) += -Wl,-rpath,/lib
 
 CFLAGS_NO_HARDENING := $(call cc-option, -fno-PIC,) $(call cc-option, -fno-pic,) \

-- 
2.43.0


^ permalink raw reply related	[relevance 89%]

* [PATCH 0/2] Fix UML build with clang-18 and newer
@ 2024-01-23 22:59 97% Nathan Chancellor
  2024-01-23 22:59 89% ` [PATCH 1/2] um: Fix adding '-no-pie' for clang Nathan Chancellor
  2024-01-23 22:59 94% ` [PATCH 2/2] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS Nathan Chancellor
  0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2024-01-23 22:59 UTC (permalink / raw)
  To: richard, anton.ivanov, johannes, masahiroy
  Cc: nathan, nicolas, ndesaulniers, morbo, justinstitt, linux-um,
	linux-kbuild, llvm, patches, stable

Hi all,

This series resolves two independent but related issues that were
recently exposed by two LLVM changes.

https://github.com/llvm/llvm-project/commit/ec92d74a0ef89b9dd46aee6ec8aca6bfd3c66a54
exposes that '-no-pie' is not getting added to the linker flags with
clang, resulting in building objects with '-fno-PIE' that are linked
with '-pie', to which the linker rightfully errors with:

  /usr/sbin/ld: init/main.o: relocation R_X86_64_32 against symbol `saved_command_line' can not be used when making a PIE object; recompile with -fPIE
  /usr/sbin/ld: failed to set dynamic section sizes: bad value

https://github.com/llvm/llvm-project/commit/4bf8a688956a759b7b6b8d94f42d25c13c7af130
adds '.ltext' (and '.ltext.*' with '-ffunction-sections') when using
'-mcmodel=large' (which UML does), which causes a segmentation fault
with modpost.

I have tested these patches with all supported versions of clang,
noticing no regressions.

---
Nathan Chancellor (2):
      um: Fix adding '-no-pie' for clang
      modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS

 arch/um/Makefile      | 4 +++-
 scripts/mod/modpost.c | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)
---
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
change-id: 20240118-fix-uml-clang-18-e365b0503a29

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply	[relevance 97%]

* [PATCH] media: mxl5xx: Move xpt structures off stack
@ 2024-01-12  0:40 85% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-12  0:40 UTC (permalink / raw)
  To: mchehab
  Cc: ndesaulniers, morbo, justinstitt, linux-media, llvm, patches,
	stable, Nathan Chancellor

When building for LoongArch with clang 18.0.0, the stack usage of
probe() is larger than the allowed 2048 bytes:

  drivers/media/dvb-frontends/mxl5xx.c:1698:12: warning: stack frame size (2368) exceeds limit (2048) in 'probe' [-Wframe-larger-than]
   1698 | static int probe(struct mxl *state, struct mxl5xx_cfg *cfg)
        |            ^
  1 warning generated.

This is the result of the linked LLVM commit, which changes how the
arrays of structures in config_ts() get handled with
CONFIG_INIT_STACK_ZERO and CONFIG_INIT_STACK_PATTERN, which causes the
above warning in combination with inlining, as config_ts() gets inlined
into probe().

This warning can be easily fixed by moving the array of structures off
of the stackvia 'static const', which is a better location for these
variables anyways because they are static data that is only ever read
from, never modified, so allocating the stack space is wasteful.

This drops the stack usage from 2368 bytes to 256 bytes with the same
compiler and configuration.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1977
Link: https://github.com/llvm/llvm-project/commit/afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/media/dvb-frontends/mxl5xx.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/mxl5xx.c b/drivers/media/dvb-frontends/mxl5xx.c
index 4ebbcf05cc09..91e9c378397c 100644
--- a/drivers/media/dvb-frontends/mxl5xx.c
+++ b/drivers/media/dvb-frontends/mxl5xx.c
@@ -1381,57 +1381,57 @@ static int config_ts(struct mxl *state, enum MXL_HYDRA_DEMOD_ID_E demod_id,
 	u32 nco_count_min = 0;
 	u32 clk_type = 0;
 
-	struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_sync_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 8, 1}, {0x90700010, 9, 1},
 		{0x90700010, 10, 1}, {0x90700010, 11, 1},
 		{0x90700010, 12, 1}, {0x90700010, 13, 1},
 		{0x90700010, 14, 1}, {0x90700010, 15, 1} };
-	struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_clock_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 16, 1}, {0x90700010, 17, 1},
 		{0x90700010, 18, 1}, {0x90700010, 19, 1},
 		{0x90700010, 20, 1}, {0x90700010, 21, 1},
 		{0x90700010, 22, 1}, {0x90700010, 23, 1} };
-	struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_valid_polarity[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700014, 0, 1}, {0x90700014, 1, 1},
 		{0x90700014, 2, 1}, {0x90700014, 3, 1},
 		{0x90700014, 4, 1}, {0x90700014, 5, 1},
 		{0x90700014, 6, 1}, {0x90700014, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_ts_clock_phase[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700018, 0, 3}, {0x90700018, 4, 3},
 		{0x90700018, 8, 3}, {0x90700018, 12, 3},
 		{0x90700018, 16, 3}, {0x90700018, 20, 3},
 		{0x90700018, 24, 3}, {0x90700018, 28, 3} };
-	struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_lsb_first[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 16, 1}, {0x9070000C, 17, 1},
 		{0x9070000C, 18, 1}, {0x9070000C, 19, 1},
 		{0x9070000C, 20, 1}, {0x9070000C, 21, 1},
 		{0x9070000C, 22, 1}, {0x9070000C, 23, 1} };
-	struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_sync_byte[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700010, 0, 1}, {0x90700010, 1, 1},
 		{0x90700010, 2, 1}, {0x90700010, 3, 1},
 		{0x90700010, 4, 1}, {0x90700010, 5, 1},
 		{0x90700010, 6, 1}, {0x90700010, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_enable_output[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 0, 1}, {0x9070000C, 1, 1},
 		{0x9070000C, 2, 1}, {0x9070000C, 3, 1},
 		{0x9070000C, 4, 1}, {0x9070000C, 5, 1},
 		{0x9070000C, 6, 1}, {0x9070000C, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_err_replace_sync[MXL_HYDRA_DEMOD_MAX] = {
 		{0x9070000C, 24, 1}, {0x9070000C, 25, 1},
 		{0x9070000C, 26, 1}, {0x9070000C, 27, 1},
 		{0x9070000C, 28, 1}, {0x9070000C, 29, 1},
 		{0x9070000C, 30, 1}, {0x9070000C, 31, 1} };
-	struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_err_replace_valid[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700014, 8, 1}, {0x90700014, 9, 1},
 		{0x90700014, 10, 1}, {0x90700014, 11, 1},
 		{0x90700014, 12, 1}, {0x90700014, 13, 1},
 		{0x90700014, 14, 1}, {0x90700014, 15, 1} };
-	struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_continuous_clock[MXL_HYDRA_DEMOD_MAX] = {
 		{0x907001D4, 0, 1}, {0x907001D4, 1, 1},
 		{0x907001D4, 2, 1}, {0x907001D4, 3, 1},
 		{0x907001D4, 4, 1}, {0x907001D4, 5, 1},
 		{0x907001D4, 6, 1}, {0x907001D4, 7, 1} };
-	struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
+	static const struct MXL_REG_FIELD_T xpt_nco_clock_rate[MXL_HYDRA_DEMOD_MAX] = {
 		{0x90700044, 16, 80}, {0x90700044, 16, 81},
 		{0x90700044, 16, 82}, {0x90700044, 16, 83},
 		{0x90700044, 16, 84}, {0x90700044, 16, 85},

---
base-commit: 02d4e62ae2452c83e4a3e279b8e4cb4dcbad4b31
change-id: 20240111-dvb-mxl5xx-move-structs-off-stack-e12172b1ef02

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 85%]

* Re: riscv: clang-nightly-allmodconfig: failed on stable-rc 6.6 and 6.1
  @ 2024-01-09 15:26 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-09 15:26 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: linux-stable, clang-built-linux, lkft-triage, Nick Desaulniers,
	Arnd Bergmann, Anders Roxell, Greg Kroah-Hartman, Sasha Levin

Hi Naresh,

On Tue, Jan 09, 2024 at 03:06:04PM +0530, Naresh Kamboju wrote:
> The clang nightly build failures are noticed on stable-rc 6.6 and 6.1 for
> riscv allmodconfig builds.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Logs:
> =====
>  arch/riscv/kernel -I ./arch/riscv/kernel -dwarf-version=4 -mrelocation-model
>   static -target-abi lp64 -mllvm -riscv-add-build-attributes
>    -o arch/riscv/kernel/kexec_relocate.o /tmp/kexec_relocate-28089a.s
> 
>  #0 0x00007f5039e1667a llvm::sys::PrintStackTrace(llvm::raw_ostream&,
> int) (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6d67a)
>  #1 0x00007f5039e146a4 llvm::sys::RunSignalHandlers()
> (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6b6a4)
>  #2 0x00007f5039e16d3b (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6dd3b)
>  #3 0x00007f5038ba8510 (/lib/x86_64-linux-gnu/libc.so.6+0x3c510)
>  #4 0x00007f503c8f50c8 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x384c0c8)
>  #5 0x00007f503b492cf5 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9cf5)
>  #6 0x00007f503b492607 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9607)
>  #7 0x00007f503b492300
> llvm::MCExpr::evaluateAsRelocatableImpl(llvm::MCValue&,
> llvm::MCAssembler const*, llvm::MCAsmLayout const*, llvm::MCFixup
> const*, llvm::DenseMap<llvm::MCSection const*, unsigned long,
> llvm::DenseMapInfo<llvm::MCSection const*, void>,
> llvm::detail::DenseMapPair<llvm::MCSection const*, unsigned long>>
> const*, bool) const (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9300)

Thank you for the report, this is an LLVM regression that I reported a
few days ago and it has now been resolved upstream a few hours ago:

https://github.com/llvm/llvm-project/pull/76552#issuecomment-1878952480
https://github.com/llvm/llvm-project/pull/77236

It may take a few days for it to be fixed on your side between the
apt.llvm.org update cycle and the tuxmake container rebuild cycle.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v4] rpm-pkg: simplify installkernel %post
  @ 2023-12-20 17:18 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-20 17:18 UTC (permalink / raw)
  To: Jose Ignacio Tornos Martinez
  Cc: masahiroy, dcavalca, linux-kbuild, linux-kernel, ndesaulniers,
	nicolas, stable

On Tue, Dec 19, 2023 at 09:17:19PM +0100, Jose Ignacio Tornos Martinez wrote:
> The new installkernel application that is now included in systemd-udev
> package allows installation although destination files are already present
> in the boot directory of the kernel package, but is failing with the
> implemented workaround for the old installkernel application from grubby
> package.
> 
> For the new installkernel application, as Davide says:
> <<The %post currently does a shuffling dance before calling installkernel.
> This isn't actually necessary afaict, and the current implementation
> ends up triggering downstream issues such as
> https://github.com/systemd/systemd/issues/29568
> This commit simplifies the logic to remove the shuffling. For reference,
> the original logic was added in commit 3c9c7a14b627("rpm-pkg: add %post
> section to create initramfs and grub hooks").>>
> 
> But we need to keep the old behavior as well, because the old installkernel
> application from grubby package, does not allow this simplification and
> we need to be backward compatible to avoid issues with the different
> packages.
> 
> Mimic Fedora shipping process and store vmlinuz, config amd System.map
> in the module directory instead of the boot directory. In this way, we will
> avoid the commented problem for all the cases, because the new destination
> files are not going to exist in the boot directory of the kernel package.
> 
> Replace installkernel tool with kernel-install tool, because the latter is
> more complete. Suitable manual actions are added as a default if tool is not
> present (unusual).
> 
> cc: stable@vger.kernel.org
> Co-Developed-by: Davide Cavalca <dcavalca@meta.com>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

Still works for me on Fedora 39, thanks for the fix!

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
> V1 -> V2:
> - Complete to be backward compatible with the previous installkernel
> application.
> V2 -> V3:
> - Follow the suggestions from Masahiro Yamada and change the installation
> V3 -> V4:
> - Make the patch applicable to linux-kbuild/for-next (ia64 support was
> already removed).
> 
>  scripts/package/kernel.spec | 21 ++++++++++-----------
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index 89298983a169..17e7196c9be1 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -55,12 +55,12 @@ patch -p1 < %{SOURCE2}
>  %{make} %{makeflags} KERNELRELEASE=%{KERNELRELEASE} KBUILD_BUILD_VERSION=%{release}
>  
>  %install
> -mkdir -p %{buildroot}/boot
> -cp $(%{make} %{makeflags} -s image_name) %{buildroot}/boot/vmlinuz-%{KERNELRELEASE}
> +mkdir -p %{buildroot}/lib/modules/%{KERNELRELEASE}
> +cp $(%{make} %{makeflags} -s image_name) %{buildroot}/lib/modules/%{KERNELRELEASE}/vmlinuz
>  %{make} %{makeflags} INSTALL_MOD_PATH=%{buildroot} modules_install
>  %{make} %{makeflags} INSTALL_HDR_PATH=%{buildroot}/usr headers_install
> -cp System.map %{buildroot}/boot/System.map-%{KERNELRELEASE}
> -cp .config %{buildroot}/boot/config-%{KERNELRELEASE}
> +cp System.map %{buildroot}/lib/modules/%{KERNELRELEASE}
> +cp .config %{buildroot}/lib/modules/%{KERNELRELEASE}/config
>  ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEASE}/build
>  %if %{with_devel}
>  %{make} %{makeflags} run-command KBUILD_RUN_COMMAND='${srctree}/scripts/package/install-extmod-build %{buildroot}/usr/src/kernels/%{KERNELRELEASE}'
> @@ -70,12 +70,12 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA
>  rm -rf %{buildroot}
>  
>  %post
> -if [ -x /sbin/installkernel -a -r /boot/vmlinuz-%{KERNELRELEASE} -a -r /boot/System.map-%{KERNELRELEASE} ]; then
> -cp /boot/vmlinuz-%{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm
> -cp /boot/System.map-%{KERNELRELEASE} /boot/.System.map-%{KERNELRELEASE}-rpm
> -rm -f /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE}
> -/sbin/installkernel %{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm
> -rm -f /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm
> +if [ -x /usr/bin/kernel-install ]; then
> +kernel-install add %{KERNELRELEASE} /lib/modules/%{KERNELRELEASE}/vmlinuz
> +else
> +cp /lib/modules/%{KERNELRELEASE}/vmlinuz /boot/vmlinuz-%{KERNELRELEASE}
> +cp /lib/modules/%{KERNELRELEASE}/System.map /boot/System.map-%{KERNELRELEASE}
> +cp /lib/modules/%{KERNELRELEASE}/config /boot/config-%{KERNELRELEASE}
>  fi
>  
>  %preun
> @@ -94,7 +94,6 @@ fi
>  %defattr (-, root, root)
>  /lib/modules/%{KERNELRELEASE}
>  %exclude /lib/modules/%{KERNELRELEASE}/build
> -/boot/*
>  
>  %files headers
>  %defattr (-, root, root)
> -- 
> 2.43.0
> 

^ permalink raw reply	[relevance 99%]

* Apply b8ec60e1186cdcfce41e7db4c827cb107e459002 to linux-6.6.y
@ 2023-12-13  0:03 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-13  0:03 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Fangrui Song, Peter Zijlstra, Josh Poimboeuf, stable, llvm

Hi Greg and Sasha,

Please consider applying commit b8ec60e1186c ("x86/speculation, objtool:
Use absolute relocations for annotations") to linux-6.6.y, which is the
only supported stable version that has the prerequisite commit
1c0c1faf5692 ("objtool: Use relative pointers for annotations"). This
fixes a bunch of warnings along the lines of the one in the commit
message that are seen when linking ARCH=i386 kernels with ld.lld 18+. It
picks cleanly for me.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2] rpm-pkg: simplify installkernel %post
  @ 2023-12-12 19:19 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-12 19:19 UTC (permalink / raw)
  To: Jose Ignacio Tornos Martinez
  Cc: dcavalca, linux-kbuild, linux-kernel, masahiroy, ndesaulniers,
	nicolas, stable

On Tue, Dec 12, 2023 at 06:10:44PM +0100, Jose Ignacio Tornos Martinez wrote:
> A new installkernel application is now included in systemd-udev package
> and it has been improved to allow simplifications.
> 
> For the new installkernel application, as Davide says:
> <<The %post currently does a shuffling dance before calling installkernel.
> This isn't actually necessary afaict, and the current implementation
> ends up triggering downstream issues such as
> https://github.com/systemd/systemd/issues/29568
> This commit simplifies the logic to remove the shuffling. For reference,
> the original logic was added in commit 3c9c7a14b627("rpm-pkg: add %post
> section to create initramfs and grub hooks").>>
> 
> But we need to keep the old behavior as well, because the old installkernel
> application from grubby package, does not allow this simplification and
> we need to be backward compatible to avoid issues with the different
> packages. So the easiest solution is to check the package that provides
> the installkernel application, and simplify (and fix for this
> application at the same time), only if the package is systemd-udev.
> 
> cc: stable@vger.kernel.org
> Co-Developed-by: Davide Cavalca <dcavalca@meta.com>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

Thanks, I can confirm that installing the same RPM package produced by
binrpm-pkg on both Fedora 38 and 39 works as expected now and the check
seems reasonable to me but I'll defer to Masahiro for further comments.

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
> V1 -> V2:
> - Complete to be backward compatible with the previous installkernel
> application.
> 
>  scripts/package/kernel.spec | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index 3eee0143e0c5..d4276ddb6645 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -77,12 +77,16 @@ rm -rf %{buildroot}
>  
>  %post
>  if [ -x /sbin/installkernel -a -r /boot/vmlinuz-%{KERNELRELEASE} -a -r /boot/System.map-%{KERNELRELEASE} ]; then
> +if [ $(rpm -qf /sbin/installkernel --queryformat "%{n}") = systemd-udev ];then
> +/sbin/installkernel %{KERNELRELEASE} /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE}
> +else
>  cp /boot/vmlinuz-%{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm
>  cp /boot/System.map-%{KERNELRELEASE} /boot/.System.map-%{KERNELRELEASE}-rpm
>  rm -f /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE}
>  /sbin/installkernel %{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm
>  rm -f /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm
>  fi
> +fi
>  
>  %preun
>  if [ -x /sbin/new-kernel-pkg ]; then
> -- 
> 2.43.0
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.4 63/94] btrfs: add dmesg output for first mount and last unmount of a filesystem
  @ 2023-12-09 17:28 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-09 17:28 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: stable, patches, Anand Jain, Qu Wenruo, David Sterba

On Tue, Dec 05, 2023 at 12:17:31PM +0900, Greg Kroah-Hartman wrote:
> 5.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Qu Wenruo <wqu@suse.com>
> 
> commit 2db313205f8b96eea467691917138d646bb50aef upstream.
> 
> There is a feature request to add dmesg output when unmounting a btrfs.
> There are several alternative methods to do the same thing, but with
> their own problems:
> 
> - Use eBPF to watch btrfs_put_super()/open_ctree()
>   Not end user friendly, they have to dip their head into the source
>   code.
> 
> - Watch for directory /sys/fs/<uuid>/
>   This is way more simple, but still requires some simple device -> uuid
>   lookups.  And a script needs to use inotify to watch /sys/fs/.
> 
> Compared to all these, directly outputting the information into dmesg
> would be the most simple one, with both device and UUID included.
> 
> And since we're here, also add the output when mounting a filesystem for
> the first time for parity. A more fine grained monitoring of subvolume
> mounts should be done by another layer, like audit.
> 
> Now mounting a btrfs with all default mkfs options would look like this:
> 
>   [81.906566] BTRFS info (device dm-8): first mount of filesystem 633b5c16-afe3-4b79-b195-138fe145e4f2
>   [81.907494] BTRFS info (device dm-8): using crc32c (crc32c-intel) checksum algorithm
>   [81.908258] BTRFS info (device dm-8): using free space tree
>   [81.912644] BTRFS info (device dm-8): auto enabling async discard
>   [81.913277] BTRFS info (device dm-8): checking UUID tree
>   [91.668256] BTRFS info (device dm-8): last unmount of filesystem 633b5c16-afe3-4b79-b195-138fe145e4f2
> 
> CC: stable@vger.kernel.org # 5.4+
> Link: https://github.com/kdave/btrfs-progs/issues/689
> Reviewed-by: Anand Jain <anand.jain@oracle.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: David Sterba <dsterba@suse.com>
> [ update changelog ]
> Signed-off-by: David Sterba <dsterba@suse.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  fs/btrfs/disk-io.c |    1 +
>  fs/btrfs/super.c   |    5 ++++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -2829,6 +2829,7 @@ int open_ctree(struct super_block *sb,
>  		goto fail_alloc;
>  	}
>  
> +	btrfs_info(fs_info, "first mount of filesystem %pU", disk_super->fsid);

clang tells me this backport does not appear to be correct and will
likely introduce a null pointer deference:

  fs/btrfs/disk-io.c:2832:55: warning: variable 'disk_super' is uninitialized when used here [-Wuninitialized]
   2832 |         btrfs_info(fs_info, "first mount of filesystem %pU", disk_super->fsid);
        |                                                              ^~~~~~~~~~
  fs/btrfs/ctree.h:3002:41: note: expanded from macro 'btrfs_info'
   3002 |         btrfs_printk(fs_info, KERN_INFO fmt, ##args)
        |                                                ^~~~
  fs/btrfs/disk-io.c:2630:38: note: initialize the variable 'disk_super' to silence this warning
   2630 |         struct btrfs_super_block *disk_super;
        |                                             ^
        |                                              = NULL
  1 warning generated.

>  	/*
>  	 * Verify the type first, if that or the checksum value are
>  	 * corrupted, we'll find out
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -291,7 +291,10 @@ void __btrfs_panic(struct btrfs_fs_info
>  
>  static void btrfs_put_super(struct super_block *sb)
>  {
> -	close_ctree(btrfs_sb(sb));
> +	struct btrfs_fs_info *fs_info = btrfs_sb(sb);
> +
> +	btrfs_info(fs_info, "last unmount of filesystem %pU", fs_info->fs_devices->fsid);
> +	close_ctree(fs_info);
>  }
>  
>  enum {
> 
> 

^ permalink raw reply	[relevance 99%]

* [PATCH 5.10] PCI: keystone: Drop __init from ks_pcie_add_pcie_{ep,port}()
@ 2023-11-29  0:37 90% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-29  0:37 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: u.kleine-koenig, bhelgaas, llvm, stable, Naresh Kamboju,
	Nathan Chancellor

This commit has no upstream equivalent.

After commit db5ebaeb8fda ("PCI: keystone: Don't discard .probe()
callback") in 5.10, there are two modpost warnings when building with
clang:

  WARNING: modpost: vmlinux.o(.text+0x5aa6dc): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_port()
  The function ks_pcie_probe() references
  the function __init ks_pcie_add_pcie_port().
  This is often because ks_pcie_probe lacks a __init
  annotation or the annotation of ks_pcie_add_pcie_port is wrong.

  WARNING: modpost: vmlinux.o(.text+0x5aa6f4): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_ep()
  The function ks_pcie_probe() references
  the function __init ks_pcie_add_pcie_ep().
  This is often because ks_pcie_probe lacks a __init
  annotation or the annotation of ks_pcie_add_pcie_ep is wrong.

ks_pcie_add_pcie_ep() was removed in upstream commit a0fd361db8e5 ("PCI:
dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common
code") and ks_pcie_add_pcie_port() was removed in upstream
commit 60f5b73fa0f2 ("PCI: dwc: Remove unnecessary wrappers around
dw_pcie_host_init()"), both of which happened before upstream
commit 7994db905c0f ("PCI: keystone: Don't discard .probe() callback").

As neither of these removal changes are really suitable for stable, just
remove __init from these functions in stable, as it is no longer a
correct annotation after dropping __init from ks_pcie_probe().

Fixes: db5ebaeb8fda ("PCI: keystone: Don't discard .probe() callback")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This is not an issue in mainline but I still cc'd the author and
committer of 7994db905c0f in case they would like to check my analysis.
---
 drivers/pci/controller/dwc/pci-keystone.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 5b722287aac9..afaea201a5af 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -865,8 +865,8 @@ static irqreturn_t ks_pcie_err_irq_handler(int irq, void *priv)
 	return ks_pcie_handle_error_irq(ks_pcie);
 }
 
-static int __init ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
-					struct platform_device *pdev)
+static int ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
+				 struct platform_device *pdev)
 {
 	struct dw_pcie *pci = ks_pcie->pci;
 	struct pcie_port *pp = &pci->pp;
@@ -978,8 +978,8 @@ static const struct dw_pcie_ep_ops ks_pcie_am654_ep_ops = {
 	.get_features = &ks_pcie_am654_get_features,
 };
 
-static int __init ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
-				      struct platform_device *pdev)
+static int ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
+			       struct platform_device *pdev)
 {
 	int ret;
 	struct dw_pcie_ep *ep;

---
base-commit: 479e8b8925415420b31e2aa65f9b0db3dea2adf4
change-id: 20231128-5-10-fix-pci-keystone-modpost-warning-a8e886bdc0f7

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 90%]

* [PATCH 5.4] PCI: keystone: Drop __init from ks_pcie_add_pcie_{ep,port}()
@ 2023-11-29  0:35 90% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-29  0:35 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: u.kleine-koenig, bhelgaas, llvm, stable, Naresh Kamboju,
	Nathan Chancellor

This commit has no upstream equivalent.

After commit 012dba0ab814 ("PCI: keystone: Don't discard .probe()
callback") in 5.4, there are two modpost warnings when building with
clang:

  WARNING: modpost: vmlinux.o(.text+0x5aa6dc): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_port()
  The function ks_pcie_probe() references
  the function __init ks_pcie_add_pcie_port().
  This is often because ks_pcie_probe lacks a __init
  annotation or the annotation of ks_pcie_add_pcie_port is wrong.

  WARNING: modpost: vmlinux.o(.text+0x5aa6f4): Section mismatch in reference from the function ks_pcie_probe() to the function .init.text:ks_pcie_add_pcie_ep()
  The function ks_pcie_probe() references
  the function __init ks_pcie_add_pcie_ep().
  This is often because ks_pcie_probe lacks a __init
  annotation or the annotation of ks_pcie_add_pcie_ep is wrong.

ks_pcie_add_pcie_ep() was removed in upstream commit a0fd361db8e5 ("PCI:
dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common
code") and ks_pcie_add_pcie_port() was removed in upstream
commit 60f5b73fa0f2 ("PCI: dwc: Remove unnecessary wrappers around
dw_pcie_host_init()"), both of which happened before upstream
commit 7994db905c0f ("PCI: keystone: Don't discard .probe() callback").

As neither of these removal changes are really suitable for stable, just
remove __init from these functions in stable, as it is no longer a
correct annotation after dropping __init from ks_pcie_probe().

Fixes: 012dba0ab814 ("PCI: keystone: Don't discard .probe() callback")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This is not an issue in mainline but I still cc'd the author and
committer of 7994db905c0f in case they would like to check my analysis.
---
 drivers/pci/controller/dwc/pci-keystone.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index ddbb2b3db74a..920444b1cfc7 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -861,8 +861,8 @@ static irqreturn_t ks_pcie_err_irq_handler(int irq, void *priv)
 	return ks_pcie_handle_error_irq(ks_pcie);
 }
 
-static int __init ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
-					struct platform_device *pdev)
+static int ks_pcie_add_pcie_port(struct keystone_pcie *ks_pcie,
+				 struct platform_device *pdev)
 {
 	struct dw_pcie *pci = ks_pcie->pci;
 	struct pcie_port *pp = &pci->pp;
@@ -992,8 +992,8 @@ static const struct dw_pcie_ep_ops ks_pcie_am654_ep_ops = {
 	.get_features = &ks_pcie_am654_get_features,
 };
 
-static int __init ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
-				      struct platform_device *pdev)
+static int ks_pcie_add_pcie_ep(struct keystone_pcie *ks_pcie,
+			       struct platform_device *pdev)
 {
 	int ret;
 	struct dw_pcie_ep *ep;

---
base-commit: 8e221b47173d59e1b2877f6d8dc91e8be2031746
change-id: 20231128-5-4-fix-pci-keystone-modpost-warning-2a8a9c3fa1ca

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 90%]

* Re: [PATCH v3 1/1] ARM: kprobes: Explicitly reserve r7 for local variables
  @ 2023-11-21 16:38 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-21 16:38 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Maria Yu, linux, mhiramat, kernel, linux-arm-kernel,
	linux-arm-msm, linux-kernel, quic_lijuang, stable

On Tue, Nov 21, 2023 at 11:11:56AM -0500, Ard Biesheuvel wrote:
> On Sun, 19 Nov 2023 at 22:29, Maria Yu <quic_aiquny@quicinc.com> wrote:
> >
> > Registers r7 is removed in clobber list, so compiler may choose r7 for
> > local variables usage, while r7 will be actually updated by the inline asm
> > code. This caused the runtime behavior wrong.
> > While those kind of reserved registers cannot be set to clobber list
> > because of error like "inline asm clobber list contains reserved
> > registers".
> > Explicitly reserve r7 by adding attribute no-omit-frame-pointer for this
> > file, then in T32 asm code r7 is used as a frame pointer and is not
> > available for use as a general-purpose register.
> > Note that "no-omit-frame-pointer" will make the code size a little bigger
> > to store the stack frame pointer.
> >
> > Fixes: dd12e97f3c72 ("ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds")
> > Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> > Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
> > Cc: stable@vger.kernel.org
> > ---
> >  arch/arm/probes/kprobes/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/probes/kprobes/Makefile b/arch/arm/probes/kprobes/Makefile
> > index 6159010dac4a..b1f21e78950b 100644
> > --- a/arch/arm/probes/kprobes/Makefile
> > +++ b/arch/arm/probes/kprobes/Makefile
> > @@ -8,6 +8,7 @@ test-kprobes-objs               := test-core.o
> >
> >  ifdef CONFIG_THUMB2_KERNEL
> >  obj-$(CONFIG_KPROBES)          += actions-thumb.o checkers-thumb.o
> > +CFLAGS_actions-thumb.o         += -fno-omit-frame-pointer
> >  test-kprobes-objs              += test-thumb.o
> >  else
> >  obj-$(CONFIG_KPROBES)          += actions-arm.o checkers-arm.o
> >
> 
> If Nathan is happy with this, I think we can drop this into the patch tracker.

I have no qualms with this approach, there are no issues with the couple
of LLVM versions that I tested.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2 1/1] ARM: kprobes: Explicitly reserve r7 for local variables
  @ 2023-11-16 17:24 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-16 17:24 UTC (permalink / raw)
  To: Maria Yu
  Cc: linux, ardb, mhiramat, kernel, linux-arm-kernel, linux-arm-msm,
	linux-kernel, quic_lijuang, stable

On Wed, Nov 15, 2023 at 05:58:30PM +0800, Maria Yu wrote:
> Registers r7 is removed in clobber list, so compiler may choose r7 for
> local variables usage, while r7 will be actually updated by the inline asm
> code. This caused the runtime behavior wrong.
> While those kind of reserved registers cannot be set to clobber list
> because of error like "inline asm clobber list contains reserved
> registers".
> Explicitly reserve r7 by adding attribute no-omit-frame-pointer for needed
> function, then in T32 asm code r7 is used as a frame pointer and is not
> available for use as a general-purpose register.
> Note that "no-omit-frame-pointer" will make the code size a little bigger
> to store the stack frame pointer. So limited to needed functions can have
> the less impact than the full source file.
> 
> Fixes: dd12e97f3c72 ("ARM: kprobes: treat R7 as the frame pointer register in Thumb2 builds")
> Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
> Cc: stable@vger.kernel.org

This causes warnings with clang:

  arch/arm/probes/kprobes/actions-thumb.c:441:47: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
    441 | static unsigned long __kprobes __attribute__((optimize("no-omit-frame-pointer")))
        |                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  arch/arm/probes/kprobes/actions-thumb.c:524:38: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
    524 | static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
        |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  arch/arm/probes/kprobes/actions-thumb.c:560:38: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
    560 | static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
        |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  arch/arm/probes/kprobes/actions-thumb.c:579:38: warning: unknown attribute 'optimize' ignored [-Wunknown-attributes]
    579 | static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
        |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  4 warnings generated.

Furthermore, as far as I am aware, the optimize attribute has other issues so
its use is discouraged, see commits 080b6f407635 ("bpf: Don't rely on GCC
__attribute__((optimize)) to disable GCSE") and a7223f5bfcae ("powerpc: Avoid
broken GCC __attribute__((optimize))").

Cheers,
Nathan

> ---
>  arch/arm/probes/kprobes/actions-thumb.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/probes/kprobes/actions-thumb.c b/arch/arm/probes/kprobes/actions-thumb.c
> index 51624fc263fc..c2fdaf9f6dba 100644
> --- a/arch/arm/probes/kprobes/actions-thumb.c
> +++ b/arch/arm/probes/kprobes/actions-thumb.c
> @@ -438,7 +438,7 @@ t16_simulate_branch(probes_opcode_t insn,
>  	regs->ARM_pc = pc + (offset * 2);
>  }
>  
> -static unsigned long __kprobes
> +static unsigned long __kprobes __attribute__((optimize("no-omit-frame-pointer")))
>  t16_emulate_loregs(probes_opcode_t insn,
>  		   struct arch_probes_insn *asi, struct pt_regs *regs)
>  {
> @@ -521,7 +521,7 @@ t16_decode_hiregs(probes_opcode_t insn, struct arch_probes_insn *asi,
>  	return INSN_GOOD;
>  }
>  
> -static void __kprobes
> +static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
>  t16_emulate_push(probes_opcode_t insn,
>  		struct arch_probes_insn *asi, struct pt_regs *regs)
>  {
> @@ -557,7 +557,7 @@ t16_decode_push(probes_opcode_t insn, struct arch_probes_insn *asi,
>  	return INSN_GOOD;
>  }
>  
> -static void __kprobes
> +static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
>  t16_emulate_pop_nopc(probes_opcode_t insn,
>  		struct arch_probes_insn *asi, struct pt_regs *regs)
>  {
> @@ -576,7 +576,7 @@ t16_emulate_pop_nopc(probes_opcode_t insn,
>  		);
>  }
>  
> -static void __kprobes
> +static void __kprobes __attribute__((optimize("no-omit-frame-pointer")))
>  t16_emulate_pop_pc(probes_opcode_t insn,
>  		struct arch_probes_insn *asi, struct pt_regs *regs)
>  {
> 
> base-commit: 9bacdd8996c77c42ca004440be610692275ff9d0
> -- 
> 2.17.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 99%]

* Re: stable-rc: 4.14 and 4.19: arch/x86/kernel/head_32.S:126: Error: invalid character '(' in mnemonic
  @ 2023-11-03 16:09 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-03 16:09 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Naresh Kamboju, linux-stable, lkft-triage, Sasha Levin,
	Josh Poimboeuf, Peter Zijlstra

On Fri, Nov 03, 2023 at 04:59:59PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 03, 2023 at 04:57:40PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Nov 03, 2023 at 09:07:32PM +0530, Naresh Kamboju wrote:
> > > Following warnings and errors have been noticed while building i386 build
> > > on stable-rc linux.4.19.y and linux.4.14.y.
> > > 
> > > Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> > > 
> > > Build log:
> > > ==========
> > > kernel/profile.c: In function 'profile_dead_cpu':
> > > kernel/profile.c:346:27: warning: the comparison will always evaluate
> > > as 'true' for the address of 'prof_cpu_mask' will never be NULL
> > > [-Waddress]
> > >   346 |         if (prof_cpu_mask != NULL)
> > >       |                           ^~
> > > kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
> > >    49 | static cpumask_var_t prof_cpu_mask;
> > >       |                      ^~~~~~~~~~~~~
> > > kernel/profile.c: In function 'profile_online_cpu':
> > > kernel/profile.c:383:27: warning: the comparison will always evaluate
> > > as 'true' for the address of 'prof_cpu_mask' will never be NULL
> > > [-Waddress]
> > >   383 |         if (prof_cpu_mask != NULL)
> > >       |                           ^~
> > > kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
> > >    49 | static cpumask_var_t prof_cpu_mask;
> > >       |                      ^~~~~~~~~~~~~
> > > kernel/profile.c: In function 'profile_tick':
> > > kernel/profile.c:413:47: warning: the comparison will always evaluate
> > > as 'true' for the address of 'prof_cpu_mask' will never be NULL
> > > [-Waddress]
> > >   413 |         if (!user_mode(regs) && prof_cpu_mask != NULL &&
> > >       |                                               ^~
> > > kernel/profile.c:49:22: note: 'prof_cpu_mask' declared here
> > >    49 | static cpumask_var_t prof_cpu_mask;
> > >       |                      ^~~~~~~~~~~~~
> > 
> > Those are not due to this set of patches, right?
> > 
> > > arch/x86/kernel/head_32.S: Assembler messages:
> > > arch/x86/kernel/head_32.S:126: Error: invalid character '(' in mnemonic
> > > arch/x86/kernel/head_32.S:57:  Info: macro invoked from here
> > > arch/x86/kernel/head_32.S:128: Error: invalid character '(' in mnemonic
> > > arch/x86/kernel/head_32.S:57:  Info: macro invoked from here
> > 
> > This is odd, nothing touches this file either.
> > 
> > 7e09ac27f43b ("x86: Fix .brk attribute in linker script") is backported
> > here, perhaps that is the issue?  If you revert that, does the error go
> > away?
> 
> Nope, that's not the issue.
> 
> > Let me see if I can build a 32 bit kernel anymore...
> 
> I can do this now, let me figure it out...

Sorry, I think this is my bad. 4.14 and 4.19 do not have
SYM_DATA_START() or SYM_DATA_END() but I did not do a 32-bit x86 build
to see the error. I think this should be the fix, it builds for me at
least. Would you prefer a new set of patches for 4.14 and 4.19 or could
this just be squashed in to my existing backport of a1e2c031ec39
("x86/mm: Simplify RESERVE_BRK()")? Sorry for not catching 7e09ac27f43b
as a fix for that either.

Cheers,
Nathan

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index e0e6aad9cd51..c5ed79159975 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -123,9 +123,9 @@ asmlinkage void __init x86_64_start_reservations(char *real_mode_data);
 
 .macro __RESERVE_BRK name, size
 	.pushsection .bss..brk, "aw"
-SYM_DATA_START(__brk_\name)
+GLOBAL(__brk_\name)
 	.skip \size
-SYM_DATA_END(__brk_\name)
+END(__brk_\name)
 	.popsection
 .endm
 

^ permalink raw reply related	[relevance 99%]

* [PATCH v2] LoongArch: Mark __percpu functions as always inline
@ 2023-11-02 15:43 83% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-02 15:43 UTC (permalink / raw)
  To: chenhuacai, kernel
  Cc: ndesaulniers, trix, jiaxun.yang, loongarch, llvm, patches,
	stable, Nathan Chancellor

A recent change to the optimization pipeline in LLVM reveals some
fragility around the inlining of LoongArch's __percpu functions, which
manifests as a BUILD_BUG() failure:

  In file included from kernel/sched/build_policy.c:17:
  In file included from include/linux/sched/cputime.h:5:
  In file included from include/linux/sched/signal.h:5:
  In file included from include/linux/rculist.h:11:
  In file included from include/linux/rcupdate.h:26:
  In file included from include/linux/irqflags.h:18:
  arch/loongarch/include/asm/percpu.h:97:3: error: call to '__compiletime_assert_51' declared with 'error' attribute: BUILD_BUG failed
     97 |                 BUILD_BUG();
        |                 ^
  include/linux/build_bug.h:59:21: note: expanded from macro 'BUILD_BUG'
     59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
        |                     ^
  include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
     39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
        |                                     ^
  include/linux/compiler_types.h:425:2: note: expanded from macro 'compiletime_assert'
    425 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        |         ^
  include/linux/compiler_types.h:413:2: note: expanded from macro '_compiletime_assert'
    413 |         __compiletime_assert(condition, msg, prefix, suffix)
        |         ^
  include/linux/compiler_types.h:406:4: note: expanded from macro '__compiletime_assert'
    406 |                         prefix ## suffix();                             \
        |                         ^
  <scratch space>:86:1: note: expanded from here
     86 | __compiletime_assert_51
        | ^
  1 error generated.

If these functions are not inlined (which the compiler is free to do
even with functions marked with the standard 'inline' keyword), the
BUILD_BUG() in the default case cannot be eliminated since the compiler
cannot prove it is never used, resulting in a build failure due to the
error attribute.

Mark these functions as __always_inline to guarantee inlining so that
the BUILD_BUG() only triggers when the default case genuinely cannot be
eliminated due to an unexpected size.

Cc:  <stable@vger.kernel.org>
Closes: https://github.com/ClangBuiltLinux/linux/issues/1955
Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
Link: https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Changes in v2:
- Change 'inline' to __always_inline for all functions that contain
  BUILD_BUG() (Huacai)
- Notate that 'inline' does not guarantee inlining in the commit message
  to further clarify the change to __always_inline.
- Link to v1: https://lore.kernel.org/r/20231101-loongarch-always-inline-percpu-ops-v1-1-b8f2e9a71729@kernel.org
---
 arch/loongarch/include/asm/percpu.h | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/loongarch/include/asm/percpu.h b/arch/loongarch/include/asm/percpu.h
index b9f567e66016..313852fba845 100644
--- a/arch/loongarch/include/asm/percpu.h
+++ b/arch/loongarch/include/asm/percpu.h
@@ -32,7 +32,7 @@ static inline void set_my_cpu_offset(unsigned long off)
 #define __my_cpu_offset __my_cpu_offset
 
 #define PERCPU_OP(op, asm_op, c_op)					\
-static inline unsigned long __percpu_##op(void *ptr,			\
+static __always_inline unsigned long __percpu_##op(void *ptr,		\
 			unsigned long val, int size)			\
 {									\
 	unsigned long ret;						\
@@ -63,7 +63,7 @@ PERCPU_OP(and, and, &)
 PERCPU_OP(or, or, |)
 #undef PERCPU_OP
 
-static inline unsigned long __percpu_read(void *ptr, int size)
+static __always_inline unsigned long __percpu_read(void *ptr, int size)
 {
 	unsigned long ret;
 
@@ -100,7 +100,8 @@ static inline unsigned long __percpu_read(void *ptr, int size)
 	return ret;
 }
 
-static inline void __percpu_write(void *ptr, unsigned long val, int size)
+static __always_inline void __percpu_write(void *ptr, unsigned long val,
+					   int size)
 {
 	switch (size) {
 	case 1:
@@ -132,8 +133,8 @@ static inline void __percpu_write(void *ptr, unsigned long val, int size)
 	}
 }
 
-static inline unsigned long __percpu_xchg(void *ptr, unsigned long val,
-						int size)
+static __always_inline unsigned long __percpu_xchg(void *ptr, unsigned long val,
+						   int size)
 {
 	switch (size) {
 	case 1:

---
base-commit: 278be83601dd1725d4732241f066d528e160a39d
change-id: 20231101-loongarch-always-inline-percpu-ops-cf77c161871f

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 83%]

* Re: [PATCH] LoongArch: Mark __percpu functions as always inline
  @ 2023-11-02  2:35 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-11-02  2:35 UTC (permalink / raw)
  To: Huacai Chen
  Cc: kernel, ndesaulniers, trix, jiaxun.yang, loongarch, llvm,
	patches, stable

On Thu, Nov 02, 2023 at 10:18:55AM +0800, Huacai Chen wrote:
> Hi, Nathan,
> 
> On Thu, Nov 2, 2023 at 3:55 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Wed, Nov 01, 2023 at 12:43:29PM -0700, Nathan Chancellor wrote:
> > > A recent change to the optimization pipeline in LLVM reveals some
> > > fragility around the inlining of LoongArch's __percpu functions, which
> > > manifests as a BUILD_BUG() failure:
> > >
> > >   In file included from kernel/sched/build_policy.c:17:
> > >   In file included from include/linux/sched/cputime.h:5:
> > >   In file included from include/linux/sched/signal.h:5:
> > >   In file included from include/linux/rculist.h:11:
> > >   In file included from include/linux/rcupdate.h:26:
> > >   In file included from include/linux/irqflags.h:18:
> > >   arch/loongarch/include/asm/percpu.h:97:3: error: call to '__compiletime_assert_51' declared with 'error' attribute: BUILD_BUG failed
> > >      97 |                 BUILD_BUG();
> > >         |                 ^
> > >   include/linux/build_bug.h:59:21: note: expanded from macro 'BUILD_BUG'
> > >      59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> > >         |                     ^
> > >   include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
> > >      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> > >         |                                     ^
> > >   include/linux/compiler_types.h:425:2: note: expanded from macro 'compiletime_assert'
> > >     425 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> > >         |         ^
> > >   include/linux/compiler_types.h:413:2: note: expanded from macro '_compiletime_assert'
> > >     413 |         __compiletime_assert(condition, msg, prefix, suffix)
> > >         |         ^
> > >   include/linux/compiler_types.h:406:4: note: expanded from macro '__compiletime_assert'
> > >     406 |                         prefix ## suffix();                             \
> > >         |                         ^
> > >   <scratch space>:86:1: note: expanded from here
> > >      86 | __compiletime_assert_51
> > >         | ^
> > >   1 error generated.
> > >
> > > If these functions are not inlined, the BUILD_BUG() in the default case
> > > cannot be eliminated since the compiler cannot prove it is never used,
> > > resulting in a build failure due to the error attribute.
> > >
> > > Mark these functions as __always_inline so that the BUILD_BUG() only
> > > triggers when the default case genuinely cannot be eliminated due to an
> > > unexpected size.
> > >
> > > Cc:  <stable@vger.kernel.org>
> > > Closes: https://github.com/ClangBuiltLinux/linux/issues/1955
> > > Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
> > > Link: https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e
> >
> > This should have also had:
> >
> > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > I can pick it up if I have to send a v2.
> >
> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > ---
> > >  arch/loongarch/include/asm/percpu.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/loongarch/include/asm/percpu.h b/arch/loongarch/include/asm/percpu.h
> > > index b9f567e66016..8fb857ae962b 100644
> > > --- a/arch/loongarch/include/asm/percpu.h
> > > +++ b/arch/loongarch/include/asm/percpu.h
> > > @@ -32,7 +32,7 @@ static inline void set_my_cpu_offset(unsigned long off)
> > >  #define __my_cpu_offset __my_cpu_offset
> > >
> > >  #define PERCPU_OP(op, asm_op, c_op)                                  \
> > > -static inline unsigned long __percpu_##op(void *ptr,                 \
> > > +static __always_inline unsigned long __percpu_##op(void *ptr,                        \
> > >                       unsigned long val, int size)                    \
> > >  {                                                                    \
> > >       unsigned long ret;                                              \
> > > @@ -63,7 +63,7 @@ PERCPU_OP(and, and, &)
> > >  PERCPU_OP(or, or, |)
> > >  #undef PERCPU_OP
> > >
> > > -static inline unsigned long __percpu_read(void *ptr, int size)
> > > +static __always_inline unsigned long __percpu_read(void *ptr, int size)
> > >  {
> > >       unsigned long ret;
> > >
> Thank you for your patch, but I think __percpu_write() and
> __percpu_xchg() also need __always_inline because they also have
> BUILD_BUG(). Although we don't meet problems about them, they have
> potential problems in theory.

Yes, you are absolutely correct! I thought I did a survey for other
BUILD_BUG() locations but seems like I did not do a good job if I did :/
I will send a v2 tomorrow with those two functions changed as well.

Cheers,
Nathan

> > >
> > > ---
> > > base-commit: 278be83601dd1725d4732241f066d528e160a39d
> > > change-id: 20231101-loongarch-always-inline-percpu-ops-cf77c161871f
> > >
> > > Best regards,
> > > --
> > > Nathan Chancellor <nathan@kernel.org>
> > >
> >

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] LoongArch: Mark __percpu functions as always inline
  2023-11-01 19:43 89% [PATCH] LoongArch: Mark __percpu functions as always inline Nathan Chancellor
@ 2023-11-01 19:55 99% ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-11-01 19:55 UTC (permalink / raw)
  To: chenhuacai, kernel
  Cc: ndesaulniers, trix, jiaxun.yang, loongarch, llvm, patches, stable

On Wed, Nov 01, 2023 at 12:43:29PM -0700, Nathan Chancellor wrote:
> A recent change to the optimization pipeline in LLVM reveals some
> fragility around the inlining of LoongArch's __percpu functions, which
> manifests as a BUILD_BUG() failure:
> 
>   In file included from kernel/sched/build_policy.c:17:
>   In file included from include/linux/sched/cputime.h:5:
>   In file included from include/linux/sched/signal.h:5:
>   In file included from include/linux/rculist.h:11:
>   In file included from include/linux/rcupdate.h:26:
>   In file included from include/linux/irqflags.h:18:
>   arch/loongarch/include/asm/percpu.h:97:3: error: call to '__compiletime_assert_51' declared with 'error' attribute: BUILD_BUG failed
>      97 |                 BUILD_BUG();
>         |                 ^
>   include/linux/build_bug.h:59:21: note: expanded from macro 'BUILD_BUG'
>      59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>         |                     ^
>   include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
>      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>         |                                     ^
>   include/linux/compiler_types.h:425:2: note: expanded from macro 'compiletime_assert'
>     425 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>         |         ^
>   include/linux/compiler_types.h:413:2: note: expanded from macro '_compiletime_assert'
>     413 |         __compiletime_assert(condition, msg, prefix, suffix)
>         |         ^
>   include/linux/compiler_types.h:406:4: note: expanded from macro '__compiletime_assert'
>     406 |                         prefix ## suffix();                             \
>         |                         ^
>   <scratch space>:86:1: note: expanded from here
>      86 | __compiletime_assert_51
>         | ^
>   1 error generated.
> 
> If these functions are not inlined, the BUILD_BUG() in the default case
> cannot be eliminated since the compiler cannot prove it is never used,
> resulting in a build failure due to the error attribute.
> 
> Mark these functions as __always_inline so that the BUILD_BUG() only
> triggers when the default case genuinely cannot be eliminated due to an
> unexpected size.
> 
> Cc:  <stable@vger.kernel.org>
> Closes: https://github.com/ClangBuiltLinux/linux/issues/1955
> Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
> Link: https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e

This should have also had:

Suggested-by: Nick Desaulniers <ndesaulniers@google.com>

I can pick it up if I have to send a v2.

> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/loongarch/include/asm/percpu.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/loongarch/include/asm/percpu.h b/arch/loongarch/include/asm/percpu.h
> index b9f567e66016..8fb857ae962b 100644
> --- a/arch/loongarch/include/asm/percpu.h
> +++ b/arch/loongarch/include/asm/percpu.h
> @@ -32,7 +32,7 @@ static inline void set_my_cpu_offset(unsigned long off)
>  #define __my_cpu_offset __my_cpu_offset
>  
>  #define PERCPU_OP(op, asm_op, c_op)					\
> -static inline unsigned long __percpu_##op(void *ptr,			\
> +static __always_inline unsigned long __percpu_##op(void *ptr,			\
>  			unsigned long val, int size)			\
>  {									\
>  	unsigned long ret;						\
> @@ -63,7 +63,7 @@ PERCPU_OP(and, and, &)
>  PERCPU_OP(or, or, |)
>  #undef PERCPU_OP
>  
> -static inline unsigned long __percpu_read(void *ptr, int size)
> +static __always_inline unsigned long __percpu_read(void *ptr, int size)
>  {
>  	unsigned long ret;
>  
> 
> ---
> base-commit: 278be83601dd1725d4732241f066d528e160a39d
> change-id: 20231101-loongarch-always-inline-percpu-ops-cf77c161871f
> 
> Best regards,
> -- 
> Nathan Chancellor <nathan@kernel.org>
> 

^ permalink raw reply	[relevance 99%]

* [PATCH] LoongArch: Mark __percpu functions as always inline
@ 2023-11-01 19:43 89% Nathan Chancellor
  2023-11-01 19:55 99% ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-11-01 19:43 UTC (permalink / raw)
  To: chenhuacai, kernel
  Cc: ndesaulniers, trix, jiaxun.yang, loongarch, llvm, patches,
	stable, Nathan Chancellor

A recent change to the optimization pipeline in LLVM reveals some
fragility around the inlining of LoongArch's __percpu functions, which
manifests as a BUILD_BUG() failure:

  In file included from kernel/sched/build_policy.c:17:
  In file included from include/linux/sched/cputime.h:5:
  In file included from include/linux/sched/signal.h:5:
  In file included from include/linux/rculist.h:11:
  In file included from include/linux/rcupdate.h:26:
  In file included from include/linux/irqflags.h:18:
  arch/loongarch/include/asm/percpu.h:97:3: error: call to '__compiletime_assert_51' declared with 'error' attribute: BUILD_BUG failed
     97 |                 BUILD_BUG();
        |                 ^
  include/linux/build_bug.h:59:21: note: expanded from macro 'BUILD_BUG'
     59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
        |                     ^
  include/linux/build_bug.h:39:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
     39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
        |                                     ^
  include/linux/compiler_types.h:425:2: note: expanded from macro 'compiletime_assert'
    425 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        |         ^
  include/linux/compiler_types.h:413:2: note: expanded from macro '_compiletime_assert'
    413 |         __compiletime_assert(condition, msg, prefix, suffix)
        |         ^
  include/linux/compiler_types.h:406:4: note: expanded from macro '__compiletime_assert'
    406 |                         prefix ## suffix();                             \
        |                         ^
  <scratch space>:86:1: note: expanded from here
     86 | __compiletime_assert_51
        | ^
  1 error generated.

If these functions are not inlined, the BUILD_BUG() in the default case
cannot be eliminated since the compiler cannot prove it is never used,
resulting in a build failure due to the error attribute.

Mark these functions as __always_inline so that the BUILD_BUG() only
triggers when the default case genuinely cannot be eliminated due to an
unexpected size.

Cc:  <stable@vger.kernel.org>
Closes: https://github.com/ClangBuiltLinux/linux/issues/1955
Fixes: 46859ac8af52 ("LoongArch: Add multi-processor (SMP) support")
Link: https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/loongarch/include/asm/percpu.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/loongarch/include/asm/percpu.h b/arch/loongarch/include/asm/percpu.h
index b9f567e66016..8fb857ae962b 100644
--- a/arch/loongarch/include/asm/percpu.h
+++ b/arch/loongarch/include/asm/percpu.h
@@ -32,7 +32,7 @@ static inline void set_my_cpu_offset(unsigned long off)
 #define __my_cpu_offset __my_cpu_offset
 
 #define PERCPU_OP(op, asm_op, c_op)					\
-static inline unsigned long __percpu_##op(void *ptr,			\
+static __always_inline unsigned long __percpu_##op(void *ptr,			\
 			unsigned long val, int size)			\
 {									\
 	unsigned long ret;						\
@@ -63,7 +63,7 @@ PERCPU_OP(and, and, &)
 PERCPU_OP(or, or, |)
 #undef PERCPU_OP
 
-static inline unsigned long __percpu_read(void *ptr, int size)
+static __always_inline unsigned long __percpu_read(void *ptr, int size)
 {
 	unsigned long ret;
 

---
base-commit: 278be83601dd1725d4732241f066d528e160a39d
change-id: 20231101-loongarch-always-inline-percpu-ops-cf77c161871f

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 89%]

* Re: [PATCH] lib/Kconfig.debug: disable FRAME_WARN for kasan and kcsan
  @ 2023-10-19 20:51 95%               ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-10-19 20:51 UTC (permalink / raw)
  To: Hamza Mahfooz
  Cc: Arnd Bergmann, Alexander Potapenko, Geert Uytterhoeven,
	linux-kernel, Rodrigo Siqueira, Harry Wentland, Alex Deucher,
	stable, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
	Boqun Feng, Gary Guo, Björn Roy Baron, Nick Terrell,
	Nick Desaulniers, Tom Rix, Andrew Morton, Masami Hiramatsu,
	Randy Dunlap, Kees Cook, Zhaoyang Huang, Li Hua, Rae Moar,
	rust-for-linux, bpf, llvm

On Thu, Oct 19, 2023 at 04:17:26PM -0400, Hamza Mahfooz wrote:
> On 10/19/23 11:56, Nathan Chancellor wrote:
> > On Thu, Oct 19, 2023 at 02:53:01PM +0200, Arnd Bergmann wrote:
> > > On Thu, Oct 19, 2023, at 12:04, Alexander Potapenko wrote:
> > > > So the remaining option would be to just increase the frame size every
> > > > time a new function surpasses the limit.
> > > 
> > > That is clearly not an option, though we could try to
> > > add Kconfig dependencies that avoid the known bad combinations,
> > > such as annotating the AMD GPU driver as
> > > 
> > >        depends on (CC_IS_GCC || CLANG_VERSION >=180000) || !(KASAN || KCSAN)
> > 
> > This would effectively disable the AMDGPU driver for allmodconfig, which
> > is somewhat unfortunate as it is an easy testing target.
> > 
> > Taking a step back, this is all being done because of a couple of
> > warnings in the AMDGPU code. If fixing those in the source is too much
> > effort (I did note [1] that GCC is at the current limit for that file
> > even with Rodrigo's series applied [2]), couldn't we just take the
> > existing workaround that this Makefile has for this file and its high
> > stack usage and just extend it slightly for clang?
> 
> I personally don't mind fixing these issues in the driver, but the fact
> that they the creep back every time a new major version of Clang rolls
> out (that has been true for the past couple of years at the very
> least), makes it rather annoying to deal with.

I am not sure I agree with that characterization of the situation. clang
has been pretty consistent for the most part (which is certainly on us),
as all versions that the kernel supports warns about this code. I
believe it is more so the fact that there is a new copy of the dcn code
added every year that has none of the fixes applied from earlier
generations... It is not just me that has fixed issues like this, just
run 'git log --grep=stack drivers/gpu/drm/amd/display'. It is not just
clang that complains about the code when sanitizers are turned on, GCC
does as well since Stephen reported them.

Cheers,
Nathan

> > diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> > index 66431525f2a0..fd49e3526c0d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
> > @@ -58,7 +58,7 @@ endif
> >   endif
> >   ifneq ($(CONFIG_FRAME_WARN),0)
> > -frame_warn_flag := -Wframe-larger-than=2048
> > +frame_warn_flag := -Wframe-larger-than=$(if $(CONFIG_CC_IS_CLANG),3072,2048)
> >   endif
> >   CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) $(frame_warn_flag)
> > 
> > That would address the immediate concern of the warning breaking builds
> > with CONFIG_WERROR=y while not raising the limit for other files in the
> > kernel (just this one file in AMDGPU) and avoiding disabling the whole
> > driver. The number could be lower, I think ~2500 bytes is the most usage
> > I see with Rodrigo's series applied, so maybe 2800 would be a decent
> > limit? Once there is a fix in the compiler, this expression could be
> > changed to use clang-min-version or something of that sort.
> > 
> > [1]: https://lore.kernel.org/20231017172231.GA2348194@dev-arch.thelio-3990X/
> > [2]: https://lore.kernel.org/20231016142031.241912-1-Rodrigo.Siqueira@amd.com/
> > 
> > Cheers,
> > Nathan
> -- 
> Hamza
> 

^ permalink raw reply	[relevance 95%]

* Re: [PATCH] lib/Kconfig.debug: disable FRAME_WARN for kasan and kcsan
  @ 2023-10-19 15:56 89%           ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-10-19 15:56 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Alexander Potapenko, Geert Uytterhoeven, Hamza Mahfooz,
	linux-kernel, Rodrigo Siqueira, Harry Wentland, Alex Deucher,
	stable, Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho,
	Boqun Feng, Gary Guo, Björn Roy Baron, Nick Terrell,
	Nick Desaulniers, Tom Rix, Andrew Morton, Masami Hiramatsu,
	Randy Dunlap, Kees Cook, Zhaoyang Huang, Li Hua, Rae Moar,
	rust-for-linux, bpf, llvm

On Thu, Oct 19, 2023 at 02:53:01PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 19, 2023, at 12:04, Alexander Potapenko wrote:
> > So the remaining option would be to just increase the frame size every
> > time a new function surpasses the limit.
> 
> That is clearly not an option, though we could try to
> add Kconfig dependencies that avoid the known bad combinations,
> such as annotating the AMD GPU driver as
> 
>       depends on (CC_IS_GCC || CLANG_VERSION >=180000) || !(KASAN || KCSAN)

This would effectively disable the AMDGPU driver for allmodconfig, which
is somewhat unfortunate as it is an easy testing target.

Taking a step back, this is all being done because of a couple of
warnings in the AMDGPU code. If fixing those in the source is too much
effort (I did note [1] that GCC is at the current limit for that file
even with Rodrigo's series applied [2]), couldn't we just take the
existing workaround that this Makefile has for this file and its high
stack usage and just extend it slightly for clang?

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/Makefile b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
index 66431525f2a0..fd49e3526c0d 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml2/Makefile
@@ -58,7 +58,7 @@ endif
 endif
 
 ifneq ($(CONFIG_FRAME_WARN),0)
-frame_warn_flag := -Wframe-larger-than=2048
+frame_warn_flag := -Wframe-larger-than=$(if $(CONFIG_CC_IS_CLANG),3072,2048)
 endif
 
 CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags) $(frame_warn_flag)

That would address the immediate concern of the warning breaking builds
with CONFIG_WERROR=y while not raising the limit for other files in the
kernel (just this one file in AMDGPU) and avoiding disabling the whole
driver. The number could be lower, I think ~2500 bytes is the most usage
I see with Rodrigo's series applied, so maybe 2800 would be a decent
limit? Once there is a fix in the compiler, this expression could be
changed to use clang-min-version or something of that sort.

[1]: https://lore.kernel.org/20231017172231.GA2348194@dev-arch.thelio-3990X/
[2]: https://lore.kernel.org/20231016142031.241912-1-Rodrigo.Siqueira@amd.com/

Cheers,
Nathan

^ permalink raw reply related	[relevance 89%]

* [PATCH 5.10] drm/mediatek: Fix backport issue in mtk_drm_gem_prime_vmap()
@ 2023-09-22 15:51 95% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-09-22 15:51 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Chun-Kuang Hu, Philipp Zabel, linux-mediatek, stable, llvm,
	Nathan Chancellor

When building with clang:

  drivers/gpu/drm/mediatek/mtk_drm_gem.c:255:10: error: incompatible integer to pointer conversion returning 'int' from a function with result type 'void *' [-Wint-conversion]
    255 |                 return -ENOMEM;
        |                        ^~~~~~~
  1 error generated.

GCC reports the same issue as a warning, rather than an error.

Prior to commit 7e542ff8b463 ("drm/mediatek: Use struct dma_buf_map in
GEM vmap ops"), this function returned a pointer rather than an integer.
This function is indirectly called in drm_gem_vmap(), which treats NULL
as -ENOMEM through an error pointer. Return NULL in this block to
resolve the warning but keep the same end result.

Fixes: 43f561e809aa ("drm/mediatek: Fix potential memory leak if vmap() fail")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This is a fix for a 5.10 backport, so it has no upstream relevance but
I've still cc'd the relevant maintainers in case they have any comments
or want to double check my work.
---
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index fe64bf2176f3..b20ea58907c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -252,7 +252,7 @@ void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
 	if (!mtk_gem->kvaddr) {
 		kfree(sgt);
 		kfree(mtk_gem->pages);
-		return -ENOMEM;
+		return NULL;
 	}
 out:
 	kfree(sgt);

---
base-commit: ff0bfa8f23eb4c5a65ee6b0d0b7dc2e3439f1063
change-id: 20230922-5-10-fix-drm-mediatek-backport-0ee69329fef0

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 95%]

* Re: [PATCH  bpf  v3 1/2] bpf: Fix BTF_ID symbol generation collision
  @ 2023-09-15 18:30 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-09-15 18:30 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh, Jiri Olsa,
	linux-kernel, bpf, Martin KaFai Lau, Song Liu, Yonghong Song,
	John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, stable,
	Satya Durga Srinivasu Prabhala, Marcus Seyfarth

On Fri, Sep 15, 2023 at 10:34:27AM -0700, Nick Desaulniers wrote:
> From: Jiri Olsa <jolsa@kernel.org>
> 
> Marcus and Satya reported an issue where BTF_ID macro generates same
> symbol in separate objects and that breaks final vmlinux link.
> 
> ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
> '__BTF_ID__struct__cgroup__624' is already defined
> 
> This can be triggered under specific configs when __COUNTER__ happens to
> be the same for the same symbol in two different translation units,
> which is already quite unlikely to happen.
> 
> Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
> not a complete fix, but it would help for now and meanwhile we can work
> on better solution as suggested by Andrii.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
> Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
> Debugged-by: Nathan Chancellor <nathan@kernel.org>
> Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  include/linux/btf_ids.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> index a3462a9b8e18..a9cb10b0e2e9 100644
> --- a/include/linux/btf_ids.h
> +++ b/include/linux/btf_ids.h
> @@ -49,7 +49,7 @@ word							\
>  	____BTF_ID(symbol, word)
>  
>  #define __ID(prefix) \
> -	__PASTE(prefix, __COUNTER__)
> +	__PASTE(__PASTE(prefix, __COUNTER__), __LINE__)
>  
>  /*
>   * The BTF_ID defines unique symbol for each ID pointing
> 
> -- 
> 2.42.0.459.ge4e396fd5e-goog
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2] bpf: Fix BTF_ID symbol generation collision
  @ 2023-09-15 17:18 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-09-15 17:18 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	linux-kernel, bpf, Martin KaFai Lau, Song Liu, Yonghong Song,
	John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, stable,
	Satya Durga Srinivasu Prabhala, Marcus Seyfarth, Jiri Olsa

On Fri, Sep 15, 2023 at 09:42:20AM -0700, Nick Desaulniers wrote:
> Marcus and Satya reported an issue where BTF_ID macro generates same
> symbol in separate objects and that breaks final vmlinux link.
> 
>   ld.lld: error: ld-temp.o <inline asm>:14577:1: symbol
>   '__BTF_ID__struct__cgroup__624' is already defined
> 
> This can be triggered under specific configs when __COUNTER__ happens to
> be the same for the same symbol in two different translation units,
> which is already quite unlikely to happen.
> 
> Add __LINE__ number suffix to make BTF_ID symbol more unique, which is
> not a complete fix, but it would help for now and meanwhile we can work
> on better solution as suggested by Andrii.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
> Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Closes: https://github.com/ClangBuiltLinux/linux/issues/1913
> Tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Debugged-by: Nathan Chancellor <nathan@kernel.org>
> Co-developed-by: Jiri Olsa <jolsa@kernel.org>
> Link: https://lore.kernel.org/bpf/CAEf4Bzb5KQ2_LmhN769ifMeSJaWfebccUasQOfQKaOd0nQ51tw@mail.gmail.com/
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
>  tools/include/linux/btf_ids.h | 2 +-

Shouldn't this diff be in include/linux/btf_ids.h as well? Otherwise, I
don't think it will be used by the kernel build.

>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/include/linux/btf_ids.h b/tools/include/linux/btf_ids.h
> index 71e54b1e3796..30e920b96a18 100644
> --- a/tools/include/linux/btf_ids.h
> +++ b/tools/include/linux/btf_ids.h
> @@ -38,7 +38,7 @@ asm(							\
>  	____BTF_ID(symbol)
>  
>  #define __ID(prefix) \
> -	__PASTE(prefix, __COUNTER__)
> +	__PASTE(prefix, __COUNTER__ __LINE__)
>  
>  /*
>   * The BTF_ID defines unique symbol for each ID pointing
> 
> ---
> base-commit: 9fdfb15a3dbf818e06be514f4abbfc071004cbe7
> change-id: 20230915-bpf_collision-36889a391d44
> 
> Best regards,
> -- 
> Nick Desaulniers <ndesaulniers@google.com>
> 

^ permalink raw reply	[relevance 99%]

* Apply 13e07691a16f and co. to linux-6.1.y
@ 2023-09-08 16:15 96% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-09-08 16:15 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, bpf, Jiri Olsa, Ian Rogers, Nick Desaulniers

Hi Greg and Sasha,

Please consider applying the following commits to 6.1 (they all picked
cleanly for me):

630ae80ea1dd ("tools lib subcmd: Add install target")
77dce6890a2a ("tools lib subcmd: Make install_headers clearer")
5d890591db6b ("tools lib subcmd: Add dependency test to install_headers")
0e43662e61f2 ("tools/resolve_btfids: Use pkg-config to locate libelf")
af03299d8536 ("tools/resolve_btfids: Install subcmd headers")
13e07691a16f ("tools/resolve_btfids: Alter how HOSTCC is forced")
56a2df7615fa ("tools/resolve_btfids: Compile resolve_btfids as host program")
e0975ab92f24 ("tools/resolve_btfids: Tidy HOST_OVERRIDES")
2531ba0e4ae6 ("tools/resolve_btfids: Pass HOSTCFLAGS as EXTRA_CFLAGS to prepare targets")
edd75c802855 ("tools/resolve_btfids: Fix setting HOSTCFLAGS")

The most critical change is 13e07691a16f, which resolves a missing
EXTRA_CFLAGS to the libsubcmd build. Without that EXTRA_CFLAGS, the
Android hermetic toolchain kernel build fails on host distributions
using glibc 2.38 and newer. The majority of those commits are strictly
needed due to dependency/fixes requirements, the few that are not still
seem to be worth bringing in for ease of backporting the rest and do not
appear to cause any problems.

I proposed another solution downstream, which may be more palatable if
people have concerns about this list of changes and the risk of
regressions, but Ian seemed to have some concerns on that thread around
that path and suggested this series of backports instead:

https://android-review.googlesource.com/c/kernel/common/+/2745896

While the number of patches seems large, the final changes are pretty
well self-contained.

Cheers,
Nathan

^ permalink raw reply	[relevance 96%]

* [PATCH 5.15] of: kexec: Mark ima_{free,stable}_kexec_buffer() as __init
@ 2023-09-05 20:36 89% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-09-05 20:36 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: stable, robh+dt, frowand.list, zohar, dmitry.kasatkin,
	devicetree, linux-integrity, linux-security-module,
	Nathan Chancellor

This commit has no direct upstream equivalent.

After commit d48016d74836 ("mm,ima,kexec,of: use memblock_free_late from
ima_free_kexec_buffer") in 5.15, there is a modpost warning for certain
configurations:

  WARNING: modpost: vmlinux.o(.text+0xb14064): Section mismatch in reference from the function ima_free_kexec_buffer() to the function .init.text:__memblock_free_late()
  The function ima_free_kexec_buffer() references
  the function __init __memblock_free_late().
  This is often because ima_free_kexec_buffer lacks a __init
  annotation or the annotation of __memblock_free_late is wrong.

In mainline, there is no issue because ima_free_kexec_buffer() is marked
as __init, which was done as part of commit b69a2afd5afc ("x86/kexec:
Carry forward IMA measurement log on kexec") in 6.0, which is not
suitable for stable.

Mark ima_free_kexec_buffer() and its single caller
ima_load_kexec_buffer() as __init in 5.15, as ima_load_kexec_buffer() is
only called from ima_init(), which is __init, clearing up the warning.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/of/kexec.c                 | 2 +-
 include/linux/of.h                 | 2 +-
 security/integrity/ima/ima.h       | 2 +-
 security/integrity/ima/ima_kexec.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 3a07cc58e7d7..d10fd54415c2 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -165,7 +165,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
 /**
  * ima_free_kexec_buffer - free memory used by the IMA buffer
  */
-int ima_free_kexec_buffer(void)
+int __init ima_free_kexec_buffer(void)
 {
 	int ret;
 	unsigned long addr;
diff --git a/include/linux/of.h b/include/linux/of.h
index 140671cb746a..6f15e8b0f9d1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -574,7 +574,7 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
 				   unsigned long initrd_len,
 				   const char *cmdline, size_t extra_fdt_size);
 int ima_get_kexec_buffer(void **addr, size_t *size);
-int ima_free_kexec_buffer(void);
+int __init ima_free_kexec_buffer(void);
 #else /* CONFIG_OF */
 
 static inline void of_core_init(void)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index be965a8715e4..0afe413dda68 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -122,7 +122,7 @@ struct ima_kexec_hdr {
 extern const int read_idmap[];
 
 #ifdef CONFIG_HAVE_IMA_KEXEC
-void ima_load_kexec_buffer(void);
+void __init ima_load_kexec_buffer(void);
 #else
 static inline void ima_load_kexec_buffer(void) {}
 #endif /* CONFIG_HAVE_IMA_KEXEC */
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index f799cc278a9a..f3b10851bbbf 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -137,7 +137,7 @@ void ima_add_kexec_buffer(struct kimage *image)
 /*
  * Restore the measurement list from the previous kernel.
  */
-void ima_load_kexec_buffer(void)
+void __init ima_load_kexec_buffer(void)
 {
 	void *kexec_buffer = NULL;
 	size_t kexec_buffer_size = 0;

---
base-commit: 8f790700c974345ab78054e109beddd84539f319
change-id: 20230905-5-15-of-kexec-modpost-warning-6a6b48f30ebf

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 89%]

* Apply 9451c79bc39e610882bdd12370f01af5004a3c4f to linux-5.4.y
@ 2023-08-30 15:33 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-30 15:33 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, Nick Desaulniers, Michael Ellerman

Hi Greg and Sasha,

Please consider applying commit 9451c79bc39e ("powerpc/pmac/smp: Avoid
unused-variable warnings") to 5.4, as it resolves a build failure that
we see building ppc64_guest_defconfig with clang due to arch/powerpc
compiling with -Werror by default:

  arch/powerpc/platforms/powermac/smp.c:664:26: error: unused variable 'core99_l2_cache' [-Werror,-Wunused-variable]
    664 | volatile static long int core99_l2_cache;
        |                          ^~~~~~~~~~~~~~~
  arch/powerpc/platforms/powermac/smp.c:665:26: error: unused variable 'core99_l3_cache' [-Werror,-Wunused-variable]
    665 | volatile static long int core99_l3_cache;
        |                          ^~~~~~~~~~~~~~~
  2 errors generated.

I have verified that it applies cleanly and does not appear to have any
direct follow up fixes, although commit a4037d1f1fc4 ("powerpc/pmac/smp:
Drop unnecessary volatile qualifier") was in the same area around the
same time so maybe it makes sense to take that one as well but I don't
think it has any functional impact.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: clang: net: qed_main.c:1227:3: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 18 [-Werror,-Wfortify-source]
  @ 2023-08-28 14:48 91% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-28 14:48 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: clang-built-linux, linux-stable, lkft-triage, Netdev,
	David Miller, Eric Dumazet, Sasha Levin, Greg Kroah-Hartman,
	Nick Desaulniers, Ariel Elior, Manish Chopra

Hi Naresh,

On Mon, Aug 28, 2023 at 05:57:38PM +0530, Naresh Kamboju wrote:
> [My two cents]
> 
> stable-rc linux-6.1.y and linux-6.4.y x86 clang-nightly builds fail with
> following warnings / errors.
> 
> Build errors:
> --------------
> drivers/net/ethernet/qlogic/qed/qed_main.c:1227:3: error: 'snprintf'
> will always be truncated; specified size is 16, but format string
> expands to at least 18 [-Werror,-Wfortify-source]
>  1227 |                 snprintf(name, NAME_SIZE, "slowpath-%02x:%02x.%02x",
>       |                 ^
> 1 error generated.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

Thank you as always for the report. This is a result of a change in
clang to implement the equivalent of GCC's -Wformat-truncation, which is
currently disabled for the whole kernel in mainline and enabled in W=1
in -next. I have filed an issue to figure out what to do about this:
https://github.com/ClangBuiltLinux/linux/issues/1923

For the record, if you see an issue with clang-nightly that you do not
see with older versions of clang, it is generally an indication that
something has changed on the toolchain side, so it is probably not worth
bothering the stable or subsystem folks with the initial report.
Consider just messaging Nick, myself, and llvm@lists.linux.dev in those
cases so we can pre-triage and bring other folks in as necessary.

That said, this seems like a legitimate warning. As I mentioned above,
GCC shows the same warning with W=1 in -next, so this should be fixed.

  drivers/net/ethernet/qlogic/qed/qed_main.c: In function 'qed_slowpath_start':
  drivers/net/ethernet/qlogic/qed/qed_main.c:1218:63: error: '%02x' directive output truncated writing 2 bytes into a region of size 1 [-Werror=format-truncation=]
   1218 |                 snprintf(name, NAME_SIZE, "slowpath-%02x:%02x.%02x",
        |                                                               ^~~~
  In function 'qed_slowpath_wq_start',
      inlined from 'qed_slowpath_start' at drivers/net/ethernet/qlogic/qed/qed_main.c:1250:6:
  drivers/net/ethernet/qlogic/qed/qed_main.c:1218:43: note: directive argument in the range [0, 255]
   1218 |                 snprintf(name, NAME_SIZE, "slowpath-%02x:%02x.%02x",
        |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/net/ethernet/qlogic/qed/qed_main.c:1218:17: note: 'snprintf' output 18 bytes into a destination of size 16
   1218 |                 snprintf(name, NAME_SIZE, "slowpath-%02x:%02x.%02x",
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1219 |                          cdev->pdev->bus->number,
        |                          ~~~~~~~~~~~~~~~~~~~~~~~~
   1220 |                          PCI_SLOT(cdev->pdev->devfn), hwfn->abs_pf_id);
        |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors

Cheers,
Nathan

^ permalink raw reply	[relevance 91%]

* Re: [PATCH v2] lib: test_scanf: Add explicit type cast to result initialization in test_number_prefix()
  @ 2023-08-16 14:01 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-16 14:01 UTC (permalink / raw)
  To: Petr Mladek
  Cc: rostedt, senozhatsky, andriy.shevchenko, linux, ndesaulniers,
	trix, linux-kernel, llvm, patches, stable

Hi Petr,

On Wed, Aug 16, 2023 at 01:01:46PM +0200, Petr Mladek wrote:
> On Mon 2023-08-07 08:36:28, Nathan Chancellor wrote:
> > A recent change in clang allows it to consider more expressions as
> > compile time constants, which causes it to point out an implicit
> > conversion in the scanf tests:
> > 
> >   lib/test_scanf.c:661:2: warning: implicit conversion from 'int' to 'unsigned char' changes value from -168 to 88 [-Wconstant-conversion]
> >     661 |         test_number_prefix(unsigned char,       "0xA7", "%2hhx%hhx", 0, 0xa7, 2, check_uchar);
> >         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   lib/test_scanf.c:609:29: note: expanded from macro 'test_number_prefix'
> >     609 |         T result[2] = {~expect[0], ~expect[1]};                                 \
> >         |                       ~            ^~~~~~~~~~
> >   1 warning generated.
> > 
> > The result of the bitwise negation is the type of the operand after
> > going through the integer promotion rules, so this truncation is
> > expected but harmless, as the initial values in the result array get
> > overwritten by _test() anyways. Add an explicit cast to the expected
> > type in test_number_prefix() to silence the warning. There is no
> > functional change, as all the tests still pass with GCC 13.1.0 and clang
> > 18.0.0.
> > 
> > Cc: stable@vger.kernel.org
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1899
> 
> "Closes:" is not a valid tag. It was proposed and rejected in the end.
> I replaced it with "Link:" as suggested by ./scripts/checkpatch.pl/

I don't really care about "Closes:" vs. "Link:", either is fine with me,
but checkpatch.pl did not warn me about it and I still see commit
44c31888098a ("checkpatch: allow Closes tags with links") in mainline
and -next that explicitly allows this (and even requires Closes: instead
of Link: when following Reported-by:).

> > Link: https://github.com/llvm/llvm-project/commit/610ec954e1f81c0e8fcadedcd25afe643f5a094e
> > Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> 
> The patch has been pushed into printk/linux.git, branch for-6.6.

Thanks a lot for the review and acceptance!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 6.1 000/127] 6.1.45-rc1 review
  @ 2023-08-14 16:52 99%         ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-14 16:52 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Guenter Roeck, Naresh Kamboju, Greg Kroah-Hartman,
	clang-built-linux, stable, patches, linux-kernel, torvalds, akpm,
	shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
	sudipm.mukherjee, srw, rwarsow, conor, Nick Desaulniers,
	Sven Volkinsfeld, Daniel Kolesa, x86

On Sun, Aug 13, 2023 at 01:02:54PM +0200, Borislav Petkov wrote:
> On Thu, Aug 10, 2023 at 09:13:39PM -0700, Nathan Chancellor wrote:
> > 1911 is still being investigated (some additional eyes on it would not
> > hurt).
> 
> I'm hoping that we can take this one:
> 
> https://lore.kernel.org/r/20230809072200.543939260@infradead.org
> 
> which should resolve this issue, right?

Yes, it does, as least for mainline and 6.4. The backport to 6.1 seems
hairy (due to a lack of call depth tracking me thinks). It may be worth
taking Nick's change there for simplicity's sake but I'll let y'all make
that decision.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 6.1 000/127] 6.1.45-rc1 review
  @ 2023-08-11  4:13 93%     ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-08-11  4:13 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Naresh Kamboju, Greg Kroah-Hartman, clang-built-linux, stable,
	patches, linux-kernel, torvalds, akpm, shuah, patches,
	lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
	rwarsow, conor, Nick Desaulniers, Sven Volkinsfeld,
	Daniel Kolesa, Borislav Petkov, x86

On Thu, Aug 10, 2023 at 08:41:42PM -0700, Guenter Roeck wrote:
> On 8/10/23 20:22, Naresh Kamboju wrote:
> > Build errors:
> > -----
> > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:193: at least one side of
> > the expression must be absolute
> > make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > 
> 
> We see that with v5.10.y, v5.15.y, and v6.1.y when building ChromeOS images with
> clang/lld. There are additional problems with LTO and the built-in assembler. See
> https://www.linuxquestions.org/questions/slackware-14/error-building-kernel-6-1-44-on-current-with-clang-4175727865/
> for a summary.

Yup, we have issues open for all of those:

https://github.com/ClangBuiltLinux/linux/issues/1907
https://github.com/ClangBuiltLinux/linux/issues/1909
https://github.com/ClangBuiltLinux/linux/issues/1911

1907 is fixed in -tip and I am sure it will make -rc6 [1].

1909 is fixed with [2] but it is sitting in x86/core (i.e., slated for
next merge window). I am guessing at the time it was picked up, it was
not fixing a noticeable issue, which is obviously not the case now. Nick
reached out to the -tip folks on IRC to inquire about getting that
applied to a branch that is going to Linus soon, as it is more of a
process issue since it has conflicts with SRSO and an separate issue
that was pointed out post-acceptance (which I addressed and pushed to
[3] for testing). I never saw a response there (which is understandable,
it is a busy time...) so looping the -tip folks in now, just to make
sure it does not get lost (apologies if this is noise).

1911 is still being investigated (some additional eyes on it would not
hurt).

[1]: https://git.kernel.org/tip/cbe8ded48b939b9d55d2c5589ab56caa7b530709
[2]: https://git.kernel.org/tip/973ab2d61f33dc85212c486e624af348c4eeb5c9
[3]: https://github.com/ClangBuiltLinux/linux/commit/150c42407f87463c27a2459e06845965291d9973

> As far as I can see none of those problems has been fixed in the upstream kernel.

Indeed, embargos are fun... :)

Cheers,
Nathan

^ permalink raw reply	[relevance 93%]

* Re: [PATCH 6.1 000/127] 6.1.45-rc1 review
  @ 2023-08-11  3:36 99%   ` Nathan Chancellor
    1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-11  3:36 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, clang-built-linux, stable, patches,
	linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
	pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow,
	conor, Nick Desaulniers, Sven Volkinsfeld, Daniel Kolesa

On Fri, Aug 11, 2023 at 08:52:01AM +0530, Naresh Kamboju wrote:
> Build errors:
> -----
> ld.lld: error: ./arch/x86/kernel/vmlinux.lds:193: at least one side of
> the expression must be absolute
> make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
> 
> 
>   Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> upstream report:
> -----
>     - https://lore.kernel.org/llvm/CA+G9fYsdUeNu-gwbs0+T6XHi4hYYk=Y9725-wFhZ7gJMspLDRA@mail.gmail.com/
> 
> Proposed fix patch:
> -----
>   [PATCH] x86/srso: fix build breakage for LD=ld.lld
>   - https://lore.kernel.org/lkml/20230809-gds-v1-1-eaac90b0cbcc@google.com/T/
> 
> This patch is yet to be backported and CC to stable.

It's now in -tip, I would expect it to make -rc6:

https://git.kernel.org/tip/cbe8ded48b939b9d55d2c5589ab56caa7b530709

It should have had 'Cc: stable@vger.kernel.org' but I hope the Fixes:
tag alone will ensure it gets picked up once it hits mainline,
especially since there are other fixes that will come in that pull.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of the expression must be absolute
  @ 2023-08-09 15:53 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-09 15:53 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Naresh Kamboju, linux-stable, clang-built-linux,
	Greg Kroah-Hartman, Sasha Levin, Anders Roxell, Arnd Bergmann,
	Borislav Petkov, Peter Zijlstra

On Wed, Aug 09, 2023 at 08:47:08AM -0700, Nick Desaulniers wrote:
> Thanks for the report. We're tracking this here
> https://github.com/ClangBuiltLinux/linux/issues/1907
> It was pointed out that PeterZ has a series reworking this code entirely:
> https://lore.kernel.org/lkml/20230809071218.000335006@infradead.org/

As I pointed out in that issue, I don't think that series helps us with
this issue but I will try to test shortly (the patches did not apply
cleanly but I have not looked into why yet).

> On Tue, Aug 8, 2023 at 11:25 PM Naresh Kamboju
> <naresh.kamboju@linaro.org> wrote:
> >
> > also noticed on stable-rc 5.15 and 5.10.
> 
> That's troubling if stable is already picking up patches that are
> breaking the build!

Those patches are already released in stable, they were basically
released at the same time as they were merged into mainline:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.4.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.1.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.15.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y

Cheers,
Nathan

> > On Wed, 9 Aug 2023 at 11:40, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > >
> > > While building Linux stable rc 6.1 x86_64 with clang-17 failed due to
> > > following warnings / errors.
> > >
> > > make --silent --keep-going --jobs=8
> > > O=/home/tuxbuild/.cache/tuxmake/builds/2/build ARCH=x86_64 SRCARCH=x86
> > > CROSS_COMPILE=x86_64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> > > clang' LLVM=1 LLVM_IAS=1
> > >
> > > arch/x86/lib/retpoline.o: warning: objtool: .altinstr_replacement:
> > > unexpected end of section
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
> > > the expression must be absolute
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
> > > the expression must be absolute
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
> > > the expression must be absolute
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
> > > the expression must be absolute
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of
> > > the expression must be absolute
> > > ld.lld: error: ./arch/x86/kernel/vmlinux.lds:192: at least one side of
> > > the expression must be absolute
> > > make[2]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > > make[2]: Target '__default' not remade because of errors.
> > > make[1]: *** [Makefile:1255: vmlinux] Error 2
> > >
> > >
> > > Build links,
> > >  - https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4fakgeTfw/
> > >  - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.44-117-g74848b090997/testrun/18917095/suite/build/test/clang-lkftconfig/details/
> > >  - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.44-117-g74848b090997/testrun/18917095/suite/build/test/clang-lkftconfig/history/
> > >
> > > Steps to reproduce:
> > >   tuxmake --runtime podman --target-arch x86_64 --toolchain clang-17
> > > --kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4fakgeTfw/config
> > > LLVM=1 LLVM_IAS=1
> > >   https://storage.tuxsuite.com/public/linaro/lkft/builds/2TiTUgExGs7SrTm9Lb4fakgeTfw/tuxmake_reproducer.sh
> > >
> > >
> > > --
> > > Linaro LKFT
> > > https://lkft.linaro.org
> 
> 
> 
> -- 
> Thanks,
> ~Nick Desaulniers

^ permalink raw reply	[relevance 99%]

* Re: stable-rc 5.15: clang-17: davinci_all_defconfig failed - arch/arm/include/asm/tlbflush.h:420:85: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand]
  @ 2023-08-08 15:13 98% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-08 15:13 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: clang-built-linux, linux-stable, lkft-triage, Greg Kroah-Hartman,
	Sasha Levin, Nick Desaulniers, Arnd Bergmann, Anders Roxell

Hi Naresh,

On Tue, Aug 08, 2023 at 11:52:12AM +0530, Naresh Kamboju wrote:
> LKFT build plans upgraded to clang-17 and found this failure,
> 
> While building stable-rc 5.15 arm davinci_all_defconfig with clang-17 failed
> with below warnings and errors.
> 
> Build log:
> ----------
> 
> arch/arm/include/asm/tlbflush.h:420:85: error: use of logical '&&'
> with constant operand [-Werror,-Wconstant-logical-operand]
>   420 |         if (possible_tlb_flags &
> (TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
>       |
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ^
> arch/arm/include/asm/tlbflush.h:420:85: note: use '&' for a bitwise operation
>   420 |         if (possible_tlb_flags &
> (TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
>       |
>                             ^~
>       |
>                             &

Thanks for the report. This is "fixed" in mainline with commit
cb32c285cc10 ("cpumask: change return types to bool where appropriate"),
which causes the warning not to fire because the right hand side is a
boolean, rather than an integer. That change picks cleanly back to at
least 5.4 with commit 1dc01abad654 ("cpumask: Always inline helpers
which use bit manipulation functions") applied before it.

However, the change to -Wconstant-logical-operand in clang that causes
this in the first place is being reverted in both clang-18 and clang-17,
so this will disappear shortly:

https://github.com/llvm/llvm-project/commit/a84525233776a716e2c6291993f0b33fd1c76f7c
https://github.com/llvm/llvm-project/issues/64515

There is some discussion about the warning coming back and the suggested
change to the warning does not seem like it fix this instance so
applying those couple of changes may not be a bad idea anyways:

https://github.com/llvm/llvm-project/issues/64356

Cheers,
Nathan

^ permalink raw reply	[relevance 98%]

* Re: [PATCH] cpufreq: amd-pstate: fix global sysfs attribute type
  @ 2023-08-07 16:06 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-08-07 16:06 UTC (permalink / raw)
  To: Thomas Weißschuh
  Cc: Huang Rui, Rafael J. Wysocki, Viresh Kumar, linux-pm,
	linux-kernel, Jannik Glueckert, Bagas Sanjaya,
	Linux LLVM Build Support, Nick Desaulniers, Greg Kroah-Hartman,
	stable

Hi Thomas,

On Mon, Aug 07, 2023 at 08:37:45AM +0200, Thomas Weißschuh wrote:
> In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")
> the "amd_pstate" attributes where moved from a dedicated kobject to the
> cpu root kobject.
> While the dedicated kobject expects to contain kobj_attributes the root
> kobject needs device_attributes.
> 
> As the changed arguments are not used by the callbacks it works most of
> the time.
> However CFI will detect this issue:
> 
> [ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)
> ...
> [ 4947.849409] Call Trace:
> [ 4947.849410]  <TASK>
> [ 4947.849411]  ? __warn+0xcf/0x1c0
> [ 4947.849414]  ? dev_attr_show+0x24/0x60
> [ 4947.849415]  ? report_cfi_failure+0x4e/0x60
> [ 4947.849417]  ? handle_cfi_failure+0x14c/0x1d0
> [ 4947.849419]  ? __cfi_show_status+0x10/0x10
> [ 4947.849420]  ? handle_bug+0x4f/0x90
> [ 4947.849421]  ? exc_invalid_op+0x1a/0x60
> [ 4947.849422]  ? asm_exc_invalid_op+0x1a/0x20
> [ 4947.849424]  ? __cfi_show_status+0x10/0x10
> [ 4947.849425]  ? dev_attr_show+0x24/0x60
> [ 4947.849426]  sysfs_kf_seq_show+0xa6/0x110
> [ 4947.849433]  seq_read_iter+0x16c/0x4b0
> [ 4947.849436]  vfs_read+0x272/0x2d0
> [ 4947.849438]  ksys_read+0x72/0xe0
> [ 4947.849439]  do_syscall_64+0x76/0xb0
> [ 4947.849440]  ? do_user_addr_fault+0x252/0x650
> [ 4947.849442]  ? exc_page_fault+0x7a/0x1b0
> [ 4947.849443]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
> 
> Reported-by: Jannik Glückert <jannik.glueckert@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217765
> Link: https://lore.kernel.org/lkml/c7f1bf9b-b183-bf6e-1cbb-d43f72494083@gmail.com/
> Fixes: 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>

Thanks a lot for the quick patch! Unfortunately, it seems like neither
of my AMD machines support amd-pstate so I can't test this but it seems
like the right fix to me.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
> Note:
> 
> This was not tested with CFI as I don't have the toolchain available.

For the record, I have LLVM toolchains on kernel.org that should be
relatively standalone enough to have them somewhere on your hard drive
then use the LLVM=<prefix>/bin/ syntax that has been supported since
5.18:

https://mirrors.edge.kernel.org/pub/tools/llvm/

> Jannik, could you give it a spin?
> ---
>  drivers/cpufreq/amd-pstate.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 81fba0dcbee9..9a1e194d5cf8 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -1012,8 +1012,8 @@ static int amd_pstate_update_status(const char *buf, size_t size)
>  	return 0;
>  }
>  
> -static ssize_t show_status(struct kobject *kobj,
> -			   struct kobj_attribute *attr, char *buf)
> +static ssize_t status_show(struct device *dev,
> +			   struct device_attribute *attr, char *buf)
>  {
>  	ssize_t ret;
>  
> @@ -1024,7 +1024,7 @@ static ssize_t show_status(struct kobject *kobj,
>  	return ret;
>  }
>  
> -static ssize_t store_status(struct kobject *a, struct kobj_attribute *b,
> +static ssize_t status_store(struct device *a, struct device_attribute *b,
>  			    const char *buf, size_t count)
>  {
>  	char *p = memchr(buf, '\n', count);
> @@ -1043,7 +1043,7 @@ cpufreq_freq_attr_ro(amd_pstate_lowest_nonlinear_freq);
>  cpufreq_freq_attr_ro(amd_pstate_highest_perf);
>  cpufreq_freq_attr_rw(energy_performance_preference);
>  cpufreq_freq_attr_ro(energy_performance_available_preferences);
> -define_one_global_rw(status);
> +static DEVICE_ATTR_RW(status);
>  
>  static struct freq_attr *amd_pstate_attr[] = {
>  	&amd_pstate_max_freq,
> @@ -1062,7 +1062,7 @@ static struct freq_attr *amd_pstate_epp_attr[] = {
>  };
>  
>  static struct attribute *pstate_global_attributes[] = {
> -	&status.attr,
> +	&dev_attr_status.attr,
>  	NULL
>  };
>  
> 
> ---
> base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f
> change-id: 20230807-amd-pstate-cfi-8302498c54f5
> 
> Best regards,
> -- 
> Thomas Weißschuh <linux@weissschuh.net>
> 

^ permalink raw reply	[relevance 99%]

* [PATCH v2] lib: test_scanf: Add explicit type cast to result initialization in test_number_prefix()
@ 2023-08-07 15:36 92% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-08-07 15:36 UTC (permalink / raw)
  To: pmladek, rostedt
  Cc: senozhatsky, andriy.shevchenko, linux, ndesaulniers, trix,
	linux-kernel, llvm, patches, stable, Nathan Chancellor

A recent change in clang allows it to consider more expressions as
compile time constants, which causes it to point out an implicit
conversion in the scanf tests:

  lib/test_scanf.c:661:2: warning: implicit conversion from 'int' to 'unsigned char' changes value from -168 to 88 [-Wconstant-conversion]
    661 |         test_number_prefix(unsigned char,       "0xA7", "%2hhx%hhx", 0, 0xa7, 2, check_uchar);
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  lib/test_scanf.c:609:29: note: expanded from macro 'test_number_prefix'
    609 |         T result[2] = {~expect[0], ~expect[1]};                                 \
        |                       ~            ^~~~~~~~~~
  1 warning generated.

The result of the bitwise negation is the type of the operand after
going through the integer promotion rules, so this truncation is
expected but harmless, as the initial values in the result array get
overwritten by _test() anyways. Add an explicit cast to the expected
type in test_number_prefix() to silence the warning. There is no
functional change, as all the tests still pass with GCC 13.1.0 and clang
18.0.0.

Cc: stable@vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1899
Link: https://github.com/llvm/llvm-project/commit/610ec954e1f81c0e8fcadedcd25afe643f5a094e
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Changes in v2:
- Add spaces in initializer to match result (Andy)
- Add 'Cc: stable', as builds with CONFIG_WERROR will be broken, such as
  allmodconfig
- Link to v1: https://lore.kernel.org/r/20230803-test_scanf-wconstant-conversion-v1-1-74da994dedbc@kernel.org
---
 lib/test_scanf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_scanf.c b/lib/test_scanf.c
index b620cf7de503..a2707af2951a 100644
--- a/lib/test_scanf.c
+++ b/lib/test_scanf.c
@@ -606,7 +606,7 @@ static void __init numbers_slice(void)
 #define test_number_prefix(T, str, scan_fmt, expect0, expect1, n_args, fn)	\
 do {										\
 	const T expect[2] = { expect0, expect1 };				\
-	T result[2] = {~expect[0], ~expect[1]};					\
+	T result[2] = { (T)~expect[0], (T)~expect[1] };				\
 										\
 	_test(fn, &expect, str, scan_fmt, n_args, &result[0], &result[1]);	\
 } while (0)

---
base-commit: 5d0c230f1de8c7515b6567d9afba1f196fb4e2f4
change-id: 20230803-test_scanf-wconstant-conversion-d97efbf3bb5d

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 92%]

* Re: [PATCH] kbuild: rust: avoid creating temporary files
  @ 2023-07-18 16:43 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-07-18 16:43 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Masahiro Yamada, Wedson Almeida Filho, Alex Gaynor,
	Nick Desaulniers, Nicolas Schier, Boqun Feng, Gary Guo,
	Björn Roy Baron, Benno Lossin, Alice Ryhl, Andreas Hindborg,
	linux-kbuild, rust-for-linux, linux-kernel, patches,
	Raphael Nestler, Andrea Righi, stable

On Tue, Jul 18, 2023 at 07:52:35AM +0200, Miguel Ojeda wrote:
> `rustc` outputs by default the temporary files (i.e. the ones saved
> by `-Csave-temps`, such as `*.rcgu*` files) in the current working
> directory when `-o` and `--out-dir` are not given (even if
> `--emit=x=path` is given, i.e. it does not use those for temporaries).
> 
> Since out-of-tree modules are compiled from the `linux` tree,
> `rustc` then tries to create them there, which may not be accessible.
> 
> Thus pass `--out-dir` explicitly, even if it is just for the temporary
> files.
> 
> Reported-by: Raphael Nestler <raphael.nestler@gmail.com>
> Closes: https://github.com/Rust-for-Linux/linux/issues/1015
> Reported-by: Andrea Righi <andrea.righi@canonical.com>
> Tested-by: Raphael Nestler <raphael.nestler@gmail.com>
> Tested-by: Andrea Righi <andrea.righi@canonical.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Seems reasonable to me.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  scripts/Makefile.build | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 6413342a03f4..82e3fb19fdaf 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -264,6 +264,9 @@ $(obj)/%.lst: $(src)/%.c FORCE
>  
>  rust_allowed_features := new_uninit
>  
> +# `--out-dir` is required to avoid temporaries being created by `rustc` in the
> +# current working directory, which may be not accessible in the out-of-tree
> +# modules case.
>  rust_common_cmd = \
>  	RUST_MODFILE=$(modfile) $(RUSTC_OR_CLIPPY) $(rust_flags) \
>  	-Zallow-features=$(rust_allowed_features) \
> @@ -272,7 +275,7 @@ rust_common_cmd = \
>  	--extern alloc --extern kernel \
>  	--crate-type rlib -L $(objtree)/rust/ \
>  	--crate-name $(basename $(notdir $@)) \
> -	--emit=dep-info=$(depfile)
> +	--out-dir $(dir $@) --emit=dep-info=$(depfile)
>  
>  # `--emit=obj`, `--emit=asm` and `--emit=llvm-ir` imply a single codegen unit
>  # will be used. We explicitly request `-Ccodegen-units=1` in any case, and
> 
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
> -- 
> 2.41.0
> 

^ permalink raw reply	[relevance 99%]

* Re: stable-rc 6.1: x86: clang build failed - block/blk-cgroup.c:1237:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true
  @ 2023-07-17 13:24 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-07-17 13:24 UTC (permalink / raw)
  To: Naresh Kamboju, Greg Kroah-Hartman, Sasha Levin
  Cc: linux-stable, open list, clang-built-linux, lkft-triage,
	Nick Desaulniers, Anders Roxell

On Mon, Jul 17, 2023 at 12:55:42AM +0530, Naresh Kamboju wrote:
> Linux stable-rc 6.1 build failed x86 and i386 with clang.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Build log:
> -----------
> block/blk-cgroup.c:1237:6: error: variable 'ret' is used uninitialized
> whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
>         if (init_blkcg_llists(blkcg))
>             ^~~~~~~~~~~~~~~~~~~~~~~~
> block/blk-cgroup.c:1287:9: note: uninitialized use occurs here
>         return ret;
>                ^~~
> block/blk-cgroup.c:1237:2: note: remove the 'if' if its condition is
> always false
>         if (init_blkcg_llists(blkcg))
>         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> block/blk-cgroup.c:1222:33: note: initialize the variable 'ret' to
> silence this warning
>         struct cgroup_subsys_state *ret;
>                                        ^
>                                         = NULL
> 1 error generated.
> 
> Links,
>  - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y-sanity/build/v6.1.38-599-g5071846d06ef/testrun/18327562/suite/build/test/clang-lkftconfig/history/
>  - https://storage.tuxsuite.com/public/linaro/lkft/builds/2SfFoWj9NmKWHRijR0hcoXGjLhr/
> 
>  tuxmake \
>  --runtime podman --target-arch x86_64 \
>  --toolchain clang-16 \
>  --kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2SfFoWj9NmKWHRijR0hcoXGjLhr/config
> \
>  LLVM=1 LLVM_IAS=1
> 

It looks like 6.1 needs commit b5a9adcbd5dc ("blk-cgroup: Return -ENOMEM
directly in blkcg_css_alloc() error path") if it wants to take commit
3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()").

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [RFC PATCH 0/2] x86: kprobes: Fix CFI_CLANG related issues
       [not found]       ` <20230711103303.287af608cc47dcf70d709070@kernel.org>
@ 2023-07-11 18:37 96%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-07-11 18:37 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Peter Zijlstra, Petr Pavlu, tglx, mingo, bp, dave.hansen, hpa,
	samitolvanen, x86, linux-trace-kernel, linux-kernel, llvm,
	ndesaulniers, Masami Hiramatsu, stable

Masami, thanks for verifying!

Hi Greg and Sasha,

On Tue, Jul 11, 2023 at 10:33:03AM +0900, Masami Hiramatsu wrote:
> On Mon, 10 Jul 2023 08:57:03 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
> 
> > On Mon, Jul 10, 2023 at 09:14:13PM +0900, Masami Hiramatsu (Google) wrote:
> > > I just build tested, since I could not boot the kernel with CFI_CLANG=y.
> > > Would anyone know something about this error?
> > > 
> > > [    0.141030] MMIO Stale Data: Unknown: No mitigations
> > > [    0.153511] SMP alternatives: Using kCFI
> > > [    0.164593] Freeing SMP alternatives memory: 36K
> > > [    0.165053] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: start_kernel+0x472/0x48b
> > > [    0.166028] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.2-00002-g12b1b2fca8ef #126
> > > [    0.166028] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> > > [    0.166028] Call Trace:
> > > [    0.166028]  <TASK>
> > > [    0.166028]  dump_stack_lvl+0x6e/0xb0
> > > [    0.166028]  panic+0x146/0x2f0
> > > [    0.166028]  ? start_kernel+0x472/0x48b
> > > [    0.166028]  __stack_chk_fail+0x14/0x20
> > > [    0.166028]  start_kernel+0x472/0x48b
> > > [    0.166028]  x86_64_start_reservations+0x24/0x30
> > > [    0.166028]  x86_64_start_kernel+0xa6/0xbb
> > > [    0.166028]  secondary_startup_64_no_verify+0x106/0x11b
> > > [    0.166028]  </TASK>
> > > [    0.166028] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: start_kernel+0x472/0x48b ]---
> > 
> > This looks like https://github.com/ClangBuiltLinux/linux/issues/1815 to
> > me. What version of LLVM are you using? This was fixed in 16.0.4. Commit
> > 514ca14ed544 ("start_kernel: Add __no_stack_protector function
> > attribute") should resolve it on the Linux side, it looks like that is
> > in 6.5-rc1. Not sure if we should backport it or just let people upgrade
> > their toolchains on older releases.
> 
> Thanks for the info. I confirmed that the commit fixed the boot issue.
> So I think it should be backported to the stable tree.

Would you please apply commit 514ca14ed544 ("start_kernel: Add
__no_stack_protector function attribute") to linux-6.4.y? The series
ending with commit 611d4c716db0 ("x86/hyperv: Mark hv_ghcb_terminate()
as noreturn") that shipped in 6.4 exposes an LLVM issue that affected
16.0.0 and 16.0.1, which was resolved in 16.0.2. When using those
affected LLVM releases, the following crash at boot occurs:

  [    0.181667] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: start_kernel+0x3cf/0x3d0
  [    0.182621] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.3 #1
  [    0.182621] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
  [    0.182621] Call Trace:
  [    0.182621]  <TASK>
  [    0.182621]  dump_stack_lvl+0x6a/0xa0
  [    0.182621]  panic+0x124/0x2f0
  [    0.182621]  ? start_kernel+0x3cf/0x3d0
  [    0.182621]  ? acpi_enable+0x64/0xc0
  [    0.182621]  __stack_chk_fail+0x14/0x20
  [    0.182621]  start_kernel+0x3cf/0x3d0
  [    0.182621]  x86_64_start_reservations+0x24/0x30
  [    0.182621]  x86_64_start_kernel+0xab/0xb0
  [    0.182621]  secondary_startup_64_no_verify+0x107/0x10b
  [    0.182621]  </TASK>
  [    0.182621] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: start_kernel+0x3cf/0x3d0 ]---

514ca14ed544 aims to avoid this on the Linux side. I have verified that
it applies to 6.4.3 cleanly and resolves the issue there, as has Masami.

If there are any issues or questions, please let me know.

Cheers,
Nathan

^ permalink raw reply	[relevance 96%]

* [PATCH] ASoC: cs35l45: Select REGMAP_IRQ
@ 2023-07-03 21:43 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-07-03 21:43 UTC (permalink / raw)
  To: broonie
  Cc: lgirdwood, vkarpovi, rf, ckeepax, alsa-devel, patches, stable,
	Marcus Seyfarth, Nathan Chancellor

After commit 6085f9e6dc19 ("ASoC: cs35l45: IRQ support"), without any
other configuration that selects CONFIG_REGMAP_IRQ, modpost errors out
with:

  ERROR: modpost: "regmap_irq_get_virq" [sound/soc/codecs/snd-soc-cs35l45.ko] undefined!
  ERROR: modpost: "devm_regmap_add_irq_chip" [sound/soc/codecs/snd-soc-cs35l45.ko] undefined!

Add the Kconfig selection to ensure these functions get built and
included, which resolves the build failure.

Cc: stable@vger.kernel.org
Fixes: 6085f9e6dc19 ("ASoC: cs35l45: IRQ support")
Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/1882
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 sound/soc/codecs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 0cd107fa112f..76ddd3ffc496 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -715,6 +715,7 @@ config SND_SOC_CS35L41_I2C
 
 config SND_SOC_CS35L45
 	tristate
+	select REGMAP_IRQ
 
 config SND_SOC_CS35L45_SPI
 	tristate "Cirrus Logic CS35L45 CODEC (SPI)"

---
base-commit: 6f49256897083848ce9a59651f6b53fc80462397
change-id: 20230703-cs35l45-select-regmap_irq-0fd9d631763c

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 99%]

* Apply clang '--target=' KBUILD_CPPFLAGS shuffle to linux-6.4.y and linux-6.3.y
@ 2023-07-03 15:03 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-07-03 15:03 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, Masahiro Yamada, Nick Desaulniers

Hi Greg and Sasha,

Please consider applying the following patches to 6.4 and 6.3, they
should apply cleanly.

08f6554ff90e ("mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation")
a7e5eb53bf9b ("powerpc/vdso: Include CLANG_FLAGS explicitly in ldflags-y")
cff6e7f50bd3 ("kbuild: Add CLANG_FLAGS to as-instr")
43fc0a99906e ("kbuild: Add KBUILD_CPPFLAGS to as-option invocation")
feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")

They resolve and help avoid build breakage with tip of tree clang, which
has become a little stricter in the flags that it will accept for a
particular target, which requires '--target=' to be passed along to all
invocations of $(CC). Our continuous integration does not currently show
any breakage with 6.1 and earlier; should these patches be needed there,
I will send them at a later time.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH V2] MIPS: Loongson: Fix build error when make modules_install
  @ 2023-06-28 15:22 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-28 15:22 UTC (permalink / raw)
  To: Huacai Chen
  Cc: Thomas Bogendoerfer, Huacai Chen, linux-mips, Jiaxun Yang,
	stable, Feiyang Chen, Nick Desaulniers

On Wed, Jun 28, 2023 at 07:08:47PM +0800, Huacai Chen wrote:
> After commit 0e96ea5c3eb5904e5dc2f ("MIPS: Loongson64: Clean up use of
> cc-ifversion") we get a build error when make modules_install:
> 
> cc1: error: '-mloongson-mmi' must be used with '-mhard-float'
> 
> The reason is when make modules_install, 'call cc-option' doesn't work
> in $(KBUILD_CFLAGS) of 'CHECKFLAGS'. Then there is no -mno-loongson-mmi
> applied and -march=loongson3a enable MMI instructions.
> 
> To be detail, the error message comes from the CHECKFLAGS invocation of
> $(CC) but it has no impact on the final result of make modules_install,
> it is purely a cosmetic issue. The error occurs because cc-option is
> defined in scripts/Makefile.compiler, which is not included in Makefile
> when running 'make modules_install', as install targets are not supposed
> to require the compiler; see commit 805b2e1d427aab4b ("kbuild: include
> Makefile.compiler only when compiler is needed"). As a result, the call
> to check for '-mno-loongson-mmi' just never happens.
> 
> Fix this by partially reverting to the old logic, use 'call cc-option'
> to conditionally apply -march=loongson3a and -march=mips64r2.
> 
> By the way, Loongson-2E/2F is also broken in commit 13ceb48bc19c563e05f4
> ("MIPS: Loongson2ef: Remove unnecessary {as,cc}-option calls") so fix it
> together.
> 
> Fixes: 13ceb48bc19c563e05f4 ("MIPS: Loongson2ef: Remove unnecessary {as,cc}-option calls")
> Fixes: 0e96ea5c3eb5904e5dc2 ("MIPS: Loongson64: Clean up use of cc-ifversion")
> Cc: stable@vger.kernel.org
> Cc: Feiyang Chen <chenfeiyang@loongson.cn>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
> V2: Update commit message and fix for LOONGSON2EF together.
> 
>  arch/mips/Makefile | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index a7a4ee66a9d3..35a1b9b34734 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -181,16 +181,12 @@ endif
>  cflags-$(CONFIG_CAVIUM_CN63XXP1) += -Wa,-mfix-cn63xxp1
>  cflags-$(CONFIG_CPU_BMIPS)	+= -march=mips32 -Wa,-mips32 -Wa,--trap
>  
> -cflags-$(CONFIG_CPU_LOONGSON2E) += -march=loongson2e -Wa,--trap
> -cflags-$(CONFIG_CPU_LOONGSON2F) += -march=loongson2f -Wa,--trap
> +cflags-$(CONFIG_CPU_LOONGSON2E) += $(call cc-option,-march=loongson2e) -Wa,--trap
> +cflags-$(CONFIG_CPU_LOONGSON2F) += $(call cc-option,-march=loongson2f) -Wa,--trap
> +cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-march=loongson3a,-march=mips64r2) -Wa,--trap
>  # Some -march= flags enable MMI instructions, and GCC complains about that
>  # support being enabled alongside -msoft-float. Thus explicitly disable MMI.
>  cflags-$(CONFIG_CPU_LOONGSON2EF) += $(call cc-option,-mno-loongson-mmi)
> -ifdef CONFIG_CPU_LOONGSON64
> -cflags-$(CONFIG_CPU_LOONGSON64)	+= -Wa,--trap
> -cflags-$(CONFIG_CC_IS_GCC) += -march=loongson3a
> -cflags-$(CONFIG_CC_IS_CLANG) += -march=mips64r2
> -endif
>  cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-mno-loongson-mmi)
>  
>  cflags-$(CONFIG_CPU_R4000_WORKAROUNDS)	+= $(call cc-option,-mfix-r4000,)
> -- 
> 2.39.3
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] MIPS: Loongson: Fix build error when make modules_install
  @ 2023-06-27 21:28 93%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-27 21:28 UTC (permalink / raw)
  To: Huacai Chen
  Cc: Huacai Chen, Thomas Bogendoerfer, linux-mips, Jiaxun Yang,
	stable, Nick Desaulniers

Hi Huacai,

+ Masahiro

On Tue, Jun 27, 2023 at 11:11:27AM +0800, Huacai Chen wrote:
> Hi, Nathan,
> 
> On Tue, Jun 27, 2023 at 12:07 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Mon, Jun 26, 2023 at 03:50:47PM +0800, Huacai Chen wrote:
> > > After commit 0e96ea5c3eb5904e5dc2f ("MIPS: Loongson64: Clean up use of
> > > cc-ifversion") we get a build error when make modules_install:
> > >
> > > cc1: error: '-mloongson-mmi' must be used with '-mhard-float'
> > >
> > > The reason is when make modules_install, 'call cc-option' doesn't work
> > > in $(KBUILD_CFLAGS) of 'CHECKFLAGS'. Then there is no -mno-loongson-mmi
> > > applied and -march=loongson3a enable MMI instructions.
> >
> > The first sentence does not make much sense to me, specifically "in
> > $(KBUILD_CFLAGS) of 'CHECKFLAGS'". What configuration and build command
> > reproduces this? I do not see how '-mno-loongson-mmi' would fail to get
> > added to cflags-y after 0e96ea5c3eb5, which should have had no
> > functional change... I don't want to hang this change up since there is
> > real breakage but I want to make sure we fully understand why
> > 0e96ea5c3eb5 broke things and why this patch resolves it.
> Please use loongson3_defconfig to build a loongson kernel with
> toolchains from here [1]:
> 'make' will succeed, but there is a build error when 'make
> modules_install'. And you should be careful because 'make
> modules_install' doesn't stop when the error occurs.

Excellent, thank you! I understand what is going on here and your patch
should work to resolve it (although I think the commit message should be
flushed out a little more with the following details) but I am curious
if Masahiro has any thoughts around this.

As you note, the error message comes from the CHECKFLAGS invocation of
$(CC) but it has no impact on the final result of modules_install, it is
purely a cosmetic issue from what I can tell. The error occurs because
cc-option is defined in scripts/Makefile.compiler, which is not included
in Makefile when running modules_install, as install targets are not
supposed to require the compiler; see commit 805b2e1d427a ("kbuild:
include Makefile.compiler only when compiler is needed"). As a result,
the call to check for '-mno-loongson-mmi' just never happens.

It would nice if '-mno-loongson-mmi' could be added unconditionally when
using GCC but I can see that the flag has only existed since 9.x, so we
do need to keep the cc-option call.

I am fine with your change as long as it includes some of the above
information (basically noting that while the original change should have
been equivalent, the requirement of '-mno-loongson-mmi' when using
certain Loongson '-march=' values with '-msoft-float' means that those
Loongson '-march=' values need to be called with cc-option as well),
even if clang will incur two more cc-option calls as a result (not the
end of the world).

Additionally, it seems like the same issue will occur when running
modules_install when CONFIG_CPU_LOONGSON2E or CONFIG_CPU_LOONGSON2F are
enabled, which I guess I also broke in commit 13ceb48bc19c ("MIPS:
Loongson2ef: Remove unnecessary {as,cc}-option calls") :/

Sorry again for the breakage and thanks for the fix!

Cheers,
Nathan

> > > Fix this by partially reverting to the old logic, use 'call cc-option'
> > > to conditionally apply -march=loongson3a and -march=mips64r2.
> > >
> > > Fixes: 0e96ea5c3eb5904e5dc2f ("MIPS: Loongson64: Clean up use of cc-ifversion")
> > > Cc: stable@vger.kernel.org
> > > Cc: Nathan Chancellor <nathan@kernel.org>
> > > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > ---
> > >  arch/mips/Makefile | 5 +----
> > >  1 file changed, 1 insertion(+), 4 deletions(-)
> > >
> > > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > > index a7a4ee66a9d3..7fb76d12829e 100644
> > > --- a/arch/mips/Makefile
> > > +++ b/arch/mips/Makefile
> > > @@ -186,11 +186,8 @@ cflags-$(CONFIG_CPU_LOONGSON2F) += -march=loongson2f -Wa,--trap
> > >  # Some -march= flags enable MMI instructions, and GCC complains about that
> > >  # support being enabled alongside -msoft-float. Thus explicitly disable MMI.
> > >  cflags-$(CONFIG_CPU_LOONGSON2EF) += $(call cc-option,-mno-loongson-mmi)
> > > -ifdef CONFIG_CPU_LOONGSON64
> > >  cflags-$(CONFIG_CPU_LOONGSON64)      += -Wa,--trap
> > > -cflags-$(CONFIG_CC_IS_GCC) += -march=loongson3a
> > > -cflags-$(CONFIG_CC_IS_CLANG) += -march=mips64r2
> > > -endif
> > > +cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-march=loongson3a,-march=mips64r2)
> > >  cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-mno-loongson-mmi)
> > >
> > >  cflags-$(CONFIG_CPU_R4000_WORKAROUNDS)       += $(call cc-option,-mfix-r4000,)
> > > --
> > > 2.39.3
> > >

^ permalink raw reply	[relevance 93%]

* Re: [PATCH] MIPS: Loongson: Fix build error when make modules_install
  @ 2023-06-26 16:07 99% ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-06-26 16:07 UTC (permalink / raw)
  To: Huacai Chen
  Cc: Thomas Bogendoerfer, Huacai Chen, linux-mips, Jiaxun Yang,
	stable, Nick Desaulniers

On Mon, Jun 26, 2023 at 03:50:47PM +0800, Huacai Chen wrote:
> After commit 0e96ea5c3eb5904e5dc2f ("MIPS: Loongson64: Clean up use of
> cc-ifversion") we get a build error when make modules_install:
> 
> cc1: error: '-mloongson-mmi' must be used with '-mhard-float'
> 
> The reason is when make modules_install, 'call cc-option' doesn't work
> in $(KBUILD_CFLAGS) of 'CHECKFLAGS'. Then there is no -mno-loongson-mmi
> applied and -march=loongson3a enable MMI instructions.

The first sentence does not make much sense to me, specifically "in
$(KBUILD_CFLAGS) of 'CHECKFLAGS'". What configuration and build command
reproduces this? I do not see how '-mno-loongson-mmi' would fail to get
added to cflags-y after 0e96ea5c3eb5, which should have had no
functional change... I don't want to hang this change up since there is
real breakage but I want to make sure we fully understand why
0e96ea5c3eb5 broke things and why this patch resolves it.

> Fix this by partially reverting to the old logic, use 'call cc-option'
> to conditionally apply -march=loongson3a and -march=mips64r2.
> 
> Fixes: 0e96ea5c3eb5904e5dc2f ("MIPS: Loongson64: Clean up use of cc-ifversion")
> Cc: stable@vger.kernel.org
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
>  arch/mips/Makefile | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index a7a4ee66a9d3..7fb76d12829e 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -186,11 +186,8 @@ cflags-$(CONFIG_CPU_LOONGSON2F) += -march=loongson2f -Wa,--trap
>  # Some -march= flags enable MMI instructions, and GCC complains about that
>  # support being enabled alongside -msoft-float. Thus explicitly disable MMI.
>  cflags-$(CONFIG_CPU_LOONGSON2EF) += $(call cc-option,-mno-loongson-mmi)
> -ifdef CONFIG_CPU_LOONGSON64
>  cflags-$(CONFIG_CPU_LOONGSON64)	+= -Wa,--trap
> -cflags-$(CONFIG_CC_IS_GCC) += -march=loongson3a
> -cflags-$(CONFIG_CC_IS_CLANG) += -march=mips64r2
> -endif
> +cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-march=loongson3a,-march=mips64r2)
>  cflags-$(CONFIG_CPU_LOONGSON64) += $(call cc-option,-mno-loongson-mmi)
>  
>  cflags-$(CONFIG_CPU_R4000_WORKAROUNDS)	+= $(call cc-option,-mfix-r4000,)
> -- 
> 2.39.3
> 

^ permalink raw reply	[relevance 99%]

* [PATCH 6.3] riscv: Link with '-z norelro'
@ 2023-06-20 17:44 95% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-20 17:44 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: palmer, conor, ndesaulniers, nathan, linux-riscv, stable, llvm,
	kernel test robot

This patch fixes a stable only patch, so it has no direct upstream
equivalent.

After a stable only patch to explicitly handle the '.got' section to
handle an orphan section warning from the linker, certain configurations
error when linking with ld.lld, which enables relro by default:

  ld.lld: error: section: .got is not contiguous with other relro sections

This has come up with other architectures before, such as arm and arm64
in commit 0cda9bc15dfc ("ARM: 9038/1: Link with '-z norelro'") and
commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
CONFIG_RELOCATABLE"). Additionally, '-z norelro' is used unconditionally
for RISC-V upstream after commit 26e7aacb83df ("riscv: Allow to
downgrade paging mode from the command line"), which alluded to this
issue for the same reason. Bring 6.3 in line with mainline and link with
'-z norelro', which resolves the above link failure.

Fixes: e6d1562dd4e9 ("riscv: vmlinux.lds.S: Explicitly handle '.got' section")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202306192231.DJmWr6BX-lkp@intel.com/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/riscv/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index b05e833a022d..d46b6722710f 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -7,7 +7,7 @@
 #
 
 OBJCOPYFLAGS    := -O binary
-LDFLAGS_vmlinux :=
+LDFLAGS_vmlinux := -z norelro
 ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
 	LDFLAGS_vmlinux := --no-relax
 	KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY

---
base-commit: f2427f9a3730e9a1a11b69f6b767f7f2fad87523
change-id: 20230620-6-3-fix-got-relro-error-lld-397f3112860b

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 95%]

* Re: clang: Powerpc: clang-nightly-maple_defconfig — FAIL
  @ 2023-06-14 18:07 99%       ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:07 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: clang-built-linux, open list, linux-stable, lkft-triage,
	Greg Kroah-Hartman, Sasha Levin, Nick Desaulniers, Anders Roxell,
	Daniel Díaz, Dan Carpenter

On Wed, Jun 14, 2023 at 07:43:45PM +0530, Naresh Kamboju wrote:
> Hi Nathan,
> 
> On Tue, 13 Jun 2023 at 09:57, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > Hi Nathan,
> >
> > On Tue, 13 Jun 2023 at 00:24, Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > Hi Naresh,
> > >
> > > On Tue, Jun 13, 2023 at 12:10:30AM +0530, Naresh Kamboju wrote:
> > > > [Please ignore if it is already reported]
> > > >
> > > > Following two builds failed on stable-rc 6.1.34-rc1.
> > > >
> > > >   - Powerpc: clang-nightly-maple_defconfig — FAIL
> > > >   - Powerpc: clang-nightly-cell_defconfig — FAIL
> > > >
> 
> > > As always, thanks for the report. This is an LLVM regression/change in
> > > behavior caused by [1], which can break as-option and as-instr on
> > > releases prior to commit d5c8d6e0fa61 ("kbuild: Update assembler calls
> > > to use proper flags and language target"), as unsupported flags for the
> > > current target ('-x') may be present (KBUILD_CFLAGS is used for these
> > > tests instead of KBUILD_AFLAGS). Inside try-run, the macro behind
> > > as-instr and as-option, I see
> > >
> > >   clang-17: error: unsupported option '-mno-prefixed' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-pcrel' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-altivec' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-vsx' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-mma' for target 'powerpc64le-linux-gnu'
> > >   clang-17: error: unsupported option '-mno-spe' for target 'powerpc64le-linux-gnu'
> > >
> > > This has come up recently elsewhere in PowerPC, see
> > > commit 2b694fc96fe3 ("powerpc/boot: Disable power10 features after
> > > BOOTAFLAGS assignment"). While I think it is dubious that clang errors
> > > on these flags for the assembler target, this is already fixed on the
> > > Linux side by using KBUILD_AFLAGS for these make macros.
> > >
> > > I am preparing a series of d5c8d6e0fa61 and its dependencies for 6.1 but
> > > I want to do sufficient build testing first, which is currently running
> > > for me. Would you be able to point your matrix to [2] to make sure
> > > everything works properly with both GCC and LLVM? It is a work in
> > > progress as the second patch in the stack needs a proper commit message
> > > but it is the diff I expect to ship so that it all that matters.
> >
> > We'll start building [2] with GCC and LLVM by using tuxplans and
> > get back to you.
> 
> LKFT has been configured to run GCC and LLVM in total 205 builds
> and all the builds have passed on your tree / branch [2]. You can find
> the list of builds including kselftest, perf, rcutorture, kunit, kmemleak
> and many more combinations and architectures.
> 
> I request you to review the list of builds results and test results on
> projects page [3] [4]. I do not find any regressions compared with
> mainline master as sanity testing.

Thanks a lot for testing!

> Do you think LKFT should build your tree / branch often ?
> We are happy to test anytime.

No, this is an exceptional circumstance, not the norm. If I need wider
testing done in the future, I will keep you all in mind :)

> Thanks Daniel and Anders for your work.
> 
> build_names: that got tested and all have passed.
> 

<snip>

Great! I sent along the 6.1 backports now:

https://lore.kernel.org/20230612-6-1-asssembler-target-llvm-17-v1-0-75605d553401@kernel.org/

Thanks again for testing and the report, cheers!
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH 6.1 4/4] kbuild: Update assembler calls to use proper flags and language target
  2023-06-14 18:04 92% [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS Nathan Chancellor
                   ` (2 preceding siblings ...)
  2023-06-14 18:04 93% ` [PATCH 6.1 3/4] MIPS: Prefer cc-option for additions to cflags Nathan Chancellor
@ 2023-06-14 18:04 83% ` Nathan Chancellor
  3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:04 UTC (permalink / raw)
  To: gregkh, sashal, ndesaulniers
  Cc: naresh.kamboju, stable, llvm, Masahiro Yamada, Nathan Chancellor,
	Linux Kernel Functional Testing, Anders Roxell

From: Nick Desaulniers <ndesaulniers@google.com>

commit d5c8d6e0fa61401a729e9eb6a9c7077b2d3aebb0 upstream.

as-instr uses KBUILD_AFLAGS, but as-option uses KBUILD_CFLAGS. This can
cause as-option to fail unexpectedly when CONFIG_WERROR is set, because
clang will emit -Werror,-Wunused-command-line-argument for various -m
and -f flags in KBUILD_CFLAGS for assembler sources.

Callers of as-option and as-instr should be adding flags to
KBUILD_AFLAGS / aflags-y, not KBUILD_CFLAGS / cflags-y. Use
KBUILD_AFLAGS in all macros to clear up the initial problem.

Unfortunately, -Wunused-command-line-argument can still be triggered
with clang by the presence of warning flags or macro definitions because
'-x assembler' is used, instead of '-x assembler-with-cpp', which will
consume these flags. Switch to '-x assembler-with-cpp' in places where
'-x assembler' is used, as the compiler is always used as the driver for
out of line assembler sources in the kernel.

Finally, add -Werror to these macros so that they behave consistently
whether or not CONFIG_WERROR is set.

[nathan: Reworded and expanded on problems in commit message
         Use '-x assembler-with-cpp' in a couple more places]

Link: https://github.com/ClangBuiltLinux/linux/issues/1699
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/Kconfig.include   | 2 +-
 scripts/Makefile.compiler | 8 ++++----
 scripts/as-version.sh     | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 274125307ebd..5a84b6443875 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -33,7 +33,7 @@ ld-option = $(success,$(LD) -v $(1))
 
 # $(as-instr,<instr>)
 # Return y if the assembler supports <instr>, n otherwise
-as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler -o /dev/null -)
+as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler-with-cpp -o /dev/null -)
 
 # check if $(CC) and $(LD) exist
 $(error-if,$(failure,command -v $(CC)),C compiler '$(CC)' not found)
diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
index 20d353dcabfb..158c57f2acfd 100644
--- a/scripts/Makefile.compiler
+++ b/scripts/Makefile.compiler
@@ -29,16 +29,16 @@ try-run = $(shell set -e;		\
 	fi)
 
 # as-option
-# Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,)
+# Usage: aflags-y += $(call as-option,-Wa$(comma)-isa=foo,)
 
 as-option = $(call try-run,\
-	$(CC) $(KBUILD_CFLAGS) $(1) -c -x assembler /dev/null -o "$$TMP",$(1),$(2))
+	$(CC) -Werror $(KBUILD_AFLAGS) $(1) -c -x assembler-with-cpp /dev/null -o "$$TMP",$(1),$(2))
 
 # as-instr
-# Usage: cflags-y += $(call as-instr,instr,option1,option2)
+# Usage: aflags-y += $(call as-instr,instr,option1,option2)
 
 as-instr = $(call try-run,\
-	printf "%b\n" "$(1)" | $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -,$(2),$(3))
+	printf "%b\n" "$(1)" | $(CC) -Werror $(KBUILD_AFLAGS) -c -x assembler-with-cpp -o "$$TMP" -,$(2),$(3))
 
 # __cc-option
 # Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586)
diff --git a/scripts/as-version.sh b/scripts/as-version.sh
index 1a21495e9ff0..af717476152d 100755
--- a/scripts/as-version.sh
+++ b/scripts/as-version.sh
@@ -45,7 +45,7 @@ orig_args="$@"
 # Get the first line of the --version output.
 IFS='
 '
-set -- $(LC_ALL=C "$@" -Wa,--version -c -x assembler /dev/null -o /dev/null 2>/dev/null)
+set -- $(LC_ALL=C "$@" -Wa,--version -c -x assembler-with-cpp /dev/null -o /dev/null 2>/dev/null)
 
 # Split the line on spaces.
 IFS=' '

-- 
2.41.0


^ permalink raw reply related	[relevance 83%]

* [PATCH 6.1 3/4] MIPS: Prefer cc-option for additions to cflags
  2023-06-14 18:04 92% [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS Nathan Chancellor
  2023-06-14 18:04 95% ` [PATCH 6.1 1/4] x86/boot/compressed: prefer cc-option for CFLAGS additions Nathan Chancellor
  2023-06-14 18:04 95% ` [PATCH 6.1 2/4] MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option Nathan Chancellor
@ 2023-06-14 18:04 93% ` Nathan Chancellor
  2023-06-14 18:04 83% ` [PATCH 6.1 4/4] kbuild: Update assembler calls to use proper flags and language target Nathan Chancellor
  3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:04 UTC (permalink / raw)
  To: gregkh, sashal, ndesaulniers
  Cc: naresh.kamboju, stable, llvm, Nathan Chancellor,
	Thomas Bogendoerfer, Philippe Mathieu-Daudé,
	Linux Kernel Functional Testing, Anders Roxell, Masahiro Yamada

commit 337ff6bb8960fdc128cabd264aaea3d42ca27a32 upstream.

A future change will switch as-option to use KBUILD_AFLAGS instead of
KBUILD_CFLAGS to allow clang to drop -Qunused-arguments, which may cause
issues if the flag being tested requires a flag previously added to
KBUILD_CFLAGS but not KBUILD_AFLAGS. Use cc-option for cflags additions
so that the flags are tested properly.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/Makefile             | 2 +-
 arch/mips/loongson2ef/Platform | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index de8d508f27af..85d3c3b4b7bd 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -152,7 +152,7 @@ cflags-y += -fno-stack-check
 #
 # Avoid this by explicitly disabling that assembler behaviour.
 #
-cflags-y += $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,)
+cflags-y += $(call cc-option,-Wa$(comma)-mno-fix-loongson3-llsc,)
 
 #
 # CPU-dependent compiler/assembler options for optimization.
diff --git a/arch/mips/loongson2ef/Platform b/arch/mips/loongson2ef/Platform
index eebabf9df6ac..c6f7a4b95997 100644
--- a/arch/mips/loongson2ef/Platform
+++ b/arch/mips/loongson2ef/Platform
@@ -25,7 +25,7 @@ cflags-$(CONFIG_CPU_LOONGSON2F) += -march=loongson2f
 # binutils does not merge support for the flag then we can revisit & remove
 # this later - for now it ensures vendor toolchains don't cause problems.
 #
-cflags-$(CONFIG_CPU_LOONGSON2EF)	+= $(call as-option,-Wa$(comma)-mno-fix-loongson3-llsc,)
+cflags-$(CONFIG_CPU_LOONGSON2EF)	+= $(call cc-option,-Wa$(comma)-mno-fix-loongson3-llsc,)
 
 # Enable the workarounds for Loongson2f
 ifdef CONFIG_CPU_LOONGSON2F_WORKAROUNDS

-- 
2.41.0


^ permalink raw reply related	[relevance 93%]

* [PATCH 6.1 2/4] MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option
  2023-06-14 18:04 92% [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS Nathan Chancellor
  2023-06-14 18:04 95% ` [PATCH 6.1 1/4] x86/boot/compressed: prefer cc-option for CFLAGS additions Nathan Chancellor
@ 2023-06-14 18:04 95% ` Nathan Chancellor
  2023-06-14 18:04 93% ` [PATCH 6.1 3/4] MIPS: Prefer cc-option for additions to cflags Nathan Chancellor
  2023-06-14 18:04 83% ` [PATCH 6.1 4/4] kbuild: Update assembler calls to use proper flags and language target Nathan Chancellor
  3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:04 UTC (permalink / raw)
  To: gregkh, sashal, ndesaulniers
  Cc: naresh.kamboju, stable, llvm, Nathan Chancellor, tsbogend, linux-mips

This patch is for linux-6.1.y and earlier, it has no direct mainline
equivalent.

In order to backport commit d5c8d6e0fa61 ("kbuild: Update assembler
calls to use proper flags and language target") to resolve a separate
issue regarding PowerPC, the problem noticed and fixed by
commit 80a20d2f8288 ("MIPS: Always use -Wa,-msoft-float and eliminate
GAS_HAS_SET_HARDFLOAT") needs to be addressed. Unfortunately, 6.1 and
earlier do not contain commit e4412739472b ("Documentation: raise
minimum supported version of binutils to 2.25"), so it cannot be assumed
that all supported versions of GNU as have support for -msoft-float.

In order to switch from KBUILD_CFLAGS to KBUILD_AFLAGS in as-option
without consequence, move the '-Wa,-msoft-float' check to cc-option,
including '$(cflags-y)' directly to avoid the issue mentioned in
commit 80a20d2f8288 ("MIPS: Always use -Wa,-msoft-float and eliminate
GAS_HAS_SET_HARDFLOAT").

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Cc: tsbogend@alpha.franken.de
Cc: linux-mips@vger.kernel.org
---
 arch/mips/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index b296e33f8e33..de8d508f27af 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -109,7 +109,7 @@ endif
 # (specifically newer than 2.24.51.20140728) we then also need to explicitly
 # set ".set hardfloat" in all files which manipulate floating point registers.
 #
-ifneq ($(call as-option,-Wa$(comma)-msoft-float,),)
+ifneq ($(call cc-option,$(cflags-y) -Wa$(comma)-msoft-float,),)
 	cflags-y		+= -DGAS_HAS_SET_HARDFLOAT -Wa,-msoft-float
 endif
 

-- 
2.41.0


^ permalink raw reply related	[relevance 95%]

* [PATCH 6.1 1/4] x86/boot/compressed: prefer cc-option for CFLAGS additions
  2023-06-14 18:04 92% [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS Nathan Chancellor
@ 2023-06-14 18:04 95% ` Nathan Chancellor
  2023-06-14 18:04 95% ` [PATCH 6.1 2/4] MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option Nathan Chancellor
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:04 UTC (permalink / raw)
  To: gregkh, sashal, ndesaulniers
  Cc: naresh.kamboju, stable, llvm, Masahiro Yamada, Nathan Chancellor,
	Linux Kernel Functional Testing, Anders Roxell

From: Nick Desaulniers <ndesaulniers@google.com>

commit 994f5f7816ff963f49269cfc97f63cb2e4edb84f upstream.

as-option tests new options using KBUILD_CFLAGS, which causes problems
when using as-option to update KBUILD_AFLAGS because many compiler
options are not valid assembler options.

This will be fixed in a follow up patch. Before doing so, move the
assembler test for -Wa,-mrelax-relocations=no from using as-option to
cc-option.

Link: https://lore.kernel.org/llvm/CAK7LNATcHt7GcXZ=jMszyH=+M_LC9Qr6yeAGRCBbE6xriLxtUQ@mail.gmail.com/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/x86/boot/compressed/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 3a261abb6d15..15b7b403a4bd 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -50,7 +50,7 @@ KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
 KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
 KBUILD_CFLAGS += -D__DISABLE_EXPORTS
 # Disable relocation relaxation in case the link is not PIE.
-KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no)
+KBUILD_CFLAGS += $(call cc-option,-Wa$(comma)-mrelax-relocations=no)
 KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
 
 # sev.c indirectly inludes inat-table.h which is generated during

-- 
2.41.0


^ permalink raw reply related	[relevance 95%]

* [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS
@ 2023-06-14 18:04 92% Nathan Chancellor
  2023-06-14 18:04 95% ` [PATCH 6.1 1/4] x86/boot/compressed: prefer cc-option for CFLAGS additions Nathan Chancellor
                   ` (3 more replies)
  0 siblings, 4 replies; 200+ results
From: Nathan Chancellor @ 2023-06-14 18:04 UTC (permalink / raw)
  To: gregkh, sashal, ndesaulniers
  Cc: naresh.kamboju, stable, llvm, Masahiro Yamada, Nathan Chancellor,
	Linux Kernel Functional Testing, Anders Roxell, tsbogend,
	linux-mips, Philippe Mathieu-Daudé

Hi all,

This series backports commit d5c8d6e0fa61 ("kbuild: Update assembler
calls to use proper flags and language target") to linux-6.1.y to
address a recent issue caused by a change in behavior in clang:

https://lore.kernel.org/CA+G9fYsJq0sPC+q6vLNKUgBqCGmmjDrfeP4R1-95Eu28FJRY_A@mail.gmail.com/
https://lore.kernel.org/20230612185424.GA2891387@dev-arch.thelio-3990X/

While that was not the original intention of the aforementioned change,
it ends up resolving the issue for the same reason, by not passing flags
that are not supported or necessary for the current language target
(KBUILD_CFLAGS for .c files and KBUILD_AFLAGS for .S files) when testing
flags for that language target.

All patches except the second one are direct backports from mainline.
The second patch is a stable specific patch because the upstream
solution could break stable due to the minimum supported version of
binutils in mainline being a newer version than 6.1 and earlier; it
chooses to do the more conservative fix, which was alluded to in the
changelog of the upstream commit.

For now, this is just a 6.1 issue. If the issue occurs in older
releases, I will send separate backports. If there are any issues or
objections to this series, please let me know.

Cheers,
Nathan

---
Nathan Chancellor (2):
      MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option
      MIPS: Prefer cc-option for additions to cflags

Nick Desaulniers (2):
      x86/boot/compressed: prefer cc-option for CFLAGS additions
      kbuild: Update assembler calls to use proper flags and language target

 arch/mips/Makefile                | 4 ++--
 arch/mips/loongson2ef/Platform    | 2 +-
 arch/x86/boot/compressed/Makefile | 2 +-
 scripts/Kconfig.include           | 2 +-
 scripts/Makefile.compiler         | 8 ++++----
 scripts/as-version.sh             | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)
---
base-commit: ca87e77a2ef8b298aa9f69658d5898e72ee450fe
change-id: 20230612-6-1-asssembler-target-llvm-17-3f8101fc008f

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply	[relevance 92%]

* Re: clang: Powerpc: clang-nightly-maple_defconfig — FAIL
  @ 2023-06-12 18:54 92% ` Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-06-12 18:54 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: clang-built-linux, open list, linux-stable, lkft-triage,
	Greg Kroah-Hartman, Sasha Levin, Nick Desaulniers

Hi Naresh,

On Tue, Jun 13, 2023 at 12:10:30AM +0530, Naresh Kamboju wrote:
> [Please ignore if it is already reported]
> 
> Following two builds failed on stable-rc 6.1.34-rc1.
> 
>   - Powerpc: clang-nightly-maple_defconfig — FAIL
>   - Powerpc: clang-nightly-cell_defconfig — FAIL
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=powerpc
> CROSS_COMPILE=powerpc64le-linux-gnu- HOSTCC=clang CC=clang LLVM=1
> LLVM_IAS=0 LD=powerpc64le-linux-gnu-ld
> 
> arch/powerpc/lib/copypage_power7.S: Assembler messages:
> arch/powerpc/lib/copypage_power7.S:34: Error: junk at end of line: `0b01000'
> arch/powerpc/lib/copypage_power7.S:35: Error: junk at end of line: `0b01010'
> arch/powerpc/lib/copypage_power7.S:37: Error: junk at end of line: `0b01000'
> arch/powerpc/lib/copypage_power7.S:38: Error: junk at end of line: `0b01010'
> arch/powerpc/lib/copypage_power7.S:40: Error: junk at end of line: `0b01010'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[4]: *** [scripts/Makefile.build:382:
> arch/powerpc/lib/copypage_power7.o] Error 1
> make[4]: Target 'arch/powerpc/lib/' not remade because of errors.
> make[3]: *** [scripts/Makefile.build:500: arch/powerpc/lib] Error 2
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:2959: Error: junk at end of line: `0b01010'
> arch/powerpc/kernel/exceptions-64s.S:2979: Error: junk at end of line: `0b01010'
> arch/powerpc/kernel/exceptions-64s.S:2994: Error: junk at end of line: `0b01010'
> arch/powerpc/kernel/exceptions-64s.S:3012: Error: junk at end of line: `0b01010'
> arch/powerpc/kernel/exceptions-64s.S:3032: Error: junk at end of line: `0b01010'
> arch/powerpc/kernel/exceptions-64s.S:3079: Error: junk at end of line: `0b01010'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[4]: *** [scripts/Makefile.build:382: arch/powerpc/kernel/head_64.o] Error 1
> arch/powerpc/kernel/entry_64.S: Assembler messages:
> arch/powerpc/kernel/entry_64.S:172: Error: junk at end of line: `0b01010'
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[4]: *** [scripts/Makefile.build:382:
> arch/powerpc/kernel/entry_64.o] Error 1
> make[4]: Target 'arch/powerpc/kernel/' not remade because of errors.
> make[3]: *** [scripts/Makefile.build:500: arch/powerpc/kernel] Error 2
> make[3]: Target 'arch/powerpc/' not remade because of errors.
> make[2]: *** [scripts/Makefile.build:500: arch/powerpc] Error 2
> make[2]: Target './' not remade because of errors.
> make[1]: *** [Makefile:2012: .] Error 2
> make[1]: Target '__all' not remade because of errors.
> make: *** [Makefile:238: __sub-make] Error 2
> make: Target '__all' not remade because of errors.

As always, thanks for the report. This is an LLVM regression/change in
behavior caused by [1], which can break as-option and as-instr on
releases prior to commit d5c8d6e0fa61 ("kbuild: Update assembler calls
to use proper flags and language target"), as unsupported flags for the
current target ('-x') may be present (KBUILD_CFLAGS is used for these
tests instead of KBUILD_AFLAGS). Inside try-run, the macro behind
as-instr and as-option, I see

  clang-17: error: unsupported option '-mno-prefixed' for target 'powerpc64le-linux-gnu'
  clang-17: error: unsupported option '-mno-pcrel' for target 'powerpc64le-linux-gnu'
  clang-17: error: unsupported option '-mno-altivec' for target 'powerpc64le-linux-gnu'
  clang-17: error: unsupported option '-mno-vsx' for target 'powerpc64le-linux-gnu'
  clang-17: error: unsupported option '-mno-mma' for target 'powerpc64le-linux-gnu'
  clang-17: error: unsupported option '-mno-spe' for target 'powerpc64le-linux-gnu'

This has come up recently elsewhere in PowerPC, see
commit 2b694fc96fe3 ("powerpc/boot: Disable power10 features after
BOOTAFLAGS assignment"). While I think it is dubious that clang errors
on these flags for the assembler target, this is already fixed on the
Linux side by using KBUILD_AFLAGS for these make macros.

I am preparing a series of d5c8d6e0fa61 and its dependencies for 6.1 but
I want to do sufficient build testing first, which is currently running
for me. Would you be able to point your matrix to [2] to make sure
everything works properly with both GCC and LLVM? It is a work in
progress as the second patch in the stack needs a proper commit message
but it is the diff I expect to ship so that it all that matters.

[1]: https://github.com/llvm/llvm-project/commit/5548843d692a92a7840f14002debc3cebcb3cdc3
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/log/?h=wip/b4/6-1-asssembler-target-llvm-17

Cheers,
Nathan

^ permalink raw reply	[relevance 92%]

* [PATCH 6.3] riscv: vmlinux.lds.S: Explicitly handle '.got' section
@ 2023-06-05 21:15 94% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-06-05 21:15 UTC (permalink / raw)
  To: gregkh, sashal, palmer, conor
  Cc: paul.walmsley, aou, ndesaulniers, trix, stable, linux-riscv,
	llvm, patches, Nathan Chancellor

This patch is for linux-6.3.y only, it has no direct mainline
equivalent.

LLVM 17 will now use the GOT for extern weak symbols when using the
medany model, which causes a linker orphan section warning on
linux-6.3.y:

  ld.lld: warning: <internal>:(.got) is being placed in '.got'

This is not an issue in mainline because handling of the .got section
was added by commit 39b33072941f ("riscv: Introduce CONFIG_RELOCATABLE")
and further extended by commit 26e7aacb83df ("riscv: Allow to downgrade
paging mode from the command line") in 6.4-rc1. Neither of these changes
are suitable for stable, so add explicit handling of the .got section in
a standalone change to align 6.3 and mainline, which addresses the
warning.

This is only an issue for 6.3 because commit f4b71bff8d85 ("riscv:
select ARCH_WANT_LD_ORPHAN_WARN for !XIP_KERNEL") landed in 6.3-rc1, so
earlier releases will not see this warning because it will not be
enabled.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1865
Link: https://github.com/llvm/llvm-project/commit/a178ba9fbd0a27057dc2fa4cb53c76caa013caac
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/riscv/kernel/vmlinux.lds.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index 53a8ad65b255..db56c38f0e19 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -129,6 +129,8 @@ SECTIONS
 		*(.sdata*)
 	}
 
+	.got : { *(.got*) }
+
 #ifdef CONFIG_EFI
 	.pecoff_edata_padding : { BYTE(0); . = ALIGN(PECOFF_FILE_ALIGNMENT); }
 	__pecoff_data_raw_size = ABSOLUTE(. - __pecoff_text_end);

---
base-commit: abfd9cf1c3d4d143a889b76af835078897e46c55
change-id: 20230605-6-3-riscv-got-orphan-warning-llvm-17-8c4b0b72282a

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 94%]

* [PATCH] powerpc/boot: Disable power10 features after BOOTAFLAGS assignment
@ 2023-04-27 19:34 90% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-04-27 19:34 UTC (permalink / raw)
  To: mpe
  Cc: npiggin, christophe.leroy, ndesaulniers, trix, linuxppc-dev,
	llvm, patches, stable, Nathan Chancellor

When building the boot wrapper assembly files with clang after
commit 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation
with CONFIG_POWER10_CPU"), the following warnings appear for each file
built:

  '-prefixed' is not a recognized feature for this target (ignoring feature)
  '-pcrel' is not a recognized feature for this target (ignoring feature)

While it is questionable whether or not LLVM should be emitting a
warning when passed negative versions of code generation flags when
building assembly files (since it does not emit a warning for the
altivec and vsx flags), it is easy enough to work around this by just
moving the disabled flags to BOOTCFLAGS after the assignment of
BOOTAFLAGS, so that they are not added when building assembly files.
Do so to silence the warnings.

Cc: stable@vger.kernel.org
Fixes: 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation with CONFIG_POWER10_CPU")
Link: https://github.com/ClangBuiltLinux/linux/issues/1839
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
I do not think that 648a1783fe25 is truly to blame for this but the
Fixes tag will help the stable team ensure that this change gets
backported with 648a1783fe25. This is the minimal fix for the problem
but the true fix is separating AFLAGS and CFLAGS, which should be done
by this in-flight series by Nick:

https://lore.kernel.org/20230426055848.402993-1-npiggin@gmail.com/
---
 arch/powerpc/boot/Makefile | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 85cde5bf04b7..771b79423bbc 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -34,8 +34,6 @@ endif
 
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
-		 $(call cc-option,-mno-prefixed) $(call cc-option,-mno-pcrel) \
-		 $(call cc-option,-mno-mma) \
 		 $(call cc-option,-mno-spe) $(call cc-option,-mspe=no) \
 		 -pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
 		 $(LINUXINCLUDE)
@@ -71,6 +69,10 @@ BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
 
 BOOTARFLAGS	:= -crD
 
+BOOTCFLAGS	+= $(call cc-option,-mno-prefixed) \
+		   $(call cc-option,-mno-pcrel) \
+		   $(call cc-option,-mno-mma)
+
 ifdef CONFIG_CC_IS_CLANG
 BOOTCFLAGS += $(CLANG_FLAGS)
 BOOTAFLAGS += $(CLANG_FLAGS)

---
base-commit: 169f8997968ab620d750d9a45e15c5288d498356
change-id: 20230427-remove-power10-args-from-boot-aflags-clang-268c43e8c1fc

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 90%]

* Re: [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y
  @ 2023-04-18 16:19 99%       ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-04-18 16:19 UTC (permalink / raw)
  To: Greg KH
  Cc: sashal, conor, stable, llvm, Masahiro Yamada, Nick Desaulniers,
	Conor Dooley, Palmer Dabbelt

On Tue, Apr 18, 2023 at 11:46:56AM +0200, Greg KH wrote:
> On Wed, Apr 12, 2023 at 08:17:06AM +0200, Greg KH wrote:
> > On Tue, Apr 11, 2023 at 09:20:01AM -0700, Nathan Chancellor wrote:
> > > Gentle ping, did this get lost?
> > 
> > Nope, just burried under a raft of other proposed backports.  It's still
> > in my review queue, will get to it eventually...
> 
> All now queued up, sorry for the delay.

Thanks a lot, I will take later over never :)

Cheers
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y
  2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
                   ` (3 preceding siblings ...)
  2023-03-29  0:08 77% ` [PATCH 5.10 4/4] riscv: Handle zicsr/zifencei issues between clang and binutils Nathan Chancellor
@ 2023-04-11 16:20 99% ` Nathan Chancellor
    4 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-04-11 16:20 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: conor, stable, llvm, Masahiro Yamada, Nick Desaulniers,
	Conor Dooley, Palmer Dabbelt

Gentle ping, did this get lost?

On Tue, Mar 28, 2023 at 05:08:28PM -0700, Nathan Chancellor wrote:
> Hi all,
> 
> This series is a backport of upstream commit e89c2e815e76 ("riscv:
> Handle zicsr/zifencei issues between clang and binutils") to
> linux-5.10.y, with the necessary machinery for CONFIG_AS_IS_GNU and
> CONFIG_AS_VERSION, which that commit requires.
> 
> While the middle two patches are not strictly necessary, they are good
> clean ups that ensure consistency with mainline. The first three changes
> are already present in 5.15, so there is no risk of a regression moving
> forward.
> 
> If there are any issues, please let me know.
> 
> NOTE: I am sending this series with 'b4 send', as that is what I am used
> to at this point. Please accept my apologies if this causes any issues.
> 
> ---
> Masahiro Yamada (2):
>       kbuild: check the minimum assembler version in Kconfig
>       kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS
> 
> Nathan Chancellor (2):
>       kbuild: Switch to 'f' variants of integrated assembler flag
>       riscv: Handle zicsr/zifencei issues between clang and binutils
> 
>  Makefile                |  8 +++---
>  arch/riscv/Kconfig      | 22 ++++++++++++++++
>  arch/riscv/Makefile     | 12 +++++----
>  init/Kconfig            | 12 +++++++++
>  scripts/Kconfig.include |  6 +++++
>  scripts/as-version.sh   | 69 +++++++++++++++++++++++++++++++++++++++++++++++++
>  scripts/dummy-tools/gcc |  6 +++++
>  7 files changed, 127 insertions(+), 8 deletions(-)
> ---
> base-commit: ca9787bdecfa2174b0a169a54916e22b89b0ef5b
> change-id: 20230328-riscv-zifencei-zicsr-5-10-65596f2cac9e
> 
> Best regards,
> -- 
> Nathan Chancellor <nathan@kernel.org>
> 
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v3] purgatory: fix disabling debug info
  @ 2023-03-30 22:29 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-30 22:29 UTC (permalink / raw)
  To: Alyssa Ross
  Cc: Masahiro Yamada, Nick Cao, linux-kbuild, Nick Desaulniers,
	linux-kernel, llvm, linux-riscv, Tom Rix, Albert Ou,
	Palmer Dabbelt, Paul Walmsley, stable, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin

On Thu, Mar 30, 2023 at 06:22:24PM +0000, Alyssa Ross wrote:
> Since 32ef9e5054ec, -Wa,-gdwarf-2 is no longer used in KBUILD_AFLAGS.
> Instead, it includes -g, the appropriate -gdwarf-* flag, and also the
> -Wa versions of both of those if building with Clang and GNU as.  As a
> result, debug info was being generated for the purgatory objects, even
> though the intention was that it not be.
> 
> Fixes: 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files")
> Signed-off-by: Alyssa Ross <hi@alyssa.is>
> Cc: stable@vger.kernel.org
> Acked-by: Nick Desaulniers <ndesaulniers@google.com>

This is definitely more future proof.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
> v2: https://lore.kernel.org/r/20230326182120.194541-1-hi@alyssa.is
> 
> Difference from v2: replaced asflags-remove-y with every possible
> debug flag with asflags-y += -g0, as suggested by Nick Desaulniers.
> 
> Additionally, I've CCed the x86 maintainers this time, since Masahiro
> said he would like acks from subsystem maintainers, and
> get_maintainer.pl didn't pick them the first time around.
> 
>  arch/riscv/purgatory/Makefile | 7 +------
>  arch/x86/purgatory/Makefile   | 3 +--
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/riscv/purgatory/Makefile b/arch/riscv/purgatory/Makefile
> index d16bf715a586..9c1e71853ee7 100644
> --- a/arch/riscv/purgatory/Makefile
> +++ b/arch/riscv/purgatory/Makefile
> @@ -84,12 +84,7 @@ CFLAGS_string.o			+= $(PURGATORY_CFLAGS)
>  CFLAGS_REMOVE_ctype.o		+= $(PURGATORY_CFLAGS_REMOVE)
>  CFLAGS_ctype.o			+= $(PURGATORY_CFLAGS)
>  
> -AFLAGS_REMOVE_entry.o		+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_memcpy.o		+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_memset.o		+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_strcmp.o		+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_strlen.o		+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_strncmp.o		+= -Wa,-gdwarf-2
> +asflags-y			+= -g0
>  
>  $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
>  		$(call if_changed,ld)
> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index 17f09dc26381..8e6c81b1c8f7 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -69,8 +69,7 @@ CFLAGS_sha256.o			+= $(PURGATORY_CFLAGS)
>  CFLAGS_REMOVE_string.o		+= $(PURGATORY_CFLAGS_REMOVE)
>  CFLAGS_string.o			+= $(PURGATORY_CFLAGS)
>  
> -AFLAGS_REMOVE_setup-x86_$(BITS).o	+= -Wa,-gdwarf-2
> -AFLAGS_REMOVE_entry64.o			+= -Wa,-gdwarf-2
> +asflags-y			+= -g0
>  
>  $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
>  		$(call if_changed,ld)
> -- 
> 2.37.1
> 
> 

^ permalink raw reply	[relevance 99%]

* [PATCH 5.10 4/4] riscv: Handle zicsr/zifencei issues between clang and binutils
  2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
                   ` (2 preceding siblings ...)
  2023-03-29  0:08 96% ` [PATCH 5.10 3/4] kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS Nathan Chancellor
@ 2023-03-29  0:08 77% ` Nathan Chancellor
  2023-04-11 16:20 99% ` [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-29  0:08 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: conor, stable, llvm, Conor Dooley, Nathan Chancellor, Palmer Dabbelt

commit e89c2e815e76471cb507bd95728bf26da7976430 upstream.

There are two related issues that appear in certain combinations with
clang and GNU binutils.

The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):

  riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
  riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
  riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
  riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o

The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):

  ../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
  ../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
  clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)

This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:

  clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
  clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'

To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.

To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.

[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/riscv/Kconfig  | 22 ++++++++++++++++++++++
 arch/riscv/Makefile | 10 ++++++----
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 557c4a8c4087..c192bd7305dc 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -331,6 +331,28 @@ config RISCV_BASE_PMU
 
 endmenu
 
+config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
+	def_bool y
+	# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
+	depends on AS_IS_GNU && AS_VERSION >= 23800
+	help
+	  Newer binutils versions default to ISA spec version 20191213 which
+	  moves some instructions from the I extension to the Zicsr and Zifencei
+	  extensions.
+
+config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
+	def_bool y
+	depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
+	# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
+	depends on CC_IS_CLANG && CLANG_VERSION < 170000
+	help
+	  Certain versions of clang do not support zicsr and zifencei via -march
+	  but newer versions of binutils require it for the reasons noted in the
+	  help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This
+	  option causes an older ISA spec compatible with these older versions
+	  of clang to be passed to GAS, which has the same result as passing zicsr
+	  and zifencei to -march.
+
 config FPU
 	bool "FPU support"
 	default y
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 14cdeaa2bb32..daa679440000 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -53,10 +53,12 @@ riscv-march-$(CONFIG_ARCH_RV64I)	:= rv64ima
 riscv-march-$(CONFIG_FPU)		:= $(riscv-march-y)fd
 riscv-march-$(CONFIG_RISCV_ISA_C)	:= $(riscv-march-y)c
 
-# Newer binutils versions default to ISA spec version 20191213 which moves some
-# instructions from the I extension to the Zicsr and Zifencei extensions.
-toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
-riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
+ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC
+KBUILD_CFLAGS += -Wa,-misa-spec=2.2
+KBUILD_AFLAGS += -Wa,-misa-spec=2.2
+else
+riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) := $(riscv-march-y)_zicsr_zifencei
+endif
 
 KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y))
 KBUILD_AFLAGS += -march=$(riscv-march-y)

-- 
2.40.0


^ permalink raw reply related	[relevance 77%]

* [PATCH 5.10 3/4] kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS
  2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
  2023-03-29  0:08 70% ` [PATCH 5.10 1/4] kbuild: check the minimum assembler version in Kconfig Nathan Chancellor
  2023-03-29  0:08 92% ` [PATCH 5.10 2/4] kbuild: Switch to 'f' variants of integrated assembler flag Nathan Chancellor
@ 2023-03-29  0:08 96% ` Nathan Chancellor
  2023-03-29  0:08 77% ` [PATCH 5.10 4/4] riscv: Handle zicsr/zifencei issues between clang and binutils Nathan Chancellor
  2023-04-11 16:20 99% ` [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-29  0:08 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: conor, stable, llvm, Masahiro Yamada, Nick Desaulniers,
	Nathan Chancellor

From: Masahiro Yamada <masahiroy@kernel.org>

commit 52cc02b910284d6bddba46cce402044ab775f314 upstream.

LLVM_IAS is the user interface to set the -(no-)integrated-as flag,
and it should be used only for that purpose.

LLVM_IAS is checked in some places to determine the assembler type,
but it is not precise.

For example,

 $ make CC=gcc LLVM_IAS=1

... will use the GNU assembler (i.e. binutils) since LLVM_IAS=1 is
effective only when $(CC) is clang.

Of course, 'CC=gcc LLVM_IAS=1' is an odd combination, but the build
system can be more robust against such insane input.

Commit ba64beb17493a ("kbuild: check the minimum assembler version in
Kconfig") introduced CONFIG_AS_IS_GNU/LLVM, which is more precise
because Kconfig checks the version string from the assembler in use.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 Makefile            | 2 +-
 arch/riscv/Makefile | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 1272e482abbe..3dfacb6fa973 100644
--- a/Makefile
+++ b/Makefile
@@ -851,7 +851,7 @@ else
 DEBUG_CFLAGS	+= -g
 endif
 
-ifeq ($(LLVM_IAS),1)
+ifdef CONFIG_AS_IS_LLVM
 KBUILD_AFLAGS	+= -g
 else
 KBUILD_AFLAGS	+= -Wa,-gdwarf-2
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 9446282b52ba..14cdeaa2bb32 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -40,7 +40,7 @@ ifeq ($(CONFIG_LD_IS_LLD),y)
 ifeq ($(shell test $(CONFIG_LLD_VERSION) -lt 150000; echo $$?),0)
 	KBUILD_CFLAGS += -mno-relax
 	KBUILD_AFLAGS += -mno-relax
-ifneq ($(LLVM_IAS),1)
+ifndef CONFIG_AS_IS_LLVM
 	KBUILD_CFLAGS += -Wa,-mno-relax
 	KBUILD_AFLAGS += -Wa,-mno-relax
 endif

-- 
2.40.0


^ permalink raw reply related	[relevance 96%]

* [PATCH 5.10 2/4] kbuild: Switch to 'f' variants of integrated assembler flag
  2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
  2023-03-29  0:08 70% ` [PATCH 5.10 1/4] kbuild: check the minimum assembler version in Kconfig Nathan Chancellor
@ 2023-03-29  0:08 92% ` Nathan Chancellor
  2023-03-29  0:08 96% ` [PATCH 5.10 3/4] kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS Nathan Chancellor
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-29  0:08 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: conor, stable, llvm, Nick Desaulniers, Nathan Chancellor,
	Masahiro Yamada

commit 2185a7e4b0ade86c2c57fc63d4a7535c40254bd0 upstream.

It has been brought up a few times in various code reviews that clang
3.5 introduced -f{,no-}integrated-as as the preferred way to enable and
disable the integrated assembler, mentioning that -{no-,}integrated-as
are now considered legacy flags.

Switch the kernel over to using those variants in case there is ever a
time where clang decides to remove the non-'f' variants of the flag.

Also, fix a typo in a comment ("intergrated" -> "integrated").

Link: https://releases.llvm.org/3.5.0/tools/clang/docs/ReleaseNotes.html#new-compiler-flags
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 Makefile              | 4 ++--
 scripts/as-version.sh | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index 44d9aff4f66a..1272e482abbe 100644
--- a/Makefile
+++ b/Makefile
@@ -581,9 +581,9 @@ ifneq ($(GCC_TOOLCHAIN),)
 CLANG_FLAGS	+= --gcc-toolchain=$(GCC_TOOLCHAIN)
 endif
 ifeq ($(LLVM_IAS),1)
-CLANG_FLAGS	+= -integrated-as
+CLANG_FLAGS	+= -fintegrated-as
 else
-CLANG_FLAGS	+= -no-integrated-as
+CLANG_FLAGS	+= -fno-integrated-as
 endif
 CLANG_FLAGS	+= -Werror=unknown-warning-option
 KBUILD_CFLAGS	+= $(CLANG_FLAGS)
diff --git a/scripts/as-version.sh b/scripts/as-version.sh
index 851dcb8a0e68..532270bd4b7e 100755
--- a/scripts/as-version.sh
+++ b/scripts/as-version.sh
@@ -21,14 +21,14 @@ get_canonical_version()
 	echo $((10000 * $1 + 100 * ${2:-0} + ${3:-0}))
 }
 
-# Clang fails to handle -Wa,--version unless -no-integrated-as is given.
-# We check -(f)integrated-as, expecting it is explicitly passed in for the
+# Clang fails to handle -Wa,--version unless -fno-integrated-as is given.
+# We check -fintegrated-as, expecting it is explicitly passed in for the
 # integrated assembler case.
 check_integrated_as()
 {
 	while [ $# -gt 0 ]; do
-		if [ "$1" = -integrated-as -o "$1" = -fintegrated-as ]; then
-			# For the intergrated assembler, we do not check the
+		if [ "$1" = -fintegrated-as ]; then
+			# For the integrated assembler, we do not check the
 			# version here. It is the same as the clang version, and
 			# it has been already checked by scripts/cc-version.sh.
 			echo LLVM 0

-- 
2.40.0


^ permalink raw reply related	[relevance 92%]

* [PATCH 5.10 1/4] kbuild: check the minimum assembler version in Kconfig
  2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
@ 2023-03-29  0:08 70% ` Nathan Chancellor
  2023-03-29  0:08 92% ` [PATCH 5.10 2/4] kbuild: Switch to 'f' variants of integrated assembler flag Nathan Chancellor
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-29  0:08 UTC (permalink / raw)
  To: gregkh, sashal; +Cc: conor, stable, llvm, Masahiro Yamada, Nathan Chancellor

From: Masahiro Yamada <masahiroy@kernel.org>

commit ba64beb17493a4bfec563100c86a462a15926f24 upstream.

Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.

Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.

Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.

As usual, the --version option prints the version string.

  $ as --version | head -n 1
  GNU assembler (GNU Binutils for Ubuntu) 2.35.1

But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.

  $ gcc -Wa,--version | head -n 1
  gcc: fatal error: no input files
  compilation terminated.

OK, we need to input something to satisfy gcc.

  $ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  GNU assembler (GNU Binutils for Ubuntu) 2.35.1

The combination of Clang and GNU assembler works in the same way:

  $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  GNU assembler (GNU Binutils for Ubuntu) 2.35.1

Clang with the integrated assembler fails like this:

  $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  clang: error: unsupported argument '--version' to option 'Wa,'

For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.

One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.

Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]

With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.

  $ scripts/as-version.sh gcc
  GNU 23501
  $ scripts/as-version.sh clang -no-integrated-as
  GNU 23501
  $ scripts/as-version.sh clang -integrated-as
  LLVM 0

[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nathan: Backport to 5.10. Drop minimum version checking, as it is not
         required in 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 Makefile                |  4 ++-
 init/Kconfig            | 12 +++++++++
 scripts/Kconfig.include |  6 +++++
 scripts/as-version.sh   | 69 +++++++++++++++++++++++++++++++++++++++++++++++++
 scripts/dummy-tools/gcc |  6 +++++
 5 files changed, 96 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 71caf5938361..44d9aff4f66a 100644
--- a/Makefile
+++ b/Makefile
@@ -580,7 +580,9 @@ endif
 ifneq ($(GCC_TOOLCHAIN),)
 CLANG_FLAGS	+= --gcc-toolchain=$(GCC_TOOLCHAIN)
 endif
-ifneq ($(LLVM_IAS),1)
+ifeq ($(LLVM_IAS),1)
+CLANG_FLAGS	+= -integrated-as
+else
 CLANG_FLAGS	+= -no-integrated-as
 endif
 CLANG_FLAGS	+= -Werror=unknown-warning-option
diff --git a/init/Kconfig b/init/Kconfig
index eba883d6d9ed..9807c66b24bb 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,18 @@ config CLANG_VERSION
 	int
 	default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
 
+config AS_IS_GNU
+	def_bool $(success,test "$(as-name)" = GNU)
+
+config AS_IS_LLVM
+	def_bool $(success,test "$(as-name)" = LLVM)
+
+config AS_VERSION
+	int
+	# Use clang version if this is the integrated assembler
+	default CLANG_VERSION if AS_IS_LLVM
+	default $(as-version)
+
 config LLD_VERSION
 	int
 	default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index a5fe72c504ff..6d37cb780452 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -42,6 +42,12 @@ $(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
 # Fail if the linker is gold as it's not capable of linking the kernel proper
 $(error-if,$(success, $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
 
+# Get the assembler name, version, and error out if it is not supported.
+as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
+$(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler is not supported.)
+as-name := $(shell,set -- $(as-info) && echo $1)
+as-version := $(shell,set -- $(as-info) && echo $2)
+
 # machine bit flags
 #  $(m32-flag): -m32 if the compiler supports it, or an empty string otherwise.
 #  $(m64-flag): -m64 if the compiler supports it, or an empty string otherwise.
diff --git a/scripts/as-version.sh b/scripts/as-version.sh
new file mode 100755
index 000000000000..851dcb8a0e68
--- /dev/null
+++ b/scripts/as-version.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Print the assembler name and its version in a 5 or 6-digit form.
+# Also, perform the minimum version check.
+# (If it is the integrated assembler, return 0 as the version, and
+# skip the version check.)
+
+set -e
+
+# Convert the version string x.y.z to a canonical 5 or 6-digit form.
+get_canonical_version()
+{
+	IFS=.
+	set -- $1
+
+	# If the 2nd or 3rd field is missing, fill it with a zero.
+	#
+	# The 4th field, if present, is ignored.
+	# This occurs in development snapshots as in 2.35.1.20201116
+	echo $((10000 * $1 + 100 * ${2:-0} + ${3:-0}))
+}
+
+# Clang fails to handle -Wa,--version unless -no-integrated-as is given.
+# We check -(f)integrated-as, expecting it is explicitly passed in for the
+# integrated assembler case.
+check_integrated_as()
+{
+	while [ $# -gt 0 ]; do
+		if [ "$1" = -integrated-as -o "$1" = -fintegrated-as ]; then
+			# For the intergrated assembler, we do not check the
+			# version here. It is the same as the clang version, and
+			# it has been already checked by scripts/cc-version.sh.
+			echo LLVM 0
+			exit 0
+		fi
+		shift
+	done
+}
+
+check_integrated_as "$@"
+
+orig_args="$@"
+
+# Get the first line of the --version output.
+IFS='
+'
+set -- $(LC_ALL=C "$@" -Wa,--version -c -x assembler /dev/null -o /dev/null 2>/dev/null)
+
+# Split the line on spaces.
+IFS=' '
+set -- $1
+
+if [ "$1" = GNU -a "$2" = assembler ]; then
+	shift $(($# - 1))
+	version=$1
+	name=GNU
+else
+	echo "$orig_args: unknown assembler invoked" >&2
+	exit 1
+fi
+
+# Some distributions append a package release number, as in 2.34-4.fc32
+# Trim the hyphen and any characters that follow.
+version=${version%-*}
+
+cversion=$(get_canonical_version $version)
+
+echo $name $cversion
diff --git a/scripts/dummy-tools/gcc b/scripts/dummy-tools/gcc
index 346757a87dbc..485427f40dba 100755
--- a/scripts/dummy-tools/gcc
+++ b/scripts/dummy-tools/gcc
@@ -67,6 +67,12 @@ if arg_contain -E "$@"; then
 	fi
 fi
 
+# To set CONFIG_AS_IS_GNU
+if arg_contain -Wa,--version "$@"; then
+	echo "GNU assembler (scripts/dummy-tools) 2.50"
+	exit 0
+fi
+
 if arg_contain -S "$@"; then
 	# For scripts/gcc-x86-*-has-stack-protector.sh
 	if arg_contain -fstack-protector "$@"; then

-- 
2.40.0


^ permalink raw reply related	[relevance 70%]

* [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y
@ 2023-03-29  0:08 97% Nathan Chancellor
  2023-03-29  0:08 70% ` [PATCH 5.10 1/4] kbuild: check the minimum assembler version in Kconfig Nathan Chancellor
                   ` (4 more replies)
  0 siblings, 5 replies; 200+ results
From: Nathan Chancellor @ 2023-03-29  0:08 UTC (permalink / raw)
  To: gregkh, sashal
  Cc: conor, stable, llvm, Masahiro Yamada, Nathan Chancellor,
	Nick Desaulniers, Conor Dooley, Palmer Dabbelt

Hi all,

This series is a backport of upstream commit e89c2e815e76 ("riscv:
Handle zicsr/zifencei issues between clang and binutils") to
linux-5.10.y, with the necessary machinery for CONFIG_AS_IS_GNU and
CONFIG_AS_VERSION, which that commit requires.

While the middle two patches are not strictly necessary, they are good
clean ups that ensure consistency with mainline. The first three changes
are already present in 5.15, so there is no risk of a regression moving
forward.

If there are any issues, please let me know.

NOTE: I am sending this series with 'b4 send', as that is what I am used
to at this point. Please accept my apologies if this causes any issues.

---
Masahiro Yamada (2):
      kbuild: check the minimum assembler version in Kconfig
      kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS

Nathan Chancellor (2):
      kbuild: Switch to 'f' variants of integrated assembler flag
      riscv: Handle zicsr/zifencei issues between clang and binutils

 Makefile                |  8 +++---
 arch/riscv/Kconfig      | 22 ++++++++++++++++
 arch/riscv/Makefile     | 12 +++++----
 init/Kconfig            | 12 +++++++++
 scripts/Kconfig.include |  6 +++++
 scripts/as-version.sh   | 69 +++++++++++++++++++++++++++++++++++++++++++++++++
 scripts/dummy-tools/gcc |  6 +++++
 7 files changed, 127 insertions(+), 8 deletions(-)
---
base-commit: ca9787bdecfa2174b0a169a54916e22b89b0ef5b
change-id: 20230328-riscv-zifencei-zicsr-5-10-65596f2cac9e

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply	[relevance 97%]

* [PATCH] riscv: Handle zicsr/zifencei issues between clang and binutils
@ 2023-03-13 23:00 73% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-03-13 23:00 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, conor.dooley
  Cc: nathan, ndesaulniers, trix, linux-riscv, linux-kernel, llvm,
	patches, stable

There are two related issues that appear in certain combinations with
clang and GNU binutils.

The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):

  riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
  riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
  riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
  riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o

The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):

  ../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
  ../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
  clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)

This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:

  clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
  clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'

To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.

To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.

[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This is essentially a v3 of Conor's v1 and v2 but since I am sending the
patch after finding a separate but related issue, I left it at v1:

- v1: https://lore.kernel.org/20230223220546.52879-1-conor@kernel.org/
- v2: https://lore.kernel.org/20230308220842.1231003-1-conor@kernel.org/

I have built allmodconfig with the following toolchain combinations to
confirm this problem is resolved:

- clang 12/17 + GNU as and ld 2.35/2.39
- clang 12/17 with the integrated assembler + GNU ld 2.35/2.39
- clang 12/17 with the integrated assembler + ld.lld

There are a couple of other incompatibilities between clang-17 and GNU
binutils that I had to patch to get allmodconfig to build successfully
but those are less likely to be hit in practice because the full LLVM
stack can be used with LLVM versions 13.x and newer. I will follow up
with separate issues and patches.
---
 arch/riscv/Kconfig  | 22 ++++++++++++++++++++++
 arch/riscv/Makefile | 10 ++++++----
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c5e42cc37604..5b182d1c196c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -464,6 +464,28 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE
 	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause)
 	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23600
 
+config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
+	def_bool y
+	# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
+	depends on AS_IS_GNU && AS_VERSION >= 23800
+	help
+	  Newer binutils versions default to ISA spec version 20191213 which
+	  moves some instructions from the I extension to the Zicsr and Zifencei
+	  extensions.
+
+config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
+	def_bool y
+	depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
+	# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
+	depends on CC_IS_CLANG && CLANG_VERSION < 170000
+	help
+	  Certain versions of clang do not support zicsr and zifencei via -march
+	  but newer versions of binutils require it for the reasons noted in the
+	  help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This
+	  option causes an older ISA spec compatible with these older versions
+	  of clang to be passed to GAS, which has the same result as passing zicsr
+	  and zifencei to -march.
+
 config FPU
 	bool "FPU support"
 	default y
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 4de83b9b1772..b05e833a022d 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -57,10 +57,12 @@ riscv-march-$(CONFIG_ARCH_RV64I)	:= rv64ima
 riscv-march-$(CONFIG_FPU)		:= $(riscv-march-y)fd
 riscv-march-$(CONFIG_RISCV_ISA_C)	:= $(riscv-march-y)c
 
-# Newer binutils versions default to ISA spec version 20191213 which moves some
-# instructions from the I extension to the Zicsr and Zifencei extensions.
-toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
-riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
+ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC
+KBUILD_CFLAGS += -Wa,-misa-spec=2.2
+KBUILD_AFLAGS += -Wa,-misa-spec=2.2
+else
+riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) := $(riscv-march-y)_zicsr_zifencei
+endif
 
 # Check if the toolchain supports Zihintpause extension
 riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause

---
base-commit: eeac8ede17557680855031c6f305ece2378af326
change-id: 20230313-riscv-zicsr-zifencei-fiasco-2941caebe7dc

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


^ permalink raw reply related	[relevance 73%]

* Please apply 4e4a08868f15897ca236528771c3733fded42c62 to linux-6.2.y
@ 2023-02-28 16:17 95% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-28 16:17 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, linux-crypto, Herbert Xu

Hi Greg and Sasha,

Please apply commit 4e4a08868f15 ("crypto: arm64/sm4-gcm - Fix possible crash
in GCM cryption") to 6.2, as it fixes a crash that I see when booting Arch
Linux ARM's aarch64 configuration [1] in QEMU:

[    1.512110] Unable to handle kernel paging request at virtual address fffffe000024d588
[    1.512357] Mem abort info:
[    1.512542]   ESR = 0x0000000097c38004
[    1.512695]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.512863]   SET = 0, FnV = 0
[    1.512967]   EA = 0, S1PTW = 0
[    1.513075]   FSC = 0x04: level 0 translation fault
[    1.513236] Data abort info:
[    1.513343]   Access size = 8 byte(s)
[    1.513618]   SSE = 0, SRT = 3
[    1.513721]   SF = 1, AR = 0
[    1.513824]   CM = 0, WnR = 0
[    1.513964] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041ef8000
[    1.514162] [fffffe000024d588] pgd=0000000000000000, p4d=0000000000000000
[    1.514932] Internal error: Oops: 0000000097c38004 [#1] PREEMPT SMP
[    1.515206] Modules linked in:
[    1.515477] CPU: 0 PID: 113 Comm: cryptomgr_test Not tainted 6.2.1-ARCH #1
[    1.515755] Hardware name: linux,dummy-virt (DT)
[    1.516029] pstate: a1400009 (NzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[    1.516277] pc : kfree+0x30/0xb0
[    1.516766] lr : skcipher_walk_done+0x198/0x2b0
[    1.516934] sp : ffff80000ace3820
[    1.517042] x29: ffff80000ace3820 x28: 0000000000000000 x27: 0000000000000400
[    1.517316] x26: ffff80000937d880 x25: ffff0000034d0400 x24: ffff0000036efe00
[    1.517557] x23: ffff800008088730 x22: ffff0000036efd00 x21: ffff80000ace3998
[    1.517791] x20: 0000000000000000 x19: ffff80000ace3900 x18: ffffffffffffffff
[    1.518022] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff
[    1.518263] x14: ffff80008ace3ce7 x13: 0000000000000000 x12: 0000000000000000
[    1.518510] x11: ffff80000ace38c8 x10: ffff80000ace38d0 x9 : 0000000000000001
[    1.518757] x8 : 0000000000000000 x7 : ffff80000ace38a8 x6 : 0000000000000001
[    1.518993] x5 : ffff80000ace3998 x4 : fffffc0000000000 x3 : ffff80000ace3b00
[    1.519242] x2 : 000002000024d580 x1 : ffff800009356218 x0 : fffffe000024d580
[    1.519549] Call trace:
[    1.519654]  kfree+0x30/0xb0
[    1.519785]  skcipher_walk_done+0x198/0x2b0
[    1.519931]  gcm_crypt+0xd8/0x170
[    1.520047]  gcm_encrypt+0x90/0xbc
[    1.520153]  crypto_aead_encrypt+0x24/0x40
[    1.520285]  test_aead_vec_cfg+0x21c/0x770
[    1.520422]  test_aead+0xb4/0x140
[    1.520538]  alg_test_aead+0x94/0x190
[    1.520662]  alg_test+0x34c/0x520
[    1.520770]  cryptomgr_test+0x24/0x44
[    1.520889]  kthread+0xe4/0xf0
[    1.520993]  ret_from_fork+0x10/0x20
[    1.521300] Code: b25657e4 d34cfc42 d37ae442 8b040040 (f9400403)
[    1.521691] ---[ end trace 0000000000000000 ]---

[1]: https://github.com/archlinuxarm/PKGBUILDs/raw/master/core/linux-aarch64/config

Cheers,
Nathan

^ permalink raw reply	[relevance 95%]

* Re: [PATCH v1 2/2] RISC-V: make TOOLCHAIN_NEEDS_SPEC_20191213 gas only
  @ 2023-02-24 16:32 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-24 16:32 UTC (permalink / raw)
  To: Conor Dooley
  Cc: palmer, Conor Dooley, naresh.kamboju, linux-riscv, llvm, stable

Hi Conor,

On Thu, Feb 23, 2023 at 10:05:46PM +0000, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> Quoting the llvm docs:
> > Between versions 2.0 and 2.1 of the base I specification, a backwards
> > incompatible change was made to remove selected instructions and CSRs
> > from the base ISA. These instructions were grouped into a set of new
> > extensions, but were no longer required by the base ISA. (snip) LLVM
> > currently implements version 2.0 of the base specification. Thus,
> > instructions from these extensions are accepted as part of the base
> > ISA.
> 
> There is therefore no need (at present!) to carry out a $cc-option
> check, and instead just gate presence of zicsr and zifencei in march
> on the version of binutils that commit 6df2a016c0c8 ("riscv: fix build
> with binutils 2.38") highlights as the introduction of the requirement.
> 
> In fact, the status quo creates some issues with mixed llvm/binutils
> builds, specifically building with llvm-17 and ld from binutils-2.35.
> Odd combo you may think, but this is what tuxsuite's debian stable uses
> while testing 5.10 stable kernels as doesn't support LLD.
> 
> CC: stable@vger.kernel.org # needs RISC-V: move zicsr/zifencei spec version check to Kconfi

I think it would be better to drop this comment and just mark patch 1
for stable directly. However, if it remains, 'Kconfi' -> 'Kconfig' :)

> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Link: https://lore.kernel.org/all/CA+G9fYt9T=ELCLaB9byxaLW2Qf4pZcDO=huCA0D8ug2V2+irJQ@mail.gmail.com/
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

Thanks for helping getting down to the bottom of this!

> ---
>  arch/riscv/Kconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 4eb0ef8314b3..c6902f4c5650 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -291,8 +291,7 @@ endchoice
>  config TOOLCHAIN_NEEDS_SPEC_20191213
>  	bool
>  	default y
> -	depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zicsr_zifencei)
> -	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zicsr_zifencei)
> +	depends on AS_IS_GNU && AS_VERSION >= 23800
>  	help
>  	  Newer binutils versions default to ISA spec version 20191213 which
>  	  moves some instructions from the I extension to the Zicsr and Zifencei
> -- 
> 2.39.1
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.15 00/37] 5.15.96-rc2 review
  @ 2023-02-23 19:47 98%         ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-23 19:47 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Greg Kroah-Hartman, stable, patches, linux-kernel,
	akpm, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
	sudipm.mukherjee, srw, rwarsow

On Thu, Feb 23, 2023 at 10:03:43AM -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2023 at 9:31 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > This isn't the first time this happens. I seem to recall that you mentioned
> > some time ago that whatever you use to apply patches (quilt ?) doesn't
> > handle executable permission bits correctly.
> 
> Note that even though git itself does handle these things right, we've
> also always said that if some old fogey wants to use tar-balls and
> patches, that's supposed to still work.
> 
> I guess the same "old fogey" comment then covers quilt too.
> 
> End result: we should try to generally not execute our scripts
> directly, but to explicitly state which interpreter it should use,
> rather than then depend on the #! in the script itself to do it.
> 
> In fact, for shell scripting in particular, we go further than that,
> and use $(CONFIG_SHELL)
> 
> Of course, in this case, it's actually using the Makefile '$(shell
> ..)' format, so I guess it looks a bit odd to write it as
> 
>    $(shell $(CONFIG_SHELL) script..)
> 
> but I do think we should do it.

Right, we would also need CONFIG_SHELL within scripts/pahole-flags.sh
for scripts/pahole-version.sh, which is really what was blowing up here,
but the invocation of 'scripts/pahole-flags.sh' in Makefile needs it too
to avoid the same problem if it were added to an older kernel.

diff --git a/scripts/pahole-flags.sh b/scripts/pahole-flags.sh
index 0d99ef17e4a5..ca3c311a3855 100755
--- a/scripts/pahole-flags.sh
+++ b/scripts/pahole-flags.sh
@@ -7,7 +7,7 @@ if ! [ -x "$(command -v ${PAHOLE})" ]; then
 	exit 0
 fi
 
-pahole_ver=$($(dirname $0)/pahole-version.sh ${PAHOLE})
+pahole_ver=$(${CONFIG_SHELL} $(dirname $0)/pahole-version.sh ${PAHOLE})
 
 if [ "${pahole_ver}" -ge "118" ] && [ "${pahole_ver}" -le "121" ]; then
 	# pahole 1.18 through 1.21 can't handle zero-sized per-CPU vars

I can send a patch unless you want to take those changes directly, you
have half a commit message there already I think :)

Cheers,
Nathan

^ permalink raw reply related	[relevance 98%]

* Re: stable-rc: 5.10: riscv: defconfig: clang-nightly: build failed - Invalid or unknown z ISA extension: 'zifencei'
  @ 2023-02-21 22:33 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-21 22:33 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Naresh Kamboju, llvm, linux-riscv, linux-stable, lkft-triage,
	Greg Kroah-Hartman, Sasha Levin, conor, Heiko Stuebner

On Tue, Feb 21, 2023 at 09:15:11AM +0000, Conor Dooley wrote:
> On Tue, Feb 21, 2023 at 02:30:17PM +0530, Naresh Kamboju wrote:
> > The riscv defconfig and tinyconfig builds failed with clang-nightly
> > due to below build warnings / errors on latest stable-rc 5.10.
> > 
> > Regression on riscv:
> >   - build/clang-nightly-tinyconfig - FAILED
> >   - build/clang-nightly-defconfig - FAILED
> 
> > Build log:
> > ----
> > make --silent --keep-going --jobs=8
> > O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=riscv
> > CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=clang CC=clang LLVM=1
> > LLVM_IAS=1 LD=riscv64-linux-gnu-ld
> > riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
> > Invalid or unknown z ISA extension: 'zifencei'
> > riscv64-linux-gnu-ld: failed to merge target specific data of file
> > init/version.o
> > riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
> > Invalid or unknown z ISA extension: 'zifencei'
> > riscv64-linux-gnu-ld: failed to merge target specific data of file
> > init/do_mounts.o
> > riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
> > Invalid or unknown z ISA extension: 'zifencei'
> > riscv64-linux-gnu-ld: failed to merge target specific data of file
> > init/noinitramfs.o
> > riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
> > Invalid or unknown z ISA extension: 'zifencei'
> > riscv64-linux-gnu-ld: failed to merge target specific data of file
> > init/calibrate.o
> > riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_zicsr2p0_zifencei2p0:
> > Invalid or unknown z ISA extension: 'zifencei'
> 
> > Build details,
> > https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.168-58-g7d11e4c4fc56/testrun/14869376/suite/build/test/clang-nightly-tinyconfig/details/
> 
> binutils 2.35 by the looks of things, I **think** that zifencei didn't
> land until 2.36. zicsr and zifence get added via cc-option-yn, which,
> IIRC, doesn't do anything with the linker. I dunno if anyone in RISC-V
> land cares this much about "odd" configurations back in 5.10, but while
> a fix is outstanding, you could use a newer binutils?

This is new in clang-17 so I bisected LLVM down to commit 22e199e6afb1
("[RISCV] Accept zicsr and zifencei command line options"), so I think
we need something like commit aae538cd03bc ("riscv: fix detection of
toolchain Zihintpause support") for zifencei to make sure all three
tools stay in sync, since I suspect that this is reproducible in
mainline with GNU ld. We just happen not to notice when using
LLVM=1 LLVM_IAS=1 since the tools have symmetrical support.

I can work up something like that change tomorrow if that seems like the
path worth taking.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* static call fixes for clang's conditional tail calls (6.2 and 6.1)
@ 2023-02-21 19:48 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-21 19:48 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Peter Zijlstra, Nick Desaulniers, stable, llvm

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Hi Greg and Sasha,

Please consider applying the following commits to 6.2 (they apply
cleanly with some fuzz for me):

db7adcfd1cec ("x86/alternatives: Introduce int3_emulate_jcc()")
ac0ee0a9560c ("x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions")
923510c88d2b ("x86/static_call: Add support for Jcc tail-calls")

I have attached backports to 6.1.

Without these changes, kernels built with any version of clang using -Os
or clang 17.0.0 (tip of tree) at any kernel-supported optimization level
do not boot. This has been tested by people affected by this problem,
see https://github.com/ClangBuiltLinux/linux/issues/1774 for more info.

If there are any problems, please let me know.

Cheers,
Nathan

[-- Attachment #2: clang-jcc-series-6.1.mbox --]
[-- Type: application/mbox, Size: 15195 bytes --]

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] randstruct: disable Clang 15 support
  @ 2023-02-08 14:32 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-08 14:32 UTC (permalink / raw)
  To: Eric Biggers
  Cc: linux-hardening, Kees Cook, Bill Wendling, llvm, linux-kernel, stable

On Tue, Feb 07, 2023 at 10:51:33PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> The randstruct support released in Clang 15 is unsafe to use due to a
> bug that can cause miscompilations: "-frandomize-layout-seed
> inconsistently randomizes all-function-pointers structs"
> (https://github.com/llvm/llvm-project/issues/60349).  It has been fixed
> on the Clang 16 release branch, so add a Clang version check.
> 
> Fixes: 035f7f87b729 ("randstruct: Enable Clang support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@google.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  security/Kconfig.hardening | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 53baa95cb644f..0f295961e7736 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -281,6 +281,9 @@ endmenu
>  
>  config CC_HAS_RANDSTRUCT
>  	def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
> +	# Randstruct was first added in Clang 15, but it isn't safe to use until
> +	# Clang 16 due to https://github.com/llvm/llvm-project/issues/60349
> +	depends on !CC_IS_CLANG || CLANG_VERSION >= 160000
>  
>  choice
>  	prompt "Randomize layout of sensitive kernel structures"
> 
> base-commit: 4ec5183ec48656cec489c49f989c508b68b518e3
> -- 
> 2.39.1
> 
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 6.1 00/28] 6.1.10-rc1 review
  @ 2023-02-05 19:51 93%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-02-05 19:51 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
	akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh,
	f.fainelli, sudipm.mukherjee, srw, rwarsow, llvm

Hi Naresh,

On Sat, Feb 04, 2023 at 12:55:10PM +0530, Naresh Kamboju wrote:
> On Fri, 3 Feb 2023 at 15:50, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 6.1.10 release.
> > There are 28 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun, 05 Feb 2023 10:09:58 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.10-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
> 
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> NOTE:
> 
> clang-nightly-allmodconfig - Failed
> 
> Build error:
> -----------
>   include/linux/fortify-string.h:430:4: error: call to '__write_overflow_field'
>    declared with 'warning' attribute: detected write beyond size of field
>    (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> 
> This is already reported upstream,
> https://lore.kernel.org/llvm/63d0c141.050a0220.c848b.4e93@mx.google.com/

I think you copied the wrong warning, as the one upstream is a write
warning, whereas the one I see in your build logs is a read error:

In file included from /builds/linux/drivers/infiniband/core/cma.c:9:
In file included from /builds/linux/include/linux/completion.h:12:
In file included from /builds/linux/include/linux/swait.h:7:
In file included from /builds/linux/include/linux/spinlock.h:56:
In file included from /builds/linux/include/linux/preempt.h:78:
In file included from /builds/linux/arch/x86/include/asm/preempt.h:7:
In file included from /builds/linux/include/linux/thread_info.h:60:
In file included from /builds/linux/arch/x86/include/asm/thread_info.h:53:
In file included from /builds/linux/arch/x86/include/asm/cpufeature.h:5:
In file included from /builds/linux/arch/x86/include/asm/processor.h:22:
In file included from /builds/linux/arch/x86/include/asm/msr.h:11:
In file included from /builds/linux/arch/x86/include/asm/cpumask.h:5:
In file included from /builds/linux/include/linux/cpumask.h:12:
In file included from /builds/linux/include/linux/bitmap.h:11:
In file included from /builds/linux/include/linux/string.h:253:
/builds/linux/include/linux/fortify-string.h:543:4: error: call to '__read_overflow' declared with 'error' attribute: detected read beyond size of object (1st parameter)
                        __read_overflow();
                        ^

Regardless, this is still a clang bug that we are actively investigating, so it
can still be safely ignored by the kernel folks.

https://github.com/ClangBuiltLinux/linux/issues/1687

Cheers,
Nathan

^ permalink raw reply	[relevance 93%]

* Re: [PATCH 4.14 230/338] wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
  @ 2023-01-18 16:21 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-01-18 16:21 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: stable, patches, Dokyung Song, Jisoo Jang, Minsuk Kang,
	Kalle Valo, Sasha Levin

On Mon, Jan 16, 2023 at 04:51:43PM +0100, Greg Kroah-Hartman wrote:
> From: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
> 
> [ Upstream commit 81d17f6f3331f03c8eafdacea68ab773426c1e3c ]
> 
> This patch fixes a shift-out-of-bounds in brcmfmac that occurs in
> BIT(chiprev) when a 'chiprev' provided by the device is too large.
> It should also not be equal to or greater than BITS_PER_TYPE(u32)
> as we do bitwise AND with a u32 variable and BIT(chiprev). The patch
> adds a check that makes the function return NULL if that is the case.
> Note that the NULL case is later handled by the bus-specific caller,
> brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.
> 
> Found by a modified version of syzkaller.
> 
> UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> shift exponent 151055786 is too large for 64-bit type 'long unsigned int'
> CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  dump_stack_lvl+0x57/0x7d
>  ubsan_epilogue+0x5/0x40
>  __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb
>  ? lock_chain_count+0x20/0x20
>  brcmf_fw_alloc_request.cold+0x19/0x3ea
>  ? brcmf_fw_get_firmwares+0x250/0x250
>  ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0
>  brcmf_usb_get_fwname+0x114/0x1a0
>  ? brcmf_usb_reset_resume+0x120/0x120
>  ? number+0x6c4/0x9a0
>  brcmf_c_process_clm_blob+0x168/0x590
>  ? put_dec+0x90/0x90
>  ? enable_ptr_key_workfn+0x20/0x20
>  ? brcmf_common_pd_remove+0x50/0x50
>  ? rcu_read_lock_sched_held+0xa1/0xd0
>  brcmf_c_preinit_dcmds+0x673/0xc40
>  ? brcmf_c_set_joinpref_default+0x100/0x100
>  ? rcu_read_lock_sched_held+0xa1/0xd0
>  ? rcu_read_lock_bh_held+0xb0/0xb0
>  ? lock_acquire+0x19d/0x4e0
>  ? find_held_lock+0x2d/0x110
>  ? brcmf_usb_deq+0x1cc/0x260
>  ? mark_held_locks+0x9f/0xe0
>  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
>  ? _raw_spin_unlock_irqrestore+0x47/0x50
>  ? trace_hardirqs_on+0x1c/0x120
>  ? brcmf_usb_deq+0x1a7/0x260
>  ? brcmf_usb_rx_fill_all+0x5a/0xf0
>  brcmf_attach+0x246/0xd40
>  ? wiphy_new_nm+0x1476/0x1d50
>  ? kmemdup+0x30/0x40
>  brcmf_usb_probe+0x12de/0x1690
>  ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
>  usb_probe_interface+0x25f/0x710
>  really_probe+0x1be/0xa90
>  __driver_probe_device+0x2ab/0x460
>  ? usb_match_id.part.0+0x88/0xc0
>  driver_probe_device+0x49/0x120
>  __device_attach_driver+0x18a/0x250
>  ? driver_allows_async_probing+0x120/0x120
>  bus_for_each_drv+0x123/0x1a0
>  ? bus_rescan_devices+0x20/0x20
>  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
>  ? trace_hardirqs_on+0x1c/0x120
>  __device_attach+0x207/0x330
>  ? device_bind_driver+0xb0/0xb0
>  ? kobject_uevent_env+0x230/0x12c0
>  bus_probe_device+0x1a2/0x260
>  device_add+0xa61/0x1ce0
>  ? __mutex_unlock_slowpath+0xe7/0x660
>  ? __fw_devlink_link_to_suppliers+0x550/0x550
>  usb_set_configuration+0x984/0x1770
>  ? kernfs_create_link+0x175/0x230
>  usb_generic_driver_probe+0x69/0x90
>  usb_probe_device+0x9c/0x220
>  really_probe+0x1be/0xa90
>  __driver_probe_device+0x2ab/0x460
>  driver_probe_device+0x49/0x120
>  __device_attach_driver+0x18a/0x250
>  ? driver_allows_async_probing+0x120/0x120
>  bus_for_each_drv+0x123/0x1a0
>  ? bus_rescan_devices+0x20/0x20
>  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
>  ? trace_hardirqs_on+0x1c/0x120
>  __device_attach+0x207/0x330
>  ? device_bind_driver+0xb0/0xb0
>  ? kobject_uevent_env+0x230/0x12c0
>  bus_probe_device+0x1a2/0x260
>  device_add+0xa61/0x1ce0
>  ? __fw_devlink_link_to_suppliers+0x550/0x550
>  usb_new_device.cold+0x463/0xf66
>  ? hub_disconnect+0x400/0x400
>  ? _raw_spin_unlock_irq+0x24/0x30
>  hub_event+0x10d5/0x3330
>  ? hub_port_debounce+0x280/0x280
>  ? __lock_acquire+0x1671/0x5790
>  ? wq_calc_node_cpumask+0x170/0x2a0
>  ? lock_release+0x640/0x640
>  ? rcu_read_lock_sched_held+0xa1/0xd0
>  ? rcu_read_lock_bh_held+0xb0/0xb0
>  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
>  process_one_work+0x873/0x13e0
>  ? lock_release+0x640/0x640
>  ? pwq_dec_nr_in_flight+0x320/0x320
>  ? rwlock_bug.part.0+0x90/0x90
>  worker_thread+0x8b/0xd10
>  ? __kthread_parkme+0xd9/0x1d0
>  ? process_one_work+0x13e0/0x13e0
>  kthread+0x379/0x450
>  ? _raw_spin_unlock_irq+0x24/0x30
>  ? set_kthread_struct+0x100/0x100
>  ret_from_fork+0x1f/0x30
> 
> Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
> Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
> Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
> Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
> Signed-off-by: Kalle Valo <kvalo@kernel.org>
> Link: https://lore.kernel.org/r/20221024071329.504277-1-linuxlovemin@yonsei.ac.kr
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 13c25798f39a..6d868b8b441a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -572,6 +572,11 @@ int brcmf_fw_map_chip_to_name(u32 chip, u32 chiprev,
>  	u32 i;
>  	char end;
>  
> +	if (chiprev >= BITS_PER_TYPE(u32)) {
> +		brcmf_err("Invalid chip revision %u\n", chiprev);
> +		return NULL;
> +	}
> +
>  	for (i = 0; i < table_size; i++) {
>  		if (mapping_table[i].chipid == chip &&
>  		    mapping_table[i].revmask & BIT(chiprev))
> -- 
> 2.35.1

Clang points out that this backport is incorrect:

  drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:577:10: error: incompatible pointer to integer conversion returning 'void *' from a function with result type 'int' [-Wint-conversion]
                  return NULL;
                         ^~~~
  include/linux/stddef.h:8:14: note: expanded from macro 'NULL'
  #define NULL ((void *)0)
               ^~~~~~~~~~~
  1 error generated.

That should probably be something like -EINVAL for 4.14 but I am not
sure, hence just the report. This code path was reworked in commit
2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function").
Returning NULL would be treated as an error in the callers, which would
require a negative return code here.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.15 00/86] 5.15.89-rc1 review
  @ 2023-01-17 14:23 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-01-17 14:23 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
	akpm, linux, shuah, patches, lkft-triage, pavel, jonathanh,
	f.fainelli, sudipm.mukherjee, srw, rwarsow, llvm

Hi Naresh,

On Tue, Jan 17, 2023 at 04:57:52PM +0530, Naresh Kamboju wrote:
> On Mon, 16 Jan 2023 at 21:33, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.15.89 release.
> > There are 86 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 18 Jan 2023 15:47:28 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.89-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
> 
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> NOTE:
> clang-nightly build errors noticed on defconfig of arm64. arm. x86_64,
> i386, riscv, s390 and powerpc.
> 
> include/trace/events/initcall.h:38:3: error: 'struct (unnamed at
> include/trace/events/initcall.h:27:1)' cannot be defined in
> '__builtin_offsetof'
>                 __field_struct(initcall_t, func)
>                 ^
> include/trace/events/initcall.h:38:3: error: initializer element is
> not a compile-time constant
>                 __field_struct(initcall_t, func)
>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thanks for the report! I sent backports to avoid this issue and the one
reported on the 5.4 review but it appears they did not make this round
of stable updates.

https://lore.kernel.org/Y8TWrJpb6Vn6E4+v@dev-arch.thelio-3990X/

Hopefully it will be cleared up next round.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* offsetof() backports for clang-16+
@ 2023-01-16  4:46 97% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-01-16  4:46 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, Nick Desaulniers, YingChi Long, Borislav Petkov,
	Steven Rostedt

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi Greg and Sasha,

Clang 16 (current main, next major release) errors when offsetof() has a
type defintion in it, in response to language in newer C standards
stating it is undefined behavior.

https://github.com/llvm/llvm-project/commit/e327b52766ed497e4779f4e652b9ad237dfda8e6
https://reviews.llvm.org/D133574

While this might be eventually demoted to just a warning, the kernel has
already cleaned up places that had this construct, so we can apply them
to the stable trees and avoid the issue altogether.

Please find attached mbox files for all supported stable trees, which
fix up the relevant instances for each tree using the upstream commits:

55228db2697c ("x86/fpu: Use _Alignof to avoid undefined behavior in TYPE_ALIGN")
09794a5a6c34 ("tracing: Use alignof__(struct {type b;}) instead of offsetof()")

The fpu commit uses _Alignof, which as far as I can tell was only
supported in GCC 4.7.0+. This is not a problem for mainline due to
requiring GCC 5.1.0+ but it could be relevant for old trees like 4.14,
which have an older minimum supported version. I hope people are not
using ancient compilers like that but I suppose if they are using 4.14,
they might just be stuck with old software...

If there are any issues or comments, please let me know.
Nathan

[-- Attachment #2: 4.14.mbox --]
[-- Type: application/mbox, Size: 2364 bytes --]

[-- Attachment #3: 4.19.mbox --]
[-- Type: application/mbox, Size: 2364 bytes --]

[-- Attachment #4: 5.4.mbox --]
[-- Type: application/mbox, Size: 2363 bytes --]

[-- Attachment #5: 5.10.mbox --]
[-- Type: application/mbox, Size: 3900 bytes --]

[-- Attachment #6: 5.15.mbox --]
[-- Type: application/mbox, Size: 3916 bytes --]

[-- Attachment #7: 6.1.mbox --]
[-- Type: application/mbox, Size: 2319 bytes --]

^ permalink raw reply	[relevance 97%]

* [PATCH 6.1] drm/i915: Fix CFI violations in gt_sysfs
@ 2023-01-16  3:35 42% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-01-16  3:35 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Jocelyn Falempe, llvm, stable, Nathan Chancellor, Andi Shyti,
	Andrzej Hajda, Kees Cook

commit a8a4f0467d706fc22d286dfa973946e5944b793c upstream.

When booting with CONFIG_CFI_CLANG, there are numerous violations when
accessing the files under
/sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt/gt0:

  $ cd /sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt/gt0

  $ grep . *
  id:0
  punit_req_freq_mhz:350
  rc6_enable:1
  rc6_residency_ms:214934
  rps_act_freq_mhz:1300
  rps_boost_freq_mhz:1300
  rps_cur_freq_mhz:350
  rps_max_freq_mhz:1300
  rps_min_freq_mhz:350
  rps_RP0_freq_mhz:1300
  rps_RP1_freq_mhz:350
  rps_RPn_freq_mhz:350
  throttle_reason_pl1:0
  throttle_reason_pl2:0
  throttle_reason_pl4:0
  throttle_reason_prochot:0
  throttle_reason_ratl:0
  throttle_reason_status:0
  throttle_reason_thermal:0
  throttle_reason_vr_tdc:0
  throttle_reason_vr_thermalert:0

  $ sudo dmesg &| grep "CFI failure at"
  [  214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target: id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
  [  214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target: punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
  [  214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target: rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
  [  214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target: rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
  [  214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target: act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target: boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target: cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target: max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target: min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target: RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target: RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target: RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
  [  214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
  [  214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)

With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci0000:00/0000:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.

To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.

Link: https://github.com/ClangBuiltLinux/linux/issues/1716
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221013205909.1282545-1-nathan@kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

Hi Greg and Sasha,

I received a report from a user of kCFI in 6.1 that the violation fixed
by this patch is visible there (which is expected, since this was only
merged in 6.2-rc1). This has been boot tested on real hardware and
confirmed to fix that crash.

Additionally, Jocelyn reports that this patch also fixes a separate
crash:

https://lore.kernel.org/4dcf830e-62a5-837b-7590-ac5395f84c14@redhat.com/

The patch is a little on the larger side of things but it should be
pretty safe (the i915 folks can override me if they feel this is out of
place).

Cheers,
Nathan

 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c    |  15 +-
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h    |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 461 +++++++++-----------
 3 files changed, 220 insertions(+), 258 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index d651ccd0ab20..9486dd3bed99 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -22,11 +22,9 @@ bool is_object_gt(struct kobject *kobj)
 	return !strncmp(kobj->name, "gt", 2);
 }
 
-struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct kobject *kobj,
 					    const char *name)
 {
-	struct kobject *kobj = &dev->kobj;
-
 	/*
 	 * We are interested at knowing from where the interface
 	 * has been called, whether it's called from gt/ or from
@@ -38,6 +36,7 @@ struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
 	 * "struct drm_i915_private *" type.
 	 */
 	if (!is_object_gt(kobj)) {
+		struct device *dev = kobj_to_dev(kobj);
 		struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
 
 		return to_gt(i915);
@@ -51,18 +50,18 @@ static struct kobject *gt_get_parent_obj(struct intel_gt *gt)
 	return &gt->i915->drm.primary->kdev->kobj;
 }
 
-static ssize_t id_show(struct device *dev,
-		       struct device_attribute *attr,
+static ssize_t id_show(struct kobject *kobj,
+		       struct kobj_attribute *attr,
 		       char *buf)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 
 	return sysfs_emit(buf, "%u\n", gt->info.id);
 }
-static DEVICE_ATTR_RO(id);
+static struct kobj_attribute attr_id = __ATTR_RO(id);
 
 static struct attribute *id_attrs[] = {
-	&dev_attr_id.attr,
+	&attr_id.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(id);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index 6232923a420d..c3a123faee98 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -30,7 +30,7 @@ static inline struct intel_gt *kobj_to_gt(struct kobject *kobj)
 
 void intel_gt_sysfs_register(struct intel_gt *gt);
 void intel_gt_sysfs_unregister(struct intel_gt *gt);
-struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct kobject *kobj,
 					    const char *name);
 
 #endif /* SYSFS_GT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 180dd6f3ef57..b108f0a8a044 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -24,14 +24,15 @@ enum intel_gt_sysfs_op {
 };
 
 static int
-sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
+sysfs_gt_attribute_w_func(struct kobject *kobj, struct attribute *attr,
 			  int (func)(struct intel_gt *gt, u32 val), u32 val)
 {
 	struct intel_gt *gt;
 	int ret;
 
-	if (!is_object_gt(&dev->kobj)) {
+	if (!is_object_gt(kobj)) {
 		int i;
+		struct device *dev = kobj_to_dev(kobj);
 		struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
 
 		for_each_gt(gt, i915, i) {
@@ -40,7 +41,7 @@ sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
 				break;
 		}
 	} else {
-		gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+		gt = intel_gt_sysfs_get_drvdata(kobj, attr->name);
 		ret = func(gt, val);
 	}
 
@@ -48,7 +49,7 @@ sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
 }
 
 static u32
-sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
+sysfs_gt_attribute_r_func(struct kobject *kobj, struct attribute *attr,
 			  u32 (func)(struct intel_gt *gt),
 			  enum intel_gt_sysfs_op op)
 {
@@ -57,8 +58,9 @@ sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
 
 	ret = (op == INTEL_GT_SYSFS_MAX) ? 0 : (u32) -1;
 
-	if (!is_object_gt(&dev->kobj)) {
+	if (!is_object_gt(kobj)) {
 		int i;
+		struct device *dev = kobj_to_dev(kobj);
 		struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
 
 		for_each_gt(gt, i915, i) {
@@ -77,7 +79,7 @@ sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
 			}
 		}
 	} else {
-		gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+		gt = intel_gt_sysfs_get_drvdata(kobj, attr->name);
 		ret = func(gt);
 	}
 
@@ -92,6 +94,76 @@ sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
 #define sysfs_gt_attribute_r_max_func(d, a, f) \
 		sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
 
+#define INTEL_GT_SYSFS_SHOW(_name, _attr_type)							\
+	static ssize_t _name##_show_common(struct kobject *kobj,				\
+					   struct attribute *attr, char *buff)			\
+	{											\
+		u32 val = sysfs_gt_attribute_r_##_attr_type##_func(kobj, attr,			\
+								   __##_name##_show);		\
+												\
+		return sysfs_emit(buff, "%u\n", val);						\
+	}											\
+	static ssize_t _name##_show(struct kobject *kobj,					\
+				    struct kobj_attribute *attr, char *buff)			\
+	{											\
+		return _name ##_show_common(kobj, &attr->attr, buff);				\
+	}											\
+	static ssize_t _name##_dev_show(struct device *dev,					\
+					struct device_attribute *attr, char *buff)		\
+	{											\
+		return _name##_show_common(&dev->kobj, &attr->attr, buff);			\
+	}
+
+#define INTEL_GT_SYSFS_STORE(_name, _func)						\
+	static ssize_t _name##_store_common(struct kobject *kobj,			\
+					    struct attribute *attr,			\
+					    const char *buff, size_t count)		\
+	{										\
+		int ret;								\
+		u32 val;								\
+											\
+		ret = kstrtou32(buff, 0, &val);						\
+		if (ret)								\
+			return ret;							\
+											\
+		ret = sysfs_gt_attribute_w_func(kobj, attr, _func, val);		\
+											\
+		return ret ?: count;							\
+	}										\
+	static ssize_t _name##_store(struct kobject *kobj,				\
+				     struct kobj_attribute *attr, const char *buff,	\
+				     size_t count)					\
+	{										\
+		return _name##_store_common(kobj, &attr->attr, buff, count);		\
+	}										\
+	static ssize_t _name##_dev_store(struct device *dev,				\
+					 struct device_attribute *attr,			\
+					 const char *buff, size_t count)		\
+	{										\
+		return _name##_store_common(&dev->kobj, &attr->attr, buff, count);	\
+	}
+
+#define INTEL_GT_SYSFS_SHOW_MAX(_name) INTEL_GT_SYSFS_SHOW(_name, max)
+#define INTEL_GT_SYSFS_SHOW_MIN(_name) INTEL_GT_SYSFS_SHOW(_name, min)
+
+#define INTEL_GT_ATTR_RW(_name) \
+	static struct kobj_attribute attr_##_name = __ATTR_RW(_name)
+
+#define INTEL_GT_ATTR_RO(_name) \
+	static struct kobj_attribute attr_##_name = __ATTR_RO(_name)
+
+#define INTEL_GT_DUAL_ATTR_RW(_name) \
+	static struct device_attribute dev_attr_##_name = __ATTR(_name, 0644,		\
+								 _name##_dev_show,	\
+								 _name##_dev_store);	\
+	INTEL_GT_ATTR_RW(_name)
+
+#define INTEL_GT_DUAL_ATTR_RO(_name) \
+	static struct device_attribute dev_attr_##_name = __ATTR(_name, 0444,		\
+								 _name##_dev_show,	\
+								 NULL);			\
+	INTEL_GT_ATTR_RO(_name)
+
 #ifdef CONFIG_PM
 static u32 get_residency(struct intel_gt *gt, i915_reg_t reg)
 {
@@ -104,11 +176,8 @@ static u32 get_residency(struct intel_gt *gt, i915_reg_t reg)
 	return DIV_ROUND_CLOSEST_ULL(res, 1000);
 }
 
-static ssize_t rc6_enable_show(struct device *dev,
-			       struct device_attribute *attr,
-			       char *buff)
+static u8 get_rc6_mask(struct intel_gt *gt)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
 	u8 mask = 0;
 
 	if (HAS_RC6(gt->i915))
@@ -118,37 +187,35 @@ static ssize_t rc6_enable_show(struct device *dev,
 	if (HAS_RC6pp(gt->i915))
 		mask |= BIT(2);
 
-	return sysfs_emit(buff, "%x\n", mask);
+	return mask;
 }
 
-static u32 __rc6_residency_ms_show(struct intel_gt *gt)
+static ssize_t rc6_enable_show(struct kobject *kobj,
+			       struct kobj_attribute *attr,
+			       char *buff)
 {
-	return get_residency(gt, GEN6_GT_GFX_RC6);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+
+	return sysfs_emit(buff, "%x\n", get_rc6_mask(gt));
 }
 
-static ssize_t rc6_residency_ms_show(struct device *dev,
-				     struct device_attribute *attr,
-				     char *buff)
+static ssize_t rc6_enable_dev_show(struct device *dev,
+				   struct device_attribute *attr,
+				   char *buff)
 {
-	u32 rc6_residency = sysfs_gt_attribute_r_min_func(dev, attr,
-						      __rc6_residency_ms_show);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(&dev->kobj, attr->attr.name);
 
-	return sysfs_emit(buff, "%u\n", rc6_residency);
+	return sysfs_emit(buff, "%x\n", get_rc6_mask(gt));
 }
 
-static u32 __rc6p_residency_ms_show(struct intel_gt *gt)
+static u32 __rc6_residency_ms_show(struct intel_gt *gt)
 {
-	return get_residency(gt, GEN6_GT_GFX_RC6p);
+	return get_residency(gt, GEN6_GT_GFX_RC6);
 }
 
-static ssize_t rc6p_residency_ms_show(struct device *dev,
-				      struct device_attribute *attr,
-				      char *buff)
+static u32 __rc6p_residency_ms_show(struct intel_gt *gt)
 {
-	u32 rc6p_residency = sysfs_gt_attribute_r_min_func(dev, attr,
-						__rc6p_residency_ms_show);
-
-	return sysfs_emit(buff, "%u\n", rc6p_residency);
+	return get_residency(gt, GEN6_GT_GFX_RC6p);
 }
 
 static u32 __rc6pp_residency_ms_show(struct intel_gt *gt)
@@ -156,67 +223,69 @@ static u32 __rc6pp_residency_ms_show(struct intel_gt *gt)
 	return get_residency(gt, GEN6_GT_GFX_RC6pp);
 }
 
-static ssize_t rc6pp_residency_ms_show(struct device *dev,
-				       struct device_attribute *attr,
-				       char *buff)
-{
-	u32 rc6pp_residency = sysfs_gt_attribute_r_min_func(dev, attr,
-						__rc6pp_residency_ms_show);
-
-	return sysfs_emit(buff, "%u\n", rc6pp_residency);
-}
-
 static u32 __media_rc6_residency_ms_show(struct intel_gt *gt)
 {
 	return get_residency(gt, VLV_GT_MEDIA_RC6);
 }
 
-static ssize_t media_rc6_residency_ms_show(struct device *dev,
-					   struct device_attribute *attr,
-					   char *buff)
-{
-	u32 rc6_residency = sysfs_gt_attribute_r_min_func(dev, attr,
-						__media_rc6_residency_ms_show);
+INTEL_GT_SYSFS_SHOW_MIN(rc6_residency_ms);
+INTEL_GT_SYSFS_SHOW_MIN(rc6p_residency_ms);
+INTEL_GT_SYSFS_SHOW_MIN(rc6pp_residency_ms);
+INTEL_GT_SYSFS_SHOW_MIN(media_rc6_residency_ms);
 
-	return sysfs_emit(buff, "%u\n", rc6_residency);
-}
-
-static DEVICE_ATTR_RO(rc6_enable);
-static DEVICE_ATTR_RO(rc6_residency_ms);
-static DEVICE_ATTR_RO(rc6p_residency_ms);
-static DEVICE_ATTR_RO(rc6pp_residency_ms);
-static DEVICE_ATTR_RO(media_rc6_residency_ms);
+INTEL_GT_DUAL_ATTR_RO(rc6_enable);
+INTEL_GT_DUAL_ATTR_RO(rc6_residency_ms);
+INTEL_GT_DUAL_ATTR_RO(rc6p_residency_ms);
+INTEL_GT_DUAL_ATTR_RO(rc6pp_residency_ms);
+INTEL_GT_DUAL_ATTR_RO(media_rc6_residency_ms);
 
 static struct attribute *rc6_attrs[] = {
+	&attr_rc6_enable.attr,
+	&attr_rc6_residency_ms.attr,
+	NULL
+};
+
+static struct attribute *rc6p_attrs[] = {
+	&attr_rc6p_residency_ms.attr,
+	&attr_rc6pp_residency_ms.attr,
+	NULL
+};
+
+static struct attribute *media_rc6_attrs[] = {
+	&attr_media_rc6_residency_ms.attr,
+	NULL
+};
+
+static struct attribute *rc6_dev_attrs[] = {
 	&dev_attr_rc6_enable.attr,
 	&dev_attr_rc6_residency_ms.attr,
 	NULL
 };
 
-static struct attribute *rc6p_attrs[] = {
+static struct attribute *rc6p_dev_attrs[] = {
 	&dev_attr_rc6p_residency_ms.attr,
 	&dev_attr_rc6pp_residency_ms.attr,
 	NULL
 };
 
-static struct attribute *media_rc6_attrs[] = {
+static struct attribute *media_rc6_dev_attrs[] = {
 	&dev_attr_media_rc6_residency_ms.attr,
 	NULL
 };
 
 static const struct attribute_group rc6_attr_group[] = {
 	{ .attrs = rc6_attrs, },
-	{ .name = power_group_name, .attrs = rc6_attrs, },
+	{ .name = power_group_name, .attrs = rc6_dev_attrs, },
 };
 
 static const struct attribute_group rc6p_attr_group[] = {
 	{ .attrs = rc6p_attrs, },
-	{ .name = power_group_name, .attrs = rc6p_attrs, },
+	{ .name = power_group_name, .attrs = rc6p_dev_attrs, },
 };
 
 static const struct attribute_group media_rc6_attr_group[] = {
 	{ .attrs = media_rc6_attrs, },
-	{ .name = power_group_name, .attrs = media_rc6_attrs, },
+	{ .name = power_group_name, .attrs = media_rc6_dev_attrs, },
 };
 
 static int __intel_gt_sysfs_create_group(struct kobject *kobj,
@@ -271,104 +340,34 @@ static u32 __act_freq_mhz_show(struct intel_gt *gt)
 	return intel_rps_read_actual_frequency(&gt->rps);
 }
 
-static ssize_t act_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						    __act_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", actual_freq);
-}
-
 static u32 __cur_freq_mhz_show(struct intel_gt *gt)
 {
 	return intel_rps_get_requested_frequency(&gt->rps);
 }
 
-static ssize_t cur_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 cur_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						 __cur_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", cur_freq);
-}
-
 static u32 __boost_freq_mhz_show(struct intel_gt *gt)
 {
 	return intel_rps_get_boost_frequency(&gt->rps);
 }
 
-static ssize_t boost_freq_mhz_show(struct device *dev,
-				   struct device_attribute *attr,
-				   char *buff)
-{
-	u32 boost_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						   __boost_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", boost_freq);
-}
-
 static int __boost_freq_mhz_store(struct intel_gt *gt, u32 val)
 {
 	return intel_rps_set_boost_frequency(&gt->rps, val);
 }
 
-static ssize_t boost_freq_mhz_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buff, size_t count)
-{
-	ssize_t ret;
-	u32 val;
-
-	ret = kstrtou32(buff, 0, &val);
-	if (ret)
-		return ret;
-
-	return sysfs_gt_attribute_w_func(dev, attr,
-					 __boost_freq_mhz_store, val) ?: count;
-}
-
-static u32 __rp0_freq_mhz_show(struct intel_gt *gt)
+static u32 __RP0_freq_mhz_show(struct intel_gt *gt)
 {
 	return intel_rps_get_rp0_frequency(&gt->rps);
 }
 
-static ssize_t RP0_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 rp0_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						     __rp0_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", rp0_freq);
-}
-
-static u32 __rp1_freq_mhz_show(struct intel_gt *gt)
-{
-	return intel_rps_get_rp1_frequency(&gt->rps);
-}
-
-static ssize_t RP1_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 rp1_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						     __rp1_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", rp1_freq);
-}
-
-static u32 __rpn_freq_mhz_show(struct intel_gt *gt)
+static u32 __RPn_freq_mhz_show(struct intel_gt *gt)
 {
 	return intel_rps_get_rpn_frequency(&gt->rps);
 }
 
-static ssize_t RPn_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
+static u32 __RP1_freq_mhz_show(struct intel_gt *gt)
 {
-	u32 rpn_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						     __rpn_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", rpn_freq);
+	return intel_rps_get_rp1_frequency(&gt->rps);
 }
 
 static u32 __max_freq_mhz_show(struct intel_gt *gt)
@@ -376,71 +375,21 @@ static u32 __max_freq_mhz_show(struct intel_gt *gt)
 	return intel_rps_get_max_frequency(&gt->rps);
 }
 
-static ssize_t max_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 max_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						     __max_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", max_freq);
-}
-
 static int __set_max_freq(struct intel_gt *gt, u32 val)
 {
 	return intel_rps_set_max_frequency(&gt->rps, val);
 }
 
-static ssize_t max_freq_mhz_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buff, size_t count)
-{
-	int ret;
-	u32 val;
-
-	ret = kstrtou32(buff, 0, &val);
-	if (ret)
-		return ret;
-
-	ret = sysfs_gt_attribute_w_func(dev, attr, __set_max_freq, val);
-
-	return ret ?: count;
-}
-
 static u32 __min_freq_mhz_show(struct intel_gt *gt)
 {
 	return intel_rps_get_min_frequency(&gt->rps);
 }
 
-static ssize_t min_freq_mhz_show(struct device *dev,
-				 struct device_attribute *attr, char *buff)
-{
-	u32 min_freq = sysfs_gt_attribute_r_min_func(dev, attr,
-						     __min_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", min_freq);
-}
-
 static int __set_min_freq(struct intel_gt *gt, u32 val)
 {
 	return intel_rps_set_min_frequency(&gt->rps, val);
 }
 
-static ssize_t min_freq_mhz_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buff, size_t count)
-{
-	int ret;
-	u32 val;
-
-	ret = kstrtou32(buff, 0, &val);
-	if (ret)
-		return ret;
-
-	ret = sysfs_gt_attribute_w_func(dev, attr, __set_min_freq, val);
-
-	return ret ?: count;
-}
-
 static u32 __vlv_rpe_freq_mhz_show(struct intel_gt *gt)
 {
 	struct intel_rps *rps = &gt->rps;
@@ -448,23 +397,31 @@ static u32 __vlv_rpe_freq_mhz_show(struct intel_gt *gt)
 	return intel_gpu_freq(rps, rps->efficient_freq);
 }
 
-static ssize_t vlv_rpe_freq_mhz_show(struct device *dev,
-				     struct device_attribute *attr, char *buff)
-{
-	u32 rpe_freq = sysfs_gt_attribute_r_max_func(dev, attr,
-						 __vlv_rpe_freq_mhz_show);
-
-	return sysfs_emit(buff, "%u\n", rpe_freq);
-}
-
-#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
-	static struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, _show, _store); \
-	static struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, _mode, _show, _store)
-
-#define INTEL_GT_RPS_SYSFS_ATTR_RO(_name)				\
-		INTEL_GT_RPS_SYSFS_ATTR(_name, 0444, _name##_show, NULL)
-#define INTEL_GT_RPS_SYSFS_ATTR_RW(_name)				\
-		INTEL_GT_RPS_SYSFS_ATTR(_name, 0644, _name##_show, _name##_store)
+INTEL_GT_SYSFS_SHOW_MAX(act_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(boost_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(cur_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(RP0_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(RP1_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(RPn_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(max_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MIN(min_freq_mhz);
+INTEL_GT_SYSFS_SHOW_MAX(vlv_rpe_freq_mhz);
+INTEL_GT_SYSFS_STORE(boost_freq_mhz, __boost_freq_mhz_store);
+INTEL_GT_SYSFS_STORE(max_freq_mhz, __set_max_freq);
+INTEL_GT_SYSFS_STORE(min_freq_mhz, __set_min_freq);
+
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store, _show_dev, _store_dev)		\
+	static struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode,		\
+								    _show_dev, _store_dev);	\
+	static struct kobj_attribute attr_rps_##_name = __ATTR(rps_##_name, _mode,		\
+							       _show, _store)
+
+#define INTEL_GT_RPS_SYSFS_ATTR_RO(_name)						\
+		INTEL_GT_RPS_SYSFS_ATTR(_name, 0444, _name##_show, NULL,		\
+					_name##_dev_show, NULL)
+#define INTEL_GT_RPS_SYSFS_ATTR_RW(_name)						\
+		INTEL_GT_RPS_SYSFS_ATTR(_name, 0644, _name##_show, _name##_store,	\
+					_name##_dev_show, _name##_dev_store)
 
 /* The below macros generate static structures */
 INTEL_GT_RPS_SYSFS_ATTR_RO(act_freq_mhz);
@@ -475,32 +432,31 @@ INTEL_GT_RPS_SYSFS_ATTR_RO(RP1_freq_mhz);
 INTEL_GT_RPS_SYSFS_ATTR_RO(RPn_freq_mhz);
 INTEL_GT_RPS_SYSFS_ATTR_RW(max_freq_mhz);
 INTEL_GT_RPS_SYSFS_ATTR_RW(min_freq_mhz);
-
-static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
-
-#define GEN6_ATTR(s) { \
-		&dev_attr_##s##_act_freq_mhz.attr, \
-		&dev_attr_##s##_cur_freq_mhz.attr, \
-		&dev_attr_##s##_boost_freq_mhz.attr, \
-		&dev_attr_##s##_max_freq_mhz.attr, \
-		&dev_attr_##s##_min_freq_mhz.attr, \
-		&dev_attr_##s##_RP0_freq_mhz.attr, \
-		&dev_attr_##s##_RP1_freq_mhz.attr, \
-		&dev_attr_##s##_RPn_freq_mhz.attr, \
+INTEL_GT_RPS_SYSFS_ATTR_RO(vlv_rpe_freq_mhz);
+
+#define GEN6_ATTR(p, s) { \
+		&p##attr_##s##_act_freq_mhz.attr, \
+		&p##attr_##s##_cur_freq_mhz.attr, \
+		&p##attr_##s##_boost_freq_mhz.attr, \
+		&p##attr_##s##_max_freq_mhz.attr, \
+		&p##attr_##s##_min_freq_mhz.attr, \
+		&p##attr_##s##_RP0_freq_mhz.attr, \
+		&p##attr_##s##_RP1_freq_mhz.attr, \
+		&p##attr_##s##_RPn_freq_mhz.attr, \
 		NULL, \
 	}
 
-#define GEN6_RPS_ATTR GEN6_ATTR(rps)
-#define GEN6_GT_ATTR  GEN6_ATTR(gt)
+#define GEN6_RPS_ATTR GEN6_ATTR(, rps)
+#define GEN6_GT_ATTR  GEN6_ATTR(dev_, gt)
 
 static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
 static const struct attribute * const gen6_gt_attrs[]  = GEN6_GT_ATTR;
 
-static ssize_t punit_req_freq_mhz_show(struct device *dev,
-				       struct device_attribute *attr,
+static ssize_t punit_req_freq_mhz_show(struct kobject *kobj,
+				       struct kobj_attribute *attr,
 				       char *buff)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	u32 preq = intel_rps_read_punit_req_frequency(&gt->rps);
 
 	return sysfs_emit(buff, "%u\n", preq);
@@ -508,17 +464,17 @@ static ssize_t punit_req_freq_mhz_show(struct device *dev,
 
 struct intel_gt_bool_throttle_attr {
 	struct attribute attr;
-	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+	ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
 			char *buf);
 	i915_reg_t reg32;
 	u32 mask;
 };
 
-static ssize_t throttle_reason_bool_show(struct device *dev,
-					 struct device_attribute *attr,
+static ssize_t throttle_reason_bool_show(struct kobject *kobj,
+					 struct kobj_attribute *attr,
 					 char *buff)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	struct intel_gt_bool_throttle_attr *t_attr =
 				(struct intel_gt_bool_throttle_attr *) attr;
 	bool val = rps_read_mask_mmio(&gt->rps, t_attr->reg32, t_attr->mask);
@@ -534,7 +490,7 @@ struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
 	.mask = mask__, \
 }
 
-static DEVICE_ATTR_RO(punit_req_freq_mhz);
+INTEL_GT_ATTR_RO(punit_req_freq_mhz);
 static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status, GT0_PERF_LIMIT_REASONS_MASK);
 static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
 static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl2, POWER_LIMIT_2_MASK);
@@ -597,8 +553,8 @@ static const struct attribute *throttle_reason_attrs[] = {
 #define U8_8_VAL_MASK           0xffff
 #define U8_8_SCALE_TO_VALUE     "0.00390625"
 
-static ssize_t freq_factor_scale_show(struct device *dev,
-				      struct device_attribute *attr,
+static ssize_t freq_factor_scale_show(struct kobject *kobj,
+				      struct kobj_attribute *attr,
 				      char *buff)
 {
 	return sysfs_emit(buff, "%s\n", U8_8_SCALE_TO_VALUE);
@@ -610,11 +566,11 @@ static u32 media_ratio_mode_to_factor(u32 mode)
 	return !mode ? mode : 256 / mode;
 }
 
-static ssize_t media_freq_factor_show(struct device *dev,
-				      struct device_attribute *attr,
+static ssize_t media_freq_factor_show(struct kobject *kobj,
+				      struct kobj_attribute *attr,
 				      char *buff)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	struct intel_guc_slpc *slpc = &gt->uc.guc.slpc;
 	intel_wakeref_t wakeref;
 	u32 mode;
@@ -641,11 +597,11 @@ static ssize_t media_freq_factor_show(struct device *dev,
 	return sysfs_emit(buff, "%u\n", media_ratio_mode_to_factor(mode));
 }
 
-static ssize_t media_freq_factor_store(struct device *dev,
-				       struct device_attribute *attr,
+static ssize_t media_freq_factor_store(struct kobject *kobj,
+				       struct kobj_attribute *attr,
 				       const char *buff, size_t count)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	struct intel_guc_slpc *slpc = &gt->uc.guc.slpc;
 	u32 factor, mode;
 	int err;
@@ -670,11 +626,11 @@ static ssize_t media_freq_factor_store(struct device *dev,
 	return err ?: count;
 }
 
-static ssize_t media_RP0_freq_mhz_show(struct device *dev,
-				       struct device_attribute *attr,
+static ssize_t media_RP0_freq_mhz_show(struct kobject *kobj,
+				       struct kobj_attribute *attr,
 				       char *buff)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	u32 val;
 	int err;
 
@@ -691,11 +647,11 @@ static ssize_t media_RP0_freq_mhz_show(struct device *dev,
 	return sysfs_emit(buff, "%u\n", val);
 }
 
-static ssize_t media_RPn_freq_mhz_show(struct device *dev,
-				       struct device_attribute *attr,
+static ssize_t media_RPn_freq_mhz_show(struct kobject *kobj,
+				       struct kobj_attribute *attr,
 				       char *buff)
 {
-	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+	struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
 	u32 val;
 	int err;
 
@@ -712,17 +668,17 @@ static ssize_t media_RPn_freq_mhz_show(struct device *dev,
 	return sysfs_emit(buff, "%u\n", val);
 }
 
-static DEVICE_ATTR_RW(media_freq_factor);
-static struct device_attribute dev_attr_media_freq_factor_scale =
+INTEL_GT_ATTR_RW(media_freq_factor);
+static struct kobj_attribute attr_media_freq_factor_scale =
 	__ATTR(media_freq_factor.scale, 0444, freq_factor_scale_show, NULL);
-static DEVICE_ATTR_RO(media_RP0_freq_mhz);
-static DEVICE_ATTR_RO(media_RPn_freq_mhz);
+INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
+INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
 
 static const struct attribute *media_perf_power_attrs[] = {
-	&dev_attr_media_freq_factor.attr,
-	&dev_attr_media_freq_factor_scale.attr,
-	&dev_attr_media_RP0_freq_mhz.attr,
-	&dev_attr_media_RPn_freq_mhz.attr,
+	&attr_media_freq_factor.attr,
+	&attr_media_freq_factor_scale.attr,
+	&attr_media_RP0_freq_mhz.attr,
+	&attr_media_RPn_freq_mhz.attr,
 	NULL
 };
 
@@ -754,20 +710,29 @@ static const struct attribute * const rps_defaults_attrs[] = {
 	NULL
 };
 
-static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj,
-				const struct attribute * const *attrs)
+static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj)
 {
+	const struct attribute * const *attrs;
+	struct attribute *vlv_attr;
 	int ret;
 
 	if (GRAPHICS_VER(gt->i915) < 6)
 		return 0;
 
+	if (is_object_gt(kobj)) {
+		attrs = gen6_rps_attrs;
+		vlv_attr = &attr_rps_vlv_rpe_freq_mhz.attr;
+	} else {
+		attrs = gen6_gt_attrs;
+		vlv_attr = &dev_attr_gt_vlv_rpe_freq_mhz.attr;
+	}
+
 	ret = sysfs_create_files(kobj, attrs);
 	if (ret)
 		return ret;
 
 	if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915))
-		ret = sysfs_create_file(kobj, &dev_attr_vlv_rpe_freq_mhz.attr);
+		ret = sysfs_create_file(kobj, vlv_attr);
 
 	return ret;
 }
@@ -778,9 +743,7 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct kobject *kobj)
 
 	intel_sysfs_rc6_init(gt, kobj);
 
-	ret = is_object_gt(kobj) ?
-	      intel_sysfs_rps_init(gt, kobj, gen6_rps_attrs) :
-	      intel_sysfs_rps_init(gt, kobj, gen6_gt_attrs);
+	ret = intel_sysfs_rps_init(gt, kobj);
 	if (ret)
 		drm_warn(&gt->i915->drm,
 			 "failed to create gt%u RPS sysfs files (%pe)",
@@ -790,7 +753,7 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct kobject *kobj)
 	if (!is_object_gt(kobj))
 		return;
 
-	ret = sysfs_create_file(kobj, &dev_attr_punit_req_freq_mhz.attr);
+	ret = sysfs_create_file(kobj, &attr_punit_req_freq_mhz.attr);
 	if (ret)
 		drm_warn(&gt->i915->drm,
 			 "failed to create gt%u punit_req_freq_mhz sysfs (%pe)",

base-commit: 38f3ee12661fdc2805e06942e4e3d604e03cd9cf
-- 
2.39.0


^ permalink raw reply related	[relevance 42%]

* Re: [PATCH] efi: tpm: Avoid READ_ONCE() for accessing the event log
  @ 2023-01-09 17:48 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-01-09 17:48 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: linux-arm-kernel, linux-efi, will, catalin.marinas, stable,
	Peter Jones, Jarkko Sakkinen, Matthew Garrett

On Mon, Jan 09, 2023 at 10:59:48AM +0100, Ard Biesheuvel wrote:
> Nathan reports that recent kernels built with LTO will crash when doing
> EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a
> misaligned load from the TPM event log, which is annotated with
> READ_ONCE(), and under LTO, this gets translated into a LDAR instruction
> which does not tolerate misaligned accesses.
> 
> Interestingly, this does not happen when booting the same kernel
> straight from the UEFI shell, and so the fact that the event log may
> appear misaligned in memory may be caused by a bug in GRUB or SHIM.
> 
> However, using READ_ONCE() to access firmware tables is slightly unusual
> in any case, and here, we only need to ensure that 'event' is not
> dereferenced again after it gets unmapped, so a compiler barrier should
> be sufficient, and works around the reported issue.
> 
> Cc: <stable@vger.kernel.org>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1782
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Based on the thread, I tested this patch without barrier() and my
machine boots up just fine now with an LTO kernel. Thanks a lot for the
analysis and fix!

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  include/linux/tpm_eventlog.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> index 20c0ff54b7a0d313..0abcc85904cba874 100644
> --- a/include/linux/tpm_eventlog.h
> +++ b/include/linux/tpm_eventlog.h
> @@ -198,8 +198,10 @@ static __always_inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *ev
>  	 * The loop below will unmap these fields if the log is larger than
>  	 * one page, so save them here for reference:
>  	 */
> -	count = READ_ONCE(event->count);
> -	event_type = READ_ONCE(event->event_type);
> +	count = event->count;
> +	event_type = event->event_type;
> +
> +	barrier();
>  
>  	/* Verify that it's the log header */
>  	if (event_header->pcr_idx != 0 ||
> -- 
> 2.39.0
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.15 000/731] 5.15.86-rc1 review
  @ 2022-12-29 16:56 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-12-29 16:56 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Greg Kroah-Hartman, andrii, dave.stevenson, stable, patches,
	linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
	jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow

On Thu, Dec 29, 2022 at 03:40:51PM +0100, Pavel Machek wrote:
> Hi!
> 
> > This is the start of the stable review cycle for the 5.15.86 release.
> > There are 731 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> These are just kCFI annotations. I don't believe we need them in 5.10
> (and 5.15).

The original CFI implementation exists in 5.15 and the problem described
in those patches should still trigger with that implementation just like
kCFI, so they should likely still go to 5.15. However, they were
AUTOSEL'd and we have not had any reports of problems that are solved
with these patches (although that is likely because nobody who is using
this hardware has tried running a CONFIG_CFI_CLANG kernel), so I do not
really care if they are applied or not.

> > Nathan Chancellor <nathan@kernel.org>
> >     net: ethernet: ti: Fix return type of netcp_ndo_start_xmit()
> > Nathan Chancellor <nathan@kernel.org>
> >     drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
> > Nathan Chancellor <nathan@kernel.org>
> >     drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: Linux-stable-rc/ queue_5.10
  @ 2022-12-19 15:26 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-12-19 15:26 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: linux-stable, llvm, Greg Kroah-Hartman, Shuah Khan, lkft-triage

Hi Naresh,

On Mon, Dec 19, 2022 at 08:47:32PM +0530, Naresh Kamboju wrote:
> The MIPS tinyconfig with clang nightly  build failed,
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Build warnings / errors,
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build LLVM=1 LLVM_IAS=0
> ARCH=mips CROSS_COMPILE=mips-linux-gnu- HOSTCC=clang CC=clang
> tinyconfig
> 
> /tmp/calibrate-9ea8cf.s: Assembler messages:
> /tmp/calibrate-9ea8cf.s:134: Error: .module is not permitted after
> generating code
> /tmp/calibrate-9ea8cf.s:168: Error: .module is not permitted after
> generating code
> /tmp/calibrate-9ea8cf.s:192: Error: .module is not permitted after
> generating code
> /tmp/calibrate-9ea8cf.s:216: Error: .module is not permitted after
> generating code
> clang: error: assembler command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [/builds/linux/scripts/Makefile.build:286:
> init/calibrate.o] Error 1

Thanks for the report. This is a toolchain regression that should
hopefully be resolved soon:

https://reviews.llvm.org/D138179#4002068

https://reviews.llvm.org/D140270

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH] security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6
@ 2022-12-14 23:26 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-12-14 23:26 UTC (permalink / raw)
  To: Kees Cook, Nick Desaulniers
  Cc: Tom Rix, linux-hardening, linux-kernel, llvm, patches,
	Nathan Chancellor, stable

A bad bug in clang's implementation of -fzero-call-used-regs can result
in NULL pointer dereferences (see the links above the check for more
information). Restrict CONFIG_CC_HAS_ZERO_CALL_USED_REGS to either a
supported GCC version or a clang newer than 15.0.6, which will catch
both a theoretical 15.0.7 and the upcoming 16.0.0, which will both have
the bug fixed.

Cc: stable@vger.kernel.org # v5.15+
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 security/Kconfig.hardening | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index d766b7d0ffd1..53baa95cb644 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -257,6 +257,9 @@ config INIT_ON_FREE_DEFAULT_ON
 
 config CC_HAS_ZERO_CALL_USED_REGS
 	def_bool $(cc-option,-fzero-call-used-regs=used-gpr)
+	# https://github.com/ClangBuiltLinux/linux/issues/1766
+	# https://github.com/llvm/llvm-project/issues/59242
+	depends on !CC_IS_CLANG || CLANG_VERSION > 150006
 
 config ZERO_CALL_USED_REGS
 	bool "Enable register zeroing on function exit"

base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
-- 
2.39.0


^ permalink raw reply related	[relevance 99%]

* Re: [PATCH 6.0 000/157] 6.0.13-rc1 review
  @ 2022-12-13 16:51 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-12-13 16:51 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, llvm, stable, patches, linux-kernel,
	torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
	jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow

Hi Naresh,

On Tue, Dec 13, 2022 at 12:01:25PM +0530, Naresh Kamboju wrote:
> This is an additional report.
> Following issue is specific to clang nightly,
> 
> x86 clang-nightly builds failed with defconfig and tinyconfig due to
> below errors / warnings.
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> Regressions found on x86_64:
> 
>     - build/clang-nightly-tinyconfig
>     - build/clang-nightly-x86_64_defconfig
>     - build/clang-nightly-allnoconfig
>     - build/clang-nightly-lkftconfig
> 
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build LLVM=1 LLVM_IAS=1
> ARCH=x86_64 SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu- HOSTCC=clang
> CC=clang
> 
> ld.lld: error: version script assignment of 'LINUX_2.6' to symbol
> '__vdso_sgx_enter_enclave' failed: symbol not defined
> llvm-objdump: error: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
> or directory
> llvm-objcopy: error: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
> or directory
> make[4]: *** [/builds/linux/arch/x86/entry/vdso/Makefile:136:
> arch/x86/entry/vdso/vdso64.so] Error 1

Thanks for the report!

This is resolved in mainline now with commit 45be2ad007a9 ("x86/vdso:
Conditionally export __vdso_sgx_enter_enclave()"). I was going to
request stable backports once it was a little calmer but if people are
hitting this now, I guess now is as good a time as ever :) I believe it
should backport cleanly to 5.15+, which is where it is needed.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 6.0 000/289] 6.0.11-rc1 review
  @ 2022-12-01  6:57 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-12-01  6:57 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, Peter Zijlstra, Daniel Borkmann, stable,
	patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
	lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
	rwarsow, bpf, llvm

On Thu, Dec 01, 2022 at 11:44:53AM +0530, Naresh Kamboju wrote:
> On Thu, 1 Dec 2022 at 00:13, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 6.0.11 release.
> > There are 289 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 02 Dec 2022 18:05:05 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.0.11-rc1.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro's test farm.
> Regressions found on x86_64:
> 
>     - build-clang-15-allmodconfig-x86_64
>     - build-clang-nightly-allmodconfig-x86_64
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
>     bpf: Convert BPF_DISPATCHER to use static_call() (not ftrace)
>     [ Upstream commit c86df29d11dfba27c0a1f5039cd6fe387fbf4239 ]
> 
> Causing the following build warnings / errors with clang-15 allmodconfig
> on x86_64,
> 
> Build error:
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build LLVM=1 LLVM_IAS=1
> ARCH=x86_64 SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu-
> 'HOSTCC=sccache clang' 'CC=sccache clang'
> kernel/bpf/dispatcher.c:126:33: error: pointer type mismatch ('void *'
> and 'unsigned int (*)(const void *, const struct bpf_insn *,
> bpf_func_t)' (aka 'unsigned int (*)(const void *, const struct
> bpf_insn *, unsigned int (*)(const void *, const struct bpf_insn
> *))')) [-Werror,-Wpointer-type-mismatch]
>         __BPF_DISPATCHER_UPDATE(d, new ?: &bpf_dispatcher_nop_func);
>                                    ~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/bpf.h:938:54: note: expanded from macro '__BPF_DISPATCHER_UPDATE'
>         __static_call_update((_d)->sc_key, (_d)->sc_tramp, (_new))
>                                                             ^~~~
> 1 error generated.

Thanks for the report! This is fixed with upstream commit a679120edfcf
("bpf: Add explicit cast to 'void *' for __BPF_DISPATCHER_UPDATE()"),
which was marked as a fix for c86df29d11df.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.4 and earlier only] mm: Fix '.data.once' orphan section warning
  @ 2022-11-30 16:20 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-11-30 16:20 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: Greg Kroah-Hartman, Sasha Levin, llvm, stable

On Tue, Nov 29, 2022 at 10:28:33PM -0800, Hugh Dickins wrote:
> On Mon, 28 Nov 2022, Nathan Chancellor wrote:
> 
> > Portions of upstream commit a4055888629b ("mm/memcg: warning on !memcg
> > after readahead page charged") were backported as commit cfe575954ddd
> > ("mm: add VM_WARN_ON_ONCE_PAGE() macro"). Unfortunately, the backport
> > did not account for the lack of commit 33def8498fdd ("treewide: Convert
> > macro and uses of __section(foo) to __section("foo")") in kernels prior
> > to 5.10, resulting in the following orphan section warnings on PowerPC
> > clang builds with CONFIG_DEBUG_VM=y:
> > 
> >   powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> >   powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> >   powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
> > 
> > This is a difference between how clang and gcc handle macro
> > stringification, which was resolved for the kernel by not stringifying
> > the argument to the __section() macro. Since that change was deemed not
> > suitable for the stable kernels by commit 59f89518f510 ("once: fix
> > section mismatch on clang builds"), do that same thing as that change
> > and remove the quotes from the argument to __section().
> > 
> > Fixes: cfe575954ddd ("mm: add VM_WARN_ON_ONCE_PAGE() macro")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
> Yes indeed: thanks Nathan, sorry about that.
> 
> Acked-by: Hugh Dickins <hughd@google.com>

No worries, it is a really subtle problem that I would not expect
someone doing normal backports to catch. Thanks for taking a look!

> > ---
> > 
> > As far as I can tell, this should be applied to 5.4 and earlier. It
> > should apply cleanly but let me know if not.
> 
> I think it should be good for 4.19 also, but I don't know what happens
> or would happen in 4.14 and 4.9 trees, since those have no other example
> of .data.once or ".data.once" (and I've lost what little I ever knew of
> that linker script stuff).
> 
> Since we're not hearing complaints about those (or are you?), perhaps
> those trees are not clang-ready in other ways, and for gcc it all works
> out by itself: I'd be inclined to just leave them as is myself, if there
> are no reports of breakage; but you may know better, and prefer to remove
> the ' __section(".data.once")' from the 4.14 and 4.9 versions.

Those trees have very rudimentary clang support, they are far from
warning and issue clean in all configurations (even mainline has known
issues for some architectures, including powerpc). Since this
specifically requires CONFIG_DEBUG_VM to see, I am perfectly fine with
just applying it to 4.19 and 5.4.

Cheers,
Nathan

> > 
> >  include/linux/mmdebug.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
> > index 5d0767cb424a..4ed52879ce55 100644
> > --- a/include/linux/mmdebug.h
> > +++ b/include/linux/mmdebug.h
> > @@ -38,7 +38,7 @@ void dump_mm(const struct mm_struct *mm);
> >  		}							\
> >  	} while (0)
> >  #define VM_WARN_ON_ONCE_PAGE(cond, page)	({			\
> > -	static bool __section(".data.once") __warned;			\
> > +	static bool __section(.data.once) __warned;			\
> >  	int __ret_warn_once = !!(cond);					\
> >  									\
> >  	if (unlikely(__ret_warn_once && !__warned)) {			\
> > 
> > base-commit: 4d2a309b5c28a2edc0900542d22fec3a5a22243b
> > -- 
> > 2.38.1

^ permalink raw reply	[relevance 99%]

* [PATCH 5.4 and earlier only] mm: Fix '.data.once' orphan section warning
@ 2022-11-28 22:53 94% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-11-28 22:53 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Hugh Dickins, llvm, stable, Nathan Chancellor

Portions of upstream commit a4055888629b ("mm/memcg: warning on !memcg
after readahead page charged") were backported as commit cfe575954ddd
("mm: add VM_WARN_ON_ONCE_PAGE() macro"). Unfortunately, the backport
did not account for the lack of commit 33def8498fdd ("treewide: Convert
macro and uses of __section(foo) to __section("foo")") in kernels prior
to 5.10, resulting in the following orphan section warnings on PowerPC
clang builds with CONFIG_DEBUG_VM=y:

  powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
  powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'
  powerpc64le-linux-gnu-ld: warning: orphan section `".data.once"' from `mm/huge_memory.o' being placed in section `".data.once"'

This is a difference between how clang and gcc handle macro
stringification, which was resolved for the kernel by not stringifying
the argument to the __section() macro. Since that change was deemed not
suitable for the stable kernels by commit 59f89518f510 ("once: fix
section mismatch on clang builds"), do that same thing as that change
and remove the quotes from the argument to __section().

Fixes: cfe575954ddd ("mm: add VM_WARN_ON_ONCE_PAGE() macro")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

As far as I can tell, this should be applied to 5.4 and earlier. It
should apply cleanly but let me know if not.

 include/linux/mmdebug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 5d0767cb424a..4ed52879ce55 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -38,7 +38,7 @@ void dump_mm(const struct mm_struct *mm);
 		}							\
 	} while (0)
 #define VM_WARN_ON_ONCE_PAGE(cond, page)	({			\
-	static bool __section(".data.once") __warned;			\
+	static bool __section(.data.once) __warned;			\
 	int __ret_warn_once = !!(cond);					\
 									\
 	if (unlikely(__ret_warn_once && !__warned)) {			\

base-commit: 4d2a309b5c28a2edc0900542d22fec3a5a22243b
-- 
2.38.1


^ permalink raw reply related	[relevance 94%]

* [PATCH] vmlinux.lds.h: Fix placement of '.data..decrypted' section
@ 2022-11-08 17:49 96% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-11-08 17:49 UTC (permalink / raw)
  To: Arnd Bergmann, Kees Cook
  Cc: linux-arch, linux-kernel, Nathan Chancellor, stable,
	Ard Biesheuvel, Zhao Wenhui, xiafukun

Commit d4c639990036 ("vmlinux.lds.h: Avoid orphan section with !SMP")
fixed an orphan section warning by adding the '.data..decrypted' section
to the linker script under the PERCPU_DECRYPTED_SECTION define but that
placement introduced a panic with !SMP, as the percpu sections are not
instantiated with that configuration so attempting to access variables
defined with DEFINE_PER_CPU_DECRYPTED() will result in a page fault.

Move the '.data..decrypted' section to the DATA_MAIN define so that the
variables in it are properly instantiated at boot time with
CONFIG_SMP=n.

Cc: stable@vger.kernel.org
Fixes: d4c639990036 ("vmlinux.lds.h: Avoid orphan section with !SMP")
Link: https://lore.kernel.org/cbbd3548-880c-d2ca-1b67-5bb93b291d5f@huawei.com/
Debugged-by: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Zhao Wenhui <zhaowenhui8@huawei.com>
Tested-by: xiafukun <xiafukun@huawei.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index d06ada2341cb..3dc5824141cd 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -347,6 +347,7 @@
 #define DATA_DATA							\
 	*(.xiptext)							\
 	*(DATA_MAIN)							\
+	*(.data..decrypted)						\
 	*(.ref.data)							\
 	*(.data..shared_aligned) /* percpu related */			\
 	MEM_KEEP(init.data*)						\
@@ -995,7 +996,6 @@
 #ifdef CONFIG_AMD_MEM_ENCRYPT
 #define PERCPU_DECRYPTED_SECTION					\
 	. = ALIGN(PAGE_SIZE);						\
-	*(.data..decrypted)						\
 	*(.data..percpu..decrypted)					\
 	. = ALIGN(PAGE_SIZE);
 #else

base-commit: f0c4d9fc9cc9462659728d168387191387e903cc
-- 
2.38.1


^ permalink raw reply related	[relevance 96%]

* Re: [PATCH 5.4 086/255] once: add DO_ONCE_SLOW() for sleepable contexts
  @ 2022-10-31 18:27 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-31 18:27 UTC (permalink / raw)
  To: Oleksandr Tymoshenko
  Cc: gregkh, christophe.leroy, davem, edumazet, linux-kernel, sashal,
	stable, w, llvm

Hi Oleksandr,

On Sat, Oct 29, 2022 at 01:12:11AM +0000, Oleksandr Tymoshenko wrote:
> Hello,
> 
> This commit causes the following panic in kernel built with clang
> (GCC build is not affected): 
> 
> [    8.320308] BUG: unable to handle page fault for address: ffffffff97216c6a                                        [26/4066]
> [    8.330029] #PF: supervisor write access in kernel mode                                                                    
> [    8.337263] #PF: error_code(0x0003) - permissions violation 
> [    8.344816] PGD 12e816067 P4D 12e816067 PUD 12e817063 PMD 800000012e2001e1                                                 
> [    8.354337] Oops: 0003 [#1] SMP PTI                
> [    8.359178] CPU: 2 PID: 437 Comm: curl Not tainted 5.4.220 #15                                                             
> [    8.367241] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015                                   
> [    8.378529] RIP: 0010:__do_once_slow_done+0xf/0xa0   
> [    8.384962] Code: 1b 84 db 74 0c 48 c7 c7 80 ce 8d 97 e8 fa e9 4a 00 84 db 0f 94 c0 5b 5d c3 66 90 55 48 89 e5 41 57 41 56 
> 53 49 89 d7 49 89 f6 <c6> 07 01 48 c7 c7 80 ce 8d 97 e8 d2 e9 4a 00 48 8b 3d 9b de c9 00                                      
> [    8.409066] RSP: 0018:ffffb764c02d3c90 EFLAGS: 00010246
> [    8.415697] RAX: 4f51d3d06bc94000 RBX: d474b86ddf7162eb RCX: 000000007229b1d6                                              
> [    8.424805] RDX: 0000000000000000 RSI: ffffffff9791b4a0 RDI: ffffffff97216c6a                                              
> [    8.434108] RBP: ffffb764c02d3ca8 R08: 0e81c130f1159fc1 R09: 1d19d60ce0b52c77                                              
> [    8.443408] R10: 8ea59218e6892b1f R11: d5260237a3c1e35c R12: ffff9c3dadd42600                                              
> [    8.452468] R13: ffffffff97910f80 R14: ffffffff9791b4a0 R15: 0000000000000000                                            
> [    8.461416] FS:  00007eff855b40c0(0000) GS:ffff9c3db7a80000(0000) knlGS:0000000000000000                                   
> [    8.471632] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                                                              
> [    8.478763] CR2: ffffffff97216c6a CR3: 000000022ded0000 CR4: 00000000000006a0                                              
> [    8.487789] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000                                              
> [    8.496684] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400                                              
> [    8.505443] Call Trace:                                                                                                    
> [    8.508568]  __inet_hash_connect+0x523/0x530                                                                               
> [    8.513839]  ? inet_hash_connect+0x50/0x50                                                                                 
> [    8.518818]  ? secure_ipv4_port_ephemeral+0x69/0xe0
> [    8.525003]  tcp_v4_connect+0x2c5/0x410
> [    8.529858]  __inet_stream_connect+0xd7/0x360
> [    8.535329]  ? _raw_spin_unlock+0xe/0x10
> ... skipped ...
> 
> 
> The root cause is the difference in __section macro semantics between 5.4 and
> later LTS releases. On 5.4 it stringifies the argument so the ___done
> symbol is created in a bogus section ".data.once", with double quotes:
> 
> % readelf -S vmlinux | grep data.once
>   [ 5] ".data.once"      PROGBITS         ffffffff82216c6a  01416c6a

Thanks for the report! The reason this does not happen in mainline is
due to commit 33def8498fdd ("treewide: Convert macro and uses of
__section(foo) to __section("foo")"), which came as a result of these
issues:

https://github.com/ClangBuiltLinux/linux/issues/619
https://llvm.org/pr42950

To keep stable from diverging, it would probably be best to pick
33def8498fdd and fight through whatever conflicts there are. If that is
not a suitable solution, the next best thing would be to remove the
quotes like was done in commit bfafddd8de42 ("include/linux/compiler.h:
fix Oops for Clang-compiled kernels") for all instances of
__section(...) or __attribute__((__section__(...))), which should
resolve the specific problem you are seeing.

In the future, please feel free to cc issues that you see with clang to
llvm@lists.linux.dev so that we can chime in sooner :)

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: FAILED: patch "[PATCH] x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB" failed to apply to 5.15-stable tree
  @ 2022-10-26 16:34 92% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-26 16:34 UTC (permalink / raw)
  To: gregkh; +Cc: ardb, bp, ndesaulniers, stable

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, Oct 26, 2022 at 05:28:03PM +0200, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 5.15-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> Possible dependencies:
> 
> 33806e7cb8d5 ("x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB")
> c6dbd3e5e69c ("x86/mmx_32: Remove X86_USE_3DNOW")
> 6bf8a55d8344 ("x86: Fix misspelled Kconfig symbols")
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> From 33806e7cb8d50379f55c3e8f335e91e1b359dc7b Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Thu, 29 Sep 2022 08:20:10 -0700
> Subject: [PATCH] x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB

Attached is a backport that applies to both 5.15 and 5.10. Let me know
if there are any issues.

Cheers,
Nathan

[-- Attachment #2: 0001-x86-Kconfig-Drop-check-for-mabi-ms-for-CONFIG_EFI_ST.patch --]
[-- Type: text/plain, Size: 2278 bytes --]

From c411c8cc183357003fc174a6c89978dd663fba33 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Thu, 29 Sep 2022 08:20:10 -0700
Subject: [PATCH 5.15/5.10] x86/Kconfig: Drop check for -mabi=ms for
 CONFIG_EFI_STUB

commit 33806e7cb8d50379f55c3e8f335e91e1b359dc7b upstream.

A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no
longer pretends to support -mabi=ms, breaking the dependency in
Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via
EFI in certain circumstances.

This check was added by

  8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")

to ensure that __attribute__((ms_abi)) was available, as -mabi=ms is
not actually used in any cflags.

According to the GCC documentation, this attribute has been supported
since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is
not necessary; even when that change landed in 5.6, the kernel required
GCC 4.9 so it was unnecessary then as well.

Clang supports __attribute__((ms_abi)) for all versions that are
supported for building the kernel so no additional check is needed.
Remove the 'depends on' line altogether to allow CONFIG_EFI_STUB to be
selected when CONFIG_EFI is enabled, regardless of compiler.

Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
[nathan: Fix conflict due to lack of c6dbd3e5e69c in older trees]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 57f5e881791a..0f2234cd8453 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1926,7 +1926,6 @@ config EFI
 config EFI_STUB
 	bool "EFI stub support"
 	depends on EFI && !X86_USE_3DNOW
-	depends on $(cc-option,-mabi=ms) || X86_32
 	select RELOCATABLE
 	help
 	  This kernel feature allows a bzImage to be loaded directly

base-commit: bd8a595958a5b02e58cdd6fed82d4ebc77b1988a
-- 
2.38.1


^ permalink raw reply related	[relevance 92%]

* Re: backports of 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files")
  @ 2022-10-25 16:53 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-25 16:53 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Greg KH, Sasha Levin, Masahiro Yamada, # 3.4.x,
	clang-built-linux, Alexey Alexandrov, Bill Wendling, Greg Thelen

On Mon, Oct 24, 2022 at 02:06:52PM -0700, Nick Desaulniers wrote:
> Dear stable kernel maintainers,
> Our production kernel team and ChromeOS kernel teams are reporting
> that they are unable to symbolize addresses of symbols defined in
> assembly sources due to a regression I caused with
>     commit a66049e2cf0e ("Kbuild: make DWARF version a choice")

I think you mean commit b8a9092330da ("Kbuild: do not emit debug info
for assembly with LLVM_IAS=1"), which is what you blamed in
32ef9e5054ec? a66049e2cf0e does not appear to have any affect on this
problem?

> I fixed this upstream with
>     commit 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files")
> but I think this is infeasible to backport through to 4.19.y.
> 
> Do the attached branch-specific variants look acceptable?

I think the stable specific versions should be okay. We should be able
to deal with any fallout that happens if there is any.

Acked-by: Nathan Chancellor <nathan@kernel.org>

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: FAILED: patch "[PATCH] drm/simpledrm: Fix return type of" failed to apply to 6.0-stable tree
  @ 2022-10-17 18:09 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-17 18:09 UTC (permalink / raw)
  To: gregkh; +Cc: samitolvanen, tpgxyz, tzimmermann, stable

On Sun, Oct 16, 2022 at 06:12:03PM +0200, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 6.0-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> Possible dependencies:
> 
> f9929f69de94 ("drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()")
> 
> thanks,
> 
> greg k-h
> 
> ------------------ original commit in Linus's tree ------------------
> 
> From f9929f69de94212f98b3ad72a3e81c3bd3d333e0 Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Mon, 25 Jul 2022 16:36:29 -0700
> Subject: [PATCH] drm/simpledrm: Fix return type of
>  simpledrm_simple_display_pipe_mode_valid()

Just for the record, this change is already in the stable trees it is
relevant for, as it was a part of 5.19:

5.19 and 6.0: 0c09bc33aa8e ("drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()")
5.15: 11c1cc3f6e42 ("drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()")

I am not sure how a second copy (f9929f69de94) ended up in the tree
during the 6.1 cycle, I am guessing it was cherry picked to a
development branch from a fixes branch, rather than backmerged.

TL;DR: Nothing for stable to do here.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH stable 5.15 0/2] kbuild: Fix compilation for latest pahole release
  @ 2022-10-17 18:02 99%         ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-17 18:02 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Greg KH, stable, bpf, Arnaldo Carvalho de Melo, Daniel Borkmann,
	Martin Rodriguez Reboredo, Andrii Nakryiko

On Mon, Sep 19, 2022 at 12:14:40AM +0200, Jiri Olsa wrote:
> On Tue, Sep 06, 2022 at 02:03:30PM +0200, Greg KH wrote:
> > On Mon, Sep 05, 2022 at 09:04:10AM +0200, Jiri Olsa wrote:
> > > On Sun, Sep 04, 2022 at 04:10:09PM +0200, Greg KH wrote:
> > > > On Sun, Sep 04, 2022 at 03:18:59PM +0200, Jiri Olsa wrote:
> > > > > hi,
> > > > > new version of pahole (1.24) is causing compilation fail for 5.15
> > > > > stable kernel, discussed in here [1][2]. Sending fix for that plus
> > > > > one dependency patch.
> > > > > 
> > > > > Note for patch 1:
> > > > > there was one extra line change in scripts/pahole-flags.sh file in
> > > > > its linux tree merge commit:
> > > > > 
> > > > >   fc02cb2b37fe Merge tag 'net-next-for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> > > > > 
> > > > > not sure how/if to track that, I squashed the change in.
> > > > 
> > > > Squashing is fine, thanks.
> > > > 
> > > > And do we also need this for kernels older than 5.15?  Like 5.10 and 5.4?
> > > 
> > > yes, 5.10 needs similar patchset, but this for 5.15 won't apply there,
> > > so I'll send it separately
> > > 
> > > 5.4 passes compilation, but I don't think it will boot properly, still
> > > need to check on that
> > > 
> > > in any case, more patches are coming ;-)
> > 
> > Ok, these two are now queued up, feel free to send the rest when you
> > have them ready.
> 
> hi,
> as for 5.10 changes, I have them ready, pushed in here:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git pahole_fix_5_10
> 
> but it looks like CONFIG_DEBUG_INFO_BTF is not being used in 5.10,
> because I had to backport other similar option, that would break
> the build even earlier (--skip_encoding_btf_vars), or people use
> just old pahole ;-)
> 
> I suggest we wait with this change until somebody actually wants
> this fixed, AFAICS there's no report of broken 5.10 build yet

Consider this your first report :)

My build containers include the latest pahole, as I have noticed more
issues with older pahole in newer kernels than newer pahole in older
kernels, as least until now. I have tripped over this issue on both 5.19
and 5.10, as the stable-only commit b775fbf532dc ("kbuild: Add
skip_encoding_btf_enum64 option to pahole") was only applied to 5.15,
even though it is needed in all kernels prior to 6.0.

Please consider explicitly sending the 5.10 series to stable and
requesting b775fbf532dc to be applied to 5.19.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Apply 0a6de78cff60 to 5.15+
@ 2022-10-17 17:52 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-17 17:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, Masahiro Yamada, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

Hi Greg and Sasha,

Please consider applying the following commits to 5.19 and 6.0:

4f001a21080f ("Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5")
bb1435f3f575 ("Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT")
0a6de78cff60 ("lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5")

The main change is the final one but the second patch is a prerequisite
and a useful fix in its own right. The first change allows the second to
apply cleanly and it is a good clean up as well.

I have verified that they apply cleanly to those trees with 'patch -p1'.
Attached is a manual backport for 5.15; the changes should not be
necessary for older trees, as they do not have support for DWARF 5.

If there are any problems or questions, please let me know.

Cheers,
Nathan

[-- Attachment #2: 0a6de78cff60-5.15.mbox --]
[-- Type: application/mbox, Size: 7619 bytes --]

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] x86/Kconfig: Drop check for '-mabi=ms' for CONFIG_EFI_STUB
  2022-09-29 15:20 93% [PATCH] x86/Kconfig: Drop check for '-mabi=ms' for CONFIG_EFI_STUB Nathan Chancellor
@ 2022-10-17 15:03 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-17 15:03 UTC (permalink / raw)
  To: Ard Biesheuvel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86
  Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, linux-kernel, llvm,
	patches, stable

Hi x86 folks,

Would it be possible to pick this up for 6.1 so it can start filtering
into the stable trees? I know it came down towards the beginning of the
merge window so I understand the silence but I have had a couple of
people independently report this problem when they used a newer snapshot
of LLVM. This problem is not immediately obvious if you do not have a
previous configuration to diff against.

Cheers,
Nathan

On Thu, Sep 29, 2022 at 08:20:10AM -0700, Nathan Chancellor wrote:
> A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no
> longer pretends to support '-mabi=ms', breaking the dependency in
> Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via
> EFI in certain circumstances.
> 
> This check was added by commit 8f24f8c2fc82 ("efi/libstub: Annotate
> firmware routines as __efiapi") to ensure that '__attribute__((ms_abi))'
> was available, as '-mabi=ms' is not actually used in any cflags.
> According to the GCC documentation, this attribute has been supported
> since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is
> not necessary; even when that change landed in 5.6, the kernel required
> GCC 4.9 so it was unnecessary then as well.  Clang supports
> '__attribute__((ms_abi))' for all versions that are supported for
> building the kernel so no additional check is needed. Remove the
> 'depends on' line altogether to allow CONFIG_EFI_STUB to be selected
> when CONFIG_EFI is enabled, regardless of compiler.
> 
> Cc: stable@vger.kernel.org
> Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1725
> Link: https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Function-Attributes.html
> Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/x86/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f9920f1341c8..81012154d9ed 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1956,7 +1956,6 @@ config EFI
>  config EFI_STUB
>  	bool "EFI stub support"
>  	depends on EFI
> -	depends on $(cc-option,-mabi=ms) || X86_32
>  	select RELOCATABLE
>  	help
>  	  This kernel feature allows a bzImage to be loaded directly
> 
> base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff
> -- 
> 2.37.3
> 
> 

^ permalink raw reply	[relevance 99%]

* Backport of 607e57c6c62c009 for 5.10 and 5.15
@ 2022-10-13 18:51 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-13 18:51 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, llvm, Kees Cook, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Hi Greg and Sasha,

Please find attached backports for commit 607e57c6c62c ("hardening:
Remove Clang's enable flag for -ftrivial-auto-var-init=zero") along with
prerequisite changes for 5.10 and 5.15. This change is necessary to keep
CONFIG_INIT_STACK_ALL_ZERO working with clang-16. This change is already
queued up for 5.19 and newer and it is not relevant for 5.4 and older
(at least upstream, I'll be doing backports for older Android branches
shortly). If there are any questions or problems, please let me know!

Cheers,
Nathan

[-- Attachment #2: 607e57c6c62c009-5.10.mbox --]
[-- Type: application/mbox, Size: 11787 bytes --]

[-- Attachment #3: 607e57c6c62c009-5.15.mbox --]
[-- Type: application/mbox, Size: 6620 bytes --]

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero
  @ 2022-10-03 16:41 98% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-10-03 16:41 UTC (permalink / raw)
  To: Kees Cook
  Cc: Masahiro Yamada, Nick Desaulniers, linux-kbuild, llvm, stable,
	linux-kernel, linux-hardening

On Thu, Sep 29, 2022 at 11:06:24PM -0700, Kees Cook wrote:
> Now that Clang's -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> option is no longer required, remove it from the command line. Clang 16
> and later will warn when it is used, which will cause Kconfig to think
> it can't use -ftrivial-auto-var-init=zero at all. Check for whether it
> is required and only use it when so.
> 
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: linux-kbuild@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Cc: stable@vger.kernel.org
> Fixes: f02003c860d9 ("hardening: Avoid harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO")
> Signed-off-by: Kees Cook <keescook@chromium.org>

Thanks for sending this change!

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>

Please consider getting this to Linus ASAP so that this can start
filtering into stable now that the LLVM change has landed, as I lost the
ability to use CONFIG_INIT_STACK_ALL_ZERO after upgrading my toolchain
over the weekend :)

Additionally, I am not sure the fixes tag is going to ensure that this
change automatically makes it back to 5.15 and 5.10, which have
commit f0fe00d4972a ("security: allow using Clang's zero initialization
for stack variables") but not commit f02003c860d9 ("hardening: Avoid
harmless Clang option under CONFIG_INIT_STACK_ALL_ZERO"). I guess if I
am reading the stable documentation right, we could do something like:

Cc: stable@vger.kernel.org # dcb7c0b9461c + f02003c860d9
Fixes: f0fe00d4972a ("security: allow using Clang's zero initialization for stack variables")

but I am not sure. I guess we can always just send manual backports
once it is merged.

> ---
>  Makefile                   |  4 ++--
>  security/Kconfig.hardening | 14 ++++++++++----
>  2 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index c7705f749601..02c857e2243c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -831,8 +831,8 @@ endif
>  # Initialize all stack variables with a zero value.
>  ifdef CONFIG_INIT_STACK_ALL_ZERO
>  KBUILD_CFLAGS	+= -ftrivial-auto-var-init=zero
> -ifdef CONFIG_CC_IS_CLANG
> -# https://bugs.llvm.org/show_bug.cgi?id=45497
> +ifdef CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
> +# https://github.com/llvm/llvm-project/issues/44842
>  KBUILD_CFLAGS	+= -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
>  endif
>  endif
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index bd2aabb2c60f..995bc42003e6 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -22,11 +22,17 @@ menu "Memory initialization"
>  config CC_HAS_AUTO_VAR_INIT_PATTERN
>  	def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
>  
> -config CC_HAS_AUTO_VAR_INIT_ZERO
> -	# GCC ignores the -enable flag, so we can test for the feature with
> -	# a single invocation using the flag, but drop it as appropriate in
> -	# the Makefile, depending on the presence of Clang.
> +config CC_HAS_AUTO_VAR_INIT_ZERO_BARE
> +	def_bool $(cc-option,-ftrivial-auto-var-init=zero)
> +
> +config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
> +	# Clang 16 and later warn about using the -enable flag, but it
> +	# is required before then.
>  	def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
> +	depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE
> +
> +config CC_HAS_AUTO_VAR_INIT_ZERO
> +	def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
>  
>  choice
>  	prompt "Initialize kernel stack variables at function entry"
> -- 
> 2.34.1
> 

^ permalink raw reply	[relevance 98%]

* [PATCH] x86/Kconfig: Drop check for '-mabi=ms' for CONFIG_EFI_STUB
@ 2022-09-29 15:20 93% Nathan Chancellor
  2022-10-17 15:03 99% ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-09-29 15:20 UTC (permalink / raw)
  To: Ard Biesheuvel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
	Dave Hansen, x86
  Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, linux-kernel, llvm,
	patches, Nathan Chancellor, stable

A recent change in LLVM made CONFIG_EFI_STUB unselectable because it no
longer pretends to support '-mabi=ms', breaking the dependency in
Kconfig. Lack of CONFIG_EFI_STUB can prevent kernels from booting via
EFI in certain circumstances.

This check was added by commit 8f24f8c2fc82 ("efi/libstub: Annotate
firmware routines as __efiapi") to ensure that '__attribute__((ms_abi))'
was available, as '-mabi=ms' is not actually used in any cflags.
According to the GCC documentation, this attribute has been supported
since GCC 4.4.7. The kernel currently requires GCC 5.1 so this check is
not necessary; even when that change landed in 5.6, the kernel required
GCC 4.9 so it was unnecessary then as well.  Clang supports
'__attribute__((ms_abi))' for all versions that are supported for
building the kernel so no additional check is needed. Remove the
'depends on' line altogether to allow CONFIG_EFI_STUB to be selected
when CONFIG_EFI is enabled, regardless of compiler.

Cc: stable@vger.kernel.org
Fixes: 8f24f8c2fc82 ("efi/libstub: Annotate firmware routines as __efiapi")
Link: https://github.com/ClangBuiltLinux/linux/issues/1725
Link: https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Function-Attributes.html
Link: https://github.com/llvm/llvm-project/commit/d1ad006a8f64bdc17f618deffa9e7c91d82c444d
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..81012154d9ed 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1956,7 +1956,6 @@ config EFI
 config EFI_STUB
 	bool "EFI stub support"
 	depends on EFI
-	depends on $(cc-option,-mabi=ms) || X86_32
 	select RELOCATABLE
 	help
 	  This kernel feature allows a bzImage to be loaded directly

base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff
-- 
2.37.3


^ permalink raw reply related	[relevance 93%]

* [PATCH] usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video()
@ 2022-09-28 20:19 89% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-09-28 20:19 UTC (permalink / raw)
  To: Laurent Pinchart, Michael Grzeschik, Felipe Balbi, Greg Kroah-Hartman
  Cc: Kees Cook, linux-usb, linux-kernel, patches, Nathan Chancellor, stable

When building s390 allmodconfig after commit 9b91a6523078 ("usb: gadget:
uvc: increase worker prio to WQ_HIGHPRI"), the following error occurs:

  In file included from ../include/linux/string.h:253,
                   from ../include/linux/bitmap.h:11,
                   from ../include/linux/cpumask.h:12,
                   from ../include/linux/smp.h:13,
                   from ../include/linux/lockdep.h:14,
                   from ../include/linux/rcupdate.h:29,
                   from ../include/linux/rculist.h:11,
                   from ../include/linux/pid.h:5,
                   from ../include/linux/sched.h:14,
                   from ../include/linux/ratelimit.h:6,
                   from ../include/linux/dev_printk.h:16,
                   from ../include/linux/device.h:15,
                   from ../drivers/usb/gadget/function/f_uvc.c:9:
  In function ‘fortify_memset_chk’,
      inlined from ‘uvc_register_video’ at ../drivers/usb/gadget/function/f_uvc.c:424:2:
  ../include/linux/fortify-string.h:301:25: error: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
    301 |                         __write_overflow_field(p_size_field, size);
        |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This points to the memset() in uvc_register_video(). It is clear that
the argument to sizeof() is incorrect, as uvc->vdev (a 'struct
video_device') is being zeroed out but the size of uvc->video (a 'struct
uvc_video') is being used as the third arugment to memset().

pahole shows that prior to commit 9b91a6523078 ("usb: gadget: uvc:
increase worker prio to WQ_HIGHPRI"), 'struct video_device' and
'struct ucv_video' had the same size, meaning that the argument to
sizeof() is incorrect semantically but there is no visible issue:

  $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
  video_device    1400    4
  uvc_video       1400    3

After that change, uvc_video becomes slightly larger, meaning that the
memset() will overwrite by 8 bytes:

  $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+"
  video_device    1400    4
  uvc_video       1408    3

Fix the arugment to sizeof() so that there is no overwrite.

Cc: stable@vger.kernel.org
Fixes: e4ce9ed835bc ("usb: gadget: uvc: ensure the vdev is unset")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/usb/gadget/function/f_uvc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c
index 71669e0e4d00..86bb0098fb66 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -421,7 +421,7 @@ uvc_register_video(struct uvc_device *uvc)
 	int ret;
 
 	/* TODO reference counting. */
-	memset(&uvc->vdev, 0, sizeof(uvc->video));
+	memset(&uvc->vdev, 0, sizeof(uvc->vdev));
 	uvc->vdev.v4l2_dev = &uvc->v4l2_dev;
 	uvc->vdev.v4l2_dev->dev = &cdev->gadget->dev;
 	uvc->vdev.fops = &uvc_v4l2_fops;

base-commit: f76349cf41451c5c42a99f18a9163377e4b364ff
-- 
2.37.3


^ permalink raw reply related	[relevance 89%]

* Re: [PATCH v4] RISC-V: Clean up the Zicbom block size probing
  @ 2022-09-13  9:40 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-09-13  9:40 UTC (permalink / raw)
  To: Conor Dooley
  Cc: atishp, ajones, anup, conor.dooley, heiko, jrtc27, linux-riscv,
	lkp, mchitale, palmer, stable, Atish Patra

On Mon, Sep 12, 2022 at 11:48:01PM +0100, Conor Dooley wrote:
> From: Palmer Dabbelt <palmer@rivosinc.com>
> 
> This fixes two issues: I truncated the warning's hart ID when porting to
> the 64-bit hart ID code, and the original code's warning handling could
> fire on an uninitialized hart ID.
> 
> The biggest change here is that riscv_cbom_block_size is no longer
> initialized, as IMO the default isn't sane: there's nothing in the ISA
> that mandates any specific cache block size, so falling back to one will
> just silently produce the wrong answer on some systems.  This also
> changes the probing order so the cache block size is known before
> enabling Zicbom support.
> 
> CC: stable@vger.kernel.org
> CC: Andrew Jones <ajones@ventanamicro.com>
> CC: Heiko Stuebner <heiko@sntech.de>
> CC: Atish Patra <atishp@rivosinc.com>
> Fixes: 3aefb2ee5bdd ("riscv: implement Zicbom-based CMO instructions + the t-head variant")
> Fixes: 1631ba1259d6 ("riscv: Add support for non-coherent devices using zicbom extension")
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
> [Conor: fixed the redefinition errors]
> Tested-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>

Build-tested-by: Nathan Chancellor <nathan@kernel.org>

Thanks a lot for continuing to chase this!

> ---
> Hey Palmer,
> w/ LPC etc I figure it's highly unlikely you'd have this respun
> in time to have it applied this week. I dropped all the tested
> and reviewed -by tags since this patch has been changed a fair
> bit back and forth since the tags were left. Checked it on my
> D1 to make sure nothing blew up.. if this could make this weeks
> rc, that'd be great so that the clang allmodconfig builds are
> working again.
> Conor.
> ---
>  arch/riscv/errata/thead/errata.c    |  1 +
>  arch/riscv/include/asm/cacheflush.h |  1 +
>  arch/riscv/kernel/setup.c           |  2 +-
>  arch/riscv/mm/dma-noncoherent.c     | 23 +++++++++++++----------
>  4 files changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/riscv/errata/thead/errata.c b/arch/riscv/errata/thead/errata.c
> index 202c83f677b2..96648c176f37 100644
> --- a/arch/riscv/errata/thead/errata.c
> +++ b/arch/riscv/errata/thead/errata.c
> @@ -37,6 +37,7 @@ static bool errata_probe_cmo(unsigned int stage,
>  	if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
>  		return false;
>  
> +	riscv_cbom_block_size = L1_CACHE_BYTES;
>  	riscv_noncoherent_supported();
>  	return true;
>  #else
> diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h
> index a60acaecfeda..a89c005b4bbf 100644
> --- a/arch/riscv/include/asm/cacheflush.h
> +++ b/arch/riscv/include/asm/cacheflush.h
> @@ -43,6 +43,7 @@ void flush_icache_mm(struct mm_struct *mm, bool local);
>  #endif /* CONFIG_SMP */
>  
>  #ifdef CONFIG_RISCV_ISA_ZICBOM
> +extern unsigned int riscv_cbom_block_size;
>  void riscv_init_cbom_blocksize(void);
>  #else
>  static inline void riscv_init_cbom_blocksize(void) { }
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 95ef6e2bf45c..2dfc463b86bb 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -296,8 +296,8 @@ void __init setup_arch(char **cmdline_p)
>  	setup_smp();
>  #endif
>  
> -	riscv_fill_hwcap();
>  	riscv_init_cbom_blocksize();
> +	riscv_fill_hwcap();
>  	apply_boot_alternatives();
>  }
>  
> diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
> index cd2225304c82..e3f9bdf47c5f 100644
> --- a/arch/riscv/mm/dma-noncoherent.c
> +++ b/arch/riscv/mm/dma-noncoherent.c
> @@ -12,7 +12,7 @@
>  #include <linux/of_device.h>
>  #include <asm/cacheflush.h>
>  
> -static unsigned int riscv_cbom_block_size = L1_CACHE_BYTES;
> +unsigned int riscv_cbom_block_size;
>  static bool noncoherent_supported;
>  
>  void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
> @@ -79,38 +79,41 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>  void riscv_init_cbom_blocksize(void)
>  {
>  	struct device_node *node;
> +	unsigned long cbom_hartid;
> +	u32 val, probed_block_size;
>  	int ret;
> -	u32 val;
>  
> +	probed_block_size = 0;
>  	for_each_of_cpu_node(node) {
>  		unsigned long hartid;
> -		int cbom_hartid;
>  
>  		ret = riscv_of_processor_hartid(node, &hartid);
>  		if (ret)
>  			continue;
>  
> -		if (hartid < 0)
> -			continue;
> -
>  		/* set block-size for cbom extension if available */
>  		ret = of_property_read_u32(node, "riscv,cbom-block-size", &val);
>  		if (ret)
>  			continue;
>  
> -		if (!riscv_cbom_block_size) {
> -			riscv_cbom_block_size = val;
> +		if (!probed_block_size) {
> +			probed_block_size = val;
>  			cbom_hartid = hartid;
>  		} else {
> -			if (riscv_cbom_block_size != val)
> -				pr_warn("cbom-block-size mismatched between harts %d and %lu\n",
> +			if (probed_block_size != val)
> +				pr_warn("cbom-block-size mismatched between harts %lu and %lu\n",
>  					cbom_hartid, hartid);
>  		}
>  	}
> +
> +	if (probed_block_size)
> +		riscv_cbom_block_size = probed_block_size;
>  }
>  #endif
>  
>  void riscv_noncoherent_supported(void)
>  {
> +	WARN(!riscv_cbom_block_size,
> +	     "Non-coherent DMA support enabled without a block size\n");
>  	noncoherent_supported = true;
>  }
> -- 
> 2.37.1
> 

^ permalink raw reply	[relevance 99%]

* Apply 5c5c2baad2b55cc0a4b190266889959642298f79 to 5.10+
@ 2022-09-10 14:34 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-09-10 14:34 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, llvm

Hi Greg and Sasha,

Please apply commit 5c5c2baad2b5 ("ASoC: mchp-spdiftx: Fix clang
-Wbitfield-constant-conversion") to 5.10 and newer, as it fixes a
warning with tip of tree LLVM. There will be a minor conflict that can
be resolved by taking commit 403fcb5118a0 ("ASoC: mchp-spdiftx: remove
references to mchp_i2s_caps") before it, which seems reasonable to me.
If that is not acceptable, I can send a backport with just 5c5c2baad2b5.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.19 000/362] 5.19.4-rc2 review
  @ 2022-08-24 20:19 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-08-24 20:19 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, linux-kernel, stable, torvalds, akpm, linux,
	shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
	sudipm.mukherjee, slade, clang-built-linux

Hi Naresh,

On Thu, Aug 25, 2022 at 01:43:09AM +0530, Naresh Kamboju wrote:
> On Wed, 24 Aug 2022 at 12:31, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.19.4 release.
> > There are 362 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri, 26 Aug 2022 06:58:34 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.19.4-rc2.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro's test farm.
> No regressions on arm64, arm, x86_64, and i386.
> 
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> 
> NOTE:
> x86_64 and arm64 clang nightly allmodconfig build failed.
> sound/soc/atmel/mchp-spdiftx.c:508:20: error: implicit truncation from
> 'int' to bit-field changes value from 1 to -1
> [-Werror,-Wbitfield-constant-conversion]
> dev->gclk_enabled = 1;
>                   ^ ~
> 1 error generated.

This should be fixed in mainline soon:

https://git.kernel.org/broonie/sound/c/5c5c2baad2b55cc0a4b190266889959642298f79
https://github.com/ClangBuiltLinux/linux/issues/1686

It will conflict due to a lack of commit 403fcb5118a0 ("ASoC:
mchp-spdiftx: remove references to mchp_i2s_caps") in the stable trees
but I think that change can just be taken along with my change to
minimize any future conflicts. I'll send a separate email with that
information when my patch hits mainline.

Thanks as always for all the testing that you do!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10?
@ 2022-08-12  0:24 97% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-08-12  0:24 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Palmer Dabbelt
  Cc: Dimitri John Ledkov, Anup Patel, stable, linux-riscv

Hi all,

Would it be reasonable to apply commit f2928e224d85 ("riscv: set default
pm_power_off to NULL") to 5.10 and 5.15? I see the following issue when
testing OpenSUSE's RISC-V configuration in QEMU and it is resolved with
that change.

Requesting system poweroff
[    4.497128][  T177] reboot: Power down
[   32.045207][    C0] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [init:177]
[   32.045785][    C0] Modules linked in:
[   32.046166][    C0] CPU: 0 PID: 177 Comm: init Not tainted 5.15.60-default #1 5b276f06901b1c37142db73337a1816290810c90
[   32.046814][    C0] Hardware name: riscv-virtio,qemu (DT)
[   32.047256][    C0] epc : default_power_off+0x1a/0x20
[   32.047667][    C0]  ra : machine_power_off+0x22/0x2a
[   32.047979][    C0] epc : ffffffff80004a4a ra : ffffffff80004abe sp : ffffffd000bc3d50
[   32.048405][    C0]  gp : ffffffff81bec160 tp : ffffffe002080000 t0 : ffffffff80490964
[   32.048827][    C0]  t1 : 0720072007200720 t2 : 50203a746f6f6265 s0 : ffffffd000bc3d60
[   32.049245][    C0]  s1 : 000000004321fedc a0 : 0000000000000004 a1 : ffffffff81b073c8
[   32.049676][    C0]  a2 : 0000000000000010 a3 : 00000000000000ab a4 : e0b1d187e51c7400
[   32.050115][    C0]  a5 : ffffffff80004a30 a6 : c0000000ffffdfff a7 : ffffffff804ea464
[   32.050555][    C0]  s2 : 0000000000000000 s3 : ffffffff81a20390 s4 : fffffffffee1dead
[   32.051009][    C0]  s5 : ffffffff81bee0c8 s6 : 0000003feff55a70 s7 : 0000002acc09bf08
[   32.051427][    C0]  s8 : 0000000000000001 s9 : 0000000000000000 s10: 0000002b0a4db6e0
[   32.051849][    C0]  s11: 0000000000000000 t3 : ffffffe001e2bf00 t4 : ffffffe001e2bf00
[   32.052274][    C0]  t5 : ffffffe001e2b000 t6 : ffffffd000bc3ac8
[   32.052604][    C0] status: 0000000000000120 badaddr: 0000000000000000 cause: 8000000000000005
qemu-system-riscv64: terminating on signal 15 from pid 2356237 (timeout)

I am not sure if there is any regression potential with that change,
hence this email. That change applies cleanly to both trees and I don't
see any additional problems from it.

Cheers,
Nathan

^ permalink raw reply	[relevance 97%]

* [PATCH 4.9] ion: Make user_ion_handle_put_nolock() a void function
@ 2022-07-27 16:46 96% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-27 16:46 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Daniel Rosenberg, stable, llvm, Nathan Chancellor, kernel test robot

Clang warns:

  drivers/staging/android/ion/ion-ioctl.c:71:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
          if (--handle->user_ref_count == 0)
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/staging/android/ion/ion-ioctl.c:74:9: note: uninitialized use occurs here
          return ret;
                 ^~~
  drivers/staging/android/ion/ion-ioctl.c:71:2: note: remove the 'if' if its condition is always true
          if (--handle->user_ref_count == 0)
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/staging/android/ion/ion-ioctl.c:69:9: note: initialize the variable 'ret' to silence this warning
          int ret;
                 ^
                  = 0
  1 warning generated.

The return value of user_ion_handle_put_nolock() is not checked in its
one call site in user_ion_free_nolock() so just make
user_ion_handle_put_nolock() return void to remove the warning.

Fixes: a8200613c8c9 ("ion: Protect kref from userspace manipulation")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/staging/android/ion/ion-ioctl.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index a27865b94416..e020a23d05f2 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -64,14 +64,10 @@ static struct ion_handle *pass_to_user(struct ion_handle *handle)
 }
 
 /* Must hold the client lock */
-static int user_ion_handle_put_nolock(struct ion_handle *handle)
+static void user_ion_handle_put_nolock(struct ion_handle *handle)
 {
-	int ret;
-
 	if (--handle->user_ref_count == 0)
-		ret = ion_handle_put_nolock(handle);
-
-	return ret;
+		ion_handle_put_nolock(handle);
 }
 
 static void user_ion_free_nolock(struct ion_client *client,

base-commit: 65be5f5665a580424a7b1102f1a04c4259c559b5
-- 
2.37.1


^ permalink raw reply related	[relevance 96%]

* [PATCH] drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()
@ 2022-07-25 23:36 98% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-25 23:36 UTC (permalink / raw)
  To: Thomas Zimmermann, Javier Martinez Canillas
  Cc: Sami Tolvanen, Kees Cook, dri-devel, linux-kernel, llvm,
	Nathan Chancellor, stable, Tomasz Paweł Gajc

When booting a kernel compiled with clang's CFI protection
(CONFIG_CFI_CLANG), there is a CFI failure in
drm_simple_kms_crtc_mode_valid() when trying to call
simpledrm_simple_display_pipe_mode_valid() through ->mode_valid():

[    0.322802] CFI failure (target: simpledrm_simple_display_pipe_mode_valid+0x0/0x8):
...
[    0.324928] Call trace:
[    0.324969]  __ubsan_handle_cfi_check_fail+0x58/0x60
[    0.325053]  __cfi_check_fail+0x3c/0x44
[    0.325120]  __cfi_slowpath_diag+0x178/0x200
[    0.325192]  drm_simple_kms_crtc_mode_valid+0x58/0x80
[    0.325279]  __drm_helper_update_and_validate+0x31c/0x464
...

The ->mode_valid() member in 'struct drm_simple_display_pipe_funcs'
expects a return type of 'enum drm_mode_status', not 'int'. Correct it
to fix the CFI failure.

Cc: stable@vger.kernel.org
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1647
Reported-by: Tomasz Paweł Gajc <tpgxyz@gmail.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 768242a78e2b..5422363690e7 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -627,7 +627,7 @@ static const struct drm_connector_funcs simpledrm_connector_funcs = {
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
-static int
+static enum drm_mode_status
 simpledrm_simple_display_pipe_mode_valid(struct drm_simple_display_pipe *pipe,
 				    const struct drm_display_mode *mode)
 {

base-commit: e0dccc3b76fb35bb257b4118367a883073d7390e
-- 
2.37.1


^ permalink raw reply related	[relevance 98%]

* Re: [PATCH v2] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current
  @ 2022-07-13 16:27 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-13 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Linus Torvalds, x86, Nick Desaulniers, Josh Poimboeuf,
	linux-kernel, llvm, stable, kernel test robot

On Wed, Jul 13, 2022 at 06:22:41PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 13, 2022 at 08:24:37AM -0700, Nathan Chancellor wrote:
> > Clang warns:
> > 
> >   arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
> >   DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
> >                       ^
> >   arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
> >   extern u64 x86_spec_ctrl_current;
> >              ^
> >   1 error generated.
> > 
> > The declaration should be using DECLARE_PER_CPU instead so all
> > attributes stay in sync.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: fc02735b14ff ("KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > 
> > v1 -> v2: https://lore.kernel.org/20220713152222.1697913-1-nathan@kernel.org/
> > 
> > * Use asm/percpu.h instead of linux/percpu.h to avoid static call
> >   include errors.
> > 
> >  arch/x86/include/asm/nospec-branch.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > index bb05ed4f46bd..10a3bfc1eb23 100644
> > --- a/arch/x86/include/asm/nospec-branch.h
> > +++ b/arch/x86/include/asm/nospec-branch.h
> > @@ -11,6 +11,7 @@
> >  #include <asm/cpufeatures.h>
> >  #include <asm/msr-index.h>
> >  #include <asm/unwind_hints.h>
> > +#include <asm/percpu.h>
> >  
> >  #define RETPOLINE_THUNK_SIZE	32
> >  
> 
> When I tried this earlier today I ran into cyclic headers, you sure this
> works?

Yes, I did my regular set of x86 builds with clang and they all passed.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH v2] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current
@ 2022-07-13 15:24 96% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-07-13 15:24 UTC (permalink / raw)
  To: Linus Torvalds, x86
  Cc: Nick Desaulniers, Peter Zijlstra, Josh Poimboeuf, linux-kernel,
	llvm, Nathan Chancellor, stable, kernel test robot

Clang warns:

  arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
  DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
                      ^
  arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
  extern u64 x86_spec_ctrl_current;
             ^
  1 error generated.

The declaration should be using DECLARE_PER_CPU instead so all
attributes stay in sync.

Cc: stable@vger.kernel.org
Fixes: fc02735b14ff ("KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

v1 -> v2: https://lore.kernel.org/20220713152222.1697913-1-nathan@kernel.org/

* Use asm/percpu.h instead of linux/percpu.h to avoid static call
  include errors.

 arch/x86/include/asm/nospec-branch.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index bb05ed4f46bd..10a3bfc1eb23 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -11,6 +11,7 @@
 #include <asm/cpufeatures.h>
 #include <asm/msr-index.h>
 #include <asm/unwind_hints.h>
+#include <asm/percpu.h>
 
 #define RETPOLINE_THUNK_SIZE	32
 
@@ -280,7 +281,7 @@ static inline void indirect_branch_prediction_barrier(void)
 
 /* The Intel SPEC CTRL MSR base value cache */
 extern u64 x86_spec_ctrl_base;
-extern u64 x86_spec_ctrl_current;
+DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
 extern void write_spec_ctrl_current(u64 val, bool force);
 extern u64 spec_ctrl_current(void);
 

base-commit: 72a8e05d4f66b5af7854df4490e3135168694b6b
-- 
2.37.1


^ permalink raw reply related	[relevance 96%]

* Re: [PATCH] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current
  2022-07-13 15:22 97% [PATCH] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current Nathan Chancellor
@ 2022-07-13 15:24 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-13 15:24 UTC (permalink / raw)
  To: Linus Torvalds, x86
  Cc: Nick Desaulniers, Peter Zijlstra, Josh Poimboeuf, linux-kernel,
	llvm, stable, kernel test robot

On Wed, Jul 13, 2022 at 08:22:22AM -0700, Nathan Chancellor wrote:
> Clang warns:
> 
>   arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
>   DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
>                       ^
>   arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
>   extern u64 x86_spec_ctrl_current;
>              ^
>   1 error generated.
> 
> The declaration should be using DECLARE_PER_CPU instead so all
> attributes stay in sync.
> 
> Cc: stable@vger.kernel.org
> Fixes: fc02735b14ff ("KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/x86/include/asm/nospec-branch.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index bb05ed4f46bd..99a29c83adf8 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -6,6 +6,7 @@
>  #include <linux/static_key.h>
>  #include <linux/objtool.h>
>  #include <linux/linkage.h>
> +#include <linux/percpu.h>

Argh, forgot to amend... v2 incoming.

>  #include <asm/alternative.h>
>  #include <asm/cpufeatures.h>
> @@ -280,7 +281,7 @@ static inline void indirect_branch_prediction_barrier(void)
>  
>  /* The Intel SPEC CTRL MSR base value cache */
>  extern u64 x86_spec_ctrl_base;
> -extern u64 x86_spec_ctrl_current;
> +DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
>  extern void write_spec_ctrl_current(u64 val, bool force);
>  extern u64 spec_ctrl_current(void);
>  
> 
> base-commit: 72a8e05d4f66b5af7854df4490e3135168694b6b
> -- 
> 2.37.1
> 

^ permalink raw reply	[relevance 99%]

* [PATCH] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current
@ 2022-07-13 15:22 97% Nathan Chancellor
  2022-07-13 15:24 99% ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-07-13 15:22 UTC (permalink / raw)
  To: Linus Torvalds, x86
  Cc: Nick Desaulniers, Peter Zijlstra, Josh Poimboeuf, linux-kernel,
	llvm, Nathan Chancellor, stable, kernel test robot

Clang warns:

  arch/x86/kernel/cpu/bugs.c:58:21: error: section attribute is specified on redeclared variable [-Werror,-Wsection]
  DEFINE_PER_CPU(u64, x86_spec_ctrl_current);
                      ^
  arch/x86/include/asm/nospec-branch.h:283:12: note: previous declaration is here
  extern u64 x86_spec_ctrl_current;
             ^
  1 error generated.

The declaration should be using DECLARE_PER_CPU instead so all
attributes stay in sync.

Cc: stable@vger.kernel.org
Fixes: fc02735b14ff ("KVM: VMX: Prevent guest RSB poisoning attacks with eIBRS")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/x86/include/asm/nospec-branch.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index bb05ed4f46bd..99a29c83adf8 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -6,6 +6,7 @@
 #include <linux/static_key.h>
 #include <linux/objtool.h>
 #include <linux/linkage.h>
+#include <linux/percpu.h>
 
 #include <asm/alternative.h>
 #include <asm/cpufeatures.h>
@@ -280,7 +281,7 @@ static inline void indirect_branch_prediction_barrier(void)
 
 /* The Intel SPEC CTRL MSR base value cache */
 extern u64 x86_spec_ctrl_base;
-extern u64 x86_spec_ctrl_current;
+DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
 extern void write_spec_ctrl_current(u64 val, bool force);
 extern u64 spec_ctrl_current(void);
 

base-commit: 72a8e05d4f66b5af7854df4490e3135168694b6b
-- 
2.37.1


^ permalink raw reply related	[relevance 97%]

* Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
  @ 2022-07-07 17:17 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-07 17:17 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
	linux-kernel, patches, llvm, stable

On Wed, Jul 06, 2022 at 03:25:51PM -0700, Dave Hansen wrote:
> On 6/17/22 11:08, Nathan Chancellor wrote:
> > When clang is invoked without a '--target' flag, code is generated for
> > the default target, which is usually the host (it is configurable via
> > cmake). As a result, the has-stack-protector scripts will generate code
> > for the default target but check for x86 specific segment registers,
> > which cannot succeed if the default target is not x86.
> 
> I guess the real root cause here is the direct use of '$(CC)' without
> any other flags.  Adding '$(CLANG_FLAGS)' seems like a pretty normal
> fix, like in scripts/Kconfig.include.

Right, also see the following commits for other areas where this was
addressed.

58d746c119df ("efi/libstub: Add $(CLANG_FLAGS) to x86 flags")
d5cbd80e302d ("x86/boot: Add $(CLANG_FLAGS) to compressed KBUILD_CFLAGS")
8abe7fc26ad8 ("x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)")

> I suspect there's another one of these here:
> 
> 	arch/x86/um/vdso/Makefile:      cmd_vdso = $(CC) -nostdlib -o $@
> 
> but I wouldn't be surprised if UML doesn't work with clang in the first
> place.

We have started testing UML with clang and it does work but I suspect
there is little value to cross compiling a UML kernel, as it has to run
in an x86 userland anyways, rather than through QEMU or other
virtualization solutions. That is not something I plan to do anyways.
If someone does and a fix similar to this one is needed, it can be done
at that time.

Thank you for picking up this change!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
  2022-06-17 18:08 87% [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
@ 2022-07-01 22:17 99% ` Nathan Chancellor
    1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-01 22:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
  Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
	linux-kernel, patches, llvm, stable

Gentle ping for review.

On Fri, Jun 17, 2022 at 11:08:46AM -0700, Nathan Chancellor wrote:
> Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
> enabled when cross compiling an x86_64 kernel with clang, even though it
> does work when natively compiling.
> 
> When building on aarch64:
> 
>   $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
> 
>   $ grep STACKPROTECTOR .config
> 
> When building on x86_64:
> 
>   $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig
> 
>   $ grep STACKPROTECTOR .config
>   CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
>   CONFIG_HAVE_STACKPROTECTOR=y
>   CONFIG_STACKPROTECTOR=y
>   CONFIG_STACKPROTECTOR_STRONG=y
> 
> When clang is invoked without a '--target' flag, code is generated for
> the default target, which is usually the host (it is configurable via
> cmake). As a result, the has-stack-protector scripts will generate code
> for the default target but check for x86 specific segment registers,
> which cannot succeed if the default target is not x86.
> 
> $(CLANG_FLAGS) contains an explicit '--target' flag so pass that
> variable along to the has-stack-protector scripts so that the stack
> protector can be enabled when cross compiling with clang. The 32-bit
> stack protector cannot currently be enabled with clang, as it does not
> support '-mstack-protector-guard-symbol', so this results in no
> functional change for ARCH=i386 when cross compiling.
> 
> Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
> Link: https://github.com/llvm/llvm-project/issues/48553
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> 
> Fixes: 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode")
> 
> might be appropriate; I am conflicted on fixes tags for problems that
> that arise due to use cases that were not considered at the time of a
> change, as it feels wrong to blame the commit for not looking far enough
> into the future where it might be common for people to have workstations
> running another architecture other than x86_64.
> 
> Chimera appears to use a 5.15 kernel so a
> 
> Cc: stable@vger.kernel.org
> 
> might be nice but some maintainers are picky about that so I leave it up
> to you all.
> 
>  arch/x86/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index be0b95e51df6..076adde7ead9 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -391,8 +391,8 @@ config PGTABLE_LEVELS
>  
>  config CC_HAS_SANE_STACKPROTECTOR
>  	bool
> -	default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
> -	default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
> +	default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
> +	default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
>  	help
>  	  We have to make sure stack protector is unconditionally disabled if
>  	  the compiler produces broken code or if it does not let us control
> 
> base-commit: b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3
> -- 
> 2.36.1
> 
> 

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 5.15 02/28] clocksource/drivers/ixp4xx: remove __init from ixp4xx_timer_setup()
  @ 2022-07-01 15:31 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-07-01 15:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Linus Walleij, Daniel Lezcano

Hi Greg,

On Thu, Jun 30, 2022 at 03:46:58PM +0200, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ixp4xx_timer_setup is exported, and so can not be an __init function.
> Remove the __init marking as the build system is rightfully claiming
> this is an error in older kernels.
> 
> This is fixed "properly" in commit 41929c9f628b
> ("clocksource/drivers/ixp4xx: Drop boardfile probe path") but that can
> not be backported to older kernels as the reworking of the IXP4xx
> codebase is not suitable for stable releases.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch causes the following warnings with clang when building
ARCH=arm allmodconfig on 5.15, 5.10, and 5.4. I am surprised nobody else
saw them.

  WARNING: modpost: vmlinux.o(.text+0x1219ccc): Section mismatch in reference from the function ixp4xx_timer_register() to the function .init.text:sched_clock_register()
  The function ixp4xx_timer_register() references
  the function __init sched_clock_register().
  This is often because ixp4xx_timer_register lacks a __init
  annotation or the annotation of sched_clock_register is wrong.

  WARNING: modpost: vmlinux.o(.text+0x1219cf4): Section mismatch in reference from the function ixp4xx_timer_register() to the function .init.text:register_current_timer_delay()
  The function ixp4xx_timer_register() references
  the function __init register_current_timer_delay().
  This is often because ixp4xx_timer_register lacks a __init
  annotation or the annotation of register_current_timer_delay is wrong.

I think it would just be better to remove the export of
ixp4xx_timer_setup(), rather than removing __init, as it is only called
in arch/arm/mach-ixp4xx/common.c, which has to be built into the kernel
image as it is 'obj-y' in arch/arm/mach-ixp4xx/Makefile.

Cheers,
Nathan

> ---
>  drivers/clocksource/mmio.c                 |    2 +-
>  drivers/clocksource/timer-ixp4xx.c         |   10 ++++------
>  include/linux/platform_data/timer-ixp4xx.h |    5 ++---
>  3 files changed, 7 insertions(+), 10 deletions(-)
> 
> --- a/drivers/clocksource/mmio.c
> +++ b/drivers/clocksource/mmio.c
> @@ -46,7 +46,7 @@ u64 clocksource_mmio_readw_down(struct c
>   * @bits:	Number of valid bits
>   * @read:	One of clocksource_mmio_read*() above
>   */
> -int __init clocksource_mmio_init(void __iomem *base, const char *name,
> +int clocksource_mmio_init(void __iomem *base, const char *name,
>  	unsigned long hz, int rating, unsigned bits,
>  	u64 (*read)(struct clocksource *))
>  {
> --- a/drivers/clocksource/timer-ixp4xx.c
> +++ b/drivers/clocksource/timer-ixp4xx.c
> @@ -161,9 +161,8 @@ static int ixp4xx_resume(struct clock_ev
>   * We use OS timer1 on the CPU for the timer tick and the timestamp
>   * counter as a source of real clock ticks to account for missed jiffies.
>   */
> -static __init int ixp4xx_timer_register(void __iomem *base,
> -					int timer_irq,
> -					unsigned int timer_freq)
> +static int ixp4xx_timer_register(void __iomem *base, int timer_irq,
> +				 unsigned int timer_freq)
>  {
>  	struct ixp4xx_timer *tmr;
>  	int ret;
> @@ -269,9 +268,8 @@ builtin_platform_driver(ixp4xx_timer_dri
>   * @timer_irq: Linux IRQ number for the timer
>   * @timer_freq: Fixed frequency of the timer
>   */
> -void __init ixp4xx_timer_setup(resource_size_t timerbase,
> -			       int timer_irq,
> -			       unsigned int timer_freq)
> +void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq,
> +			unsigned int timer_freq)
>  {
>  	void __iomem *base;
>  
> --- a/include/linux/platform_data/timer-ixp4xx.h
> +++ b/include/linux/platform_data/timer-ixp4xx.h
> @@ -4,8 +4,7 @@
>  
>  #include <linux/ioport.h>
>  
> -void __init ixp4xx_timer_setup(resource_size_t timerbase,
> -			       int timer_irq,
> -			       unsigned int timer_freq);
> +void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq,
> +			unsigned int timer_freq);
>  
>  #endif
> 
> 
> 

^ permalink raw reply	[relevance 99%]

* Apply 1e70212e031528918066a631c9fdccda93a1ffaa to 5.18
@ 2022-06-27 17:57 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-06-27 17:57 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: Nick Desaulniers, Kees Cook, stable, llvm

Hi Greg and Sasha,

Please apply commit 1e70212e0315 ("hinic: Replace memcpy() with direct
assignment") to 5.18. It fixes a warning visible when building arm64 and
x86_64 allmodconfig with clang 14 and newer (and possibly other
architectures but I didn't check). This will allow CONFIG_WERROR to
remain enabled when building arm64 and x86_64 kernels with clang on 5.15
and 5.18 (other architectures and newer versions are getting there).

This change shouldn't be problematic in older kernels but the warning it
fixes won't be visible without the new FORTIFY_SOURCE changes that
landed in 5.18, so I wouldn't worry about backporting it further.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
@ 2022-06-17 18:08 87% Nathan Chancellor
  2022-07-01 22:17 99% ` Nathan Chancellor
    0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2022-06-17 18:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86
  Cc: H. Peter Anvin, Nick Desaulniers, Tom Rix, Daniel Kolesa,
	linux-kernel, patches, llvm, Nathan Chancellor, stable

Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
enabled when cross compiling an x86_64 kernel with clang, even though it
does work when natively compiling.

When building on aarch64:

  $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig

  $ grep STACKPROTECTOR .config

When building on x86_64:

  $ make -sj"$(nproc)" ARCH=x86_64 LLVM=1 defconfig

  $ grep STACKPROTECTOR .config
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
  CONFIG_HAVE_STACKPROTECTOR=y
  CONFIG_STACKPROTECTOR=y
  CONFIG_STACKPROTECTOR_STRONG=y

When clang is invoked without a '--target' flag, code is generated for
the default target, which is usually the host (it is configurable via
cmake). As a result, the has-stack-protector scripts will generate code
for the default target but check for x86 specific segment registers,
which cannot succeed if the default target is not x86.

$(CLANG_FLAGS) contains an explicit '--target' flag so pass that
variable along to the has-stack-protector scripts so that the stack
protector can be enabled when cross compiling with clang. The 32-bit
stack protector cannot currently be enabled with clang, as it does not
support '-mstack-protector-guard-symbol', so this results in no
functional change for ARCH=i386 when cross compiling.

Link: https://github.com/chimera-linux/cports/commit/0fb7e506d5f83fdf2104feb22cdac34934561226
Link: https://github.com/llvm/llvm-project/issues/48553
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

Fixes: 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode")

might be appropriate; I am conflicted on fixes tags for problems that
that arise due to use cases that were not considered at the time of a
change, as it feels wrong to blame the commit for not looking far enough
into the future where it might be common for people to have workstations
running another architecture other than x86_64.

Chimera appears to use a 5.15 kernel so a

Cc: stable@vger.kernel.org

might be nice but some maintainers are picky about that so I leave it up
to you all.

 arch/x86/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index be0b95e51df6..076adde7ead9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -391,8 +391,8 @@ config PGTABLE_LEVELS
 
 config CC_HAS_SANE_STACKPROTECTOR
 	bool
-	default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC)) if 64BIT
-	default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC))
+	default $(success,$(srctree)/scripts/gcc-x86_64-has-stack-protector.sh $(CC) $(CLANG_FLAGS)) if 64BIT
+	default $(success,$(srctree)/scripts/gcc-x86_32-has-stack-protector.sh $(CC) $(CLANG_FLAGS))
 	help
 	  We have to make sure stack protector is unconditionally disabled if
 	  the compiler produces broken code or if it does not let us control

base-commit: b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3
-- 
2.36.1


^ permalink raw reply related	[relevance 87%]

* Re: boot loop since 5.17.6
  @ 2022-06-02 21:32 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-06-02 21:32 UTC (permalink / raw)
  To: Thomas Sattler; +Cc: stable, regressions

On Thu, Jun 02, 2022 at 09:24:18PM +0200, Thomas Sattler wrote:
> with these three diffs reverted, I was able to boot
> all affected 5.17.x kernels (x={6,7,8,9,10,11,12})
> 
> 
> 
> Am 02.06.22 um 18:42 schrieb Thomas Sattler:
> > some more information:
> > 
> > $ cat /proc/version
> > Linux version 5.17.5 (root@dragon) (x86_64-pc-linux-gnu-gcc (Gentoo
> > 11.2.1_p20220115 p4) 11.2.1 20220115, GNU ld (Gentoo 2.37_p1 p2) 2.37)
> > #130 SMP PREEMPT Thu Apr 28 10:50:24 CEST 2022
> > 
> > $ uname -mi
> > x86_64 GenuineIntel
> > 
> > 
> > I tried to compile 5.17.6 without the three mentioned diffs which
> > modify the following files:
> > 
> >     tools/objtool/check.c   and
> >     tools/objtool/elf.c      and
> >     tools/objtool/include/objtool/elf.h
> > 
> > and was then able to successfully boot 5.17.6.

5.17.6 has commit 60d2b0b1018a ("objtool: Fix code relocs vs weak
symbols"), which has a known issue that is fixed with commit
ead165fa1042 ("objtool: Fix symbol creation"). If you apply ead165fa1042
on 5.17.6 or newer, does that resolve your issue?

ead165fa1042 is tagged for stable but I don't think Greg picks up
patches from mainline until they are in a tagged -rc release.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH 4.19] MIPS: fix allmodconfig build with latest mkimage
  @ 2022-05-14 21:03 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-05-14 21:03 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Greg Kroah-Hartman, stable

On Sat, May 14, 2022 at 04:34:14PM +0100, Sudip Mukherjee wrote:
> From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> 
> With the latest mkimage from U-Boot 2021.04+ the allmodconfig build
> fails. 822564cd3aa1 ("MIPS: generic: Update node names to avoid unit
> addresses") was applied for similar build failure, but it was not
> applied to 'arch/mips/generic/board-ocelot_pcb123.its.S' as that was
> removed from upstream when the patch was applied.
> 
> Fixes: 822564cd3aa1 ("MIPS: generic: Update node names to avoid unit addresses")

Ah, fair enough. I missed this because the board file was renamed and
updated as part of commit 39249d776ca7 ("MIPS: mscc: add PCB120 to the
ocelot fitImage"), which was a part of 4.20... :) the upstream change
has this properly fixed and this diff matches so:

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> Cc: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> ---
>  arch/mips/generic/board-ocelot_pcb123.its.S | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/mips/generic/board-ocelot_pcb123.its.S b/arch/mips/generic/board-ocelot_pcb123.its.S
> index 5a7d5e1c878af..6dd54b7c2f076 100644
> --- a/arch/mips/generic/board-ocelot_pcb123.its.S
> +++ b/arch/mips/generic/board-ocelot_pcb123.its.S
> @@ -1,23 +1,23 @@
>  /* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
>  / {
>  	images {
> -		fdt@ocelot_pcb123 {
> +		fdt-ocelot_pcb123 {
>  			description = "MSCC Ocelot PCB123 Device Tree";
>  			data = /incbin/("boot/dts/mscc/ocelot_pcb123.dtb");
>  			type = "flat_dt";
>  			arch = "mips";
>  			compression = "none";
> -			hash@0 {
> +			hash {
>  				algo = "sha1";
>  			};
>  		};
>  	};
>  
>  	configurations {
> -		conf@ocelot_pcb123 {
> +		conf-ocelot_pcb123 {
>  			description = "Ocelot Linux kernel";
> -			kernel = "kernel@0";
> -			fdt = "fdt@ocelot_pcb123";
> +			kernel = "kernel";
> +			fdt = "fdt-ocelot_pcb123";
>  		};
>  	};
>  };
> -- 
> 2.30.2
> 

^ permalink raw reply	[relevance 99%]

* Warning fixes for clang + x86_64 allmodconfig on 5.10 and 5.4
@ 2022-05-10 17:49 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-05-10 17:49 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, Nick Desaulniers, Tom Rix, llvm

Hi Greg and Sasha,

A recent change in LLVM [1] strengthened -Wenum-conversion, which
revealed a couple of instances in 5.10 and 5.4 (the oldest release that
I personally build test). They are fixed with the following changes,
please consider applying them wherever they apply cleanly (I have
included the release they first appeared in):

1f1e87b4dc45 ("block: drbd: drbd_nl: Make conversion to 'enum drbd_ret_code' explicit") [5.13]
353f7f3a9dd5 ("drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types") [5.14]

Since I am here already, please consider applying the following
additional changes where they cleanly apply, as they resolve other
warnings present in x86_64 allmodconfig with clang:

7bf03e7504e4 ("drm/i915: Cast remain to unsigned long in eb_relocate_vma") [5.8]
8a64ef042eab ("nfp: bpf: silence bitwise vs. logical OR warning") [5.15]

If there are any problems or questions, please let me know!

[1]: https://github.com/llvm/llvm-project/commit/882915df61e33f3a2b7f58e52f572717e1c11499

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: Apply d799769188529abc6cbf035a10087a51f7832b6b to 5.17 and 5.15?
  2022-04-21 15:13 99%   ` Nathan Chancellor
@ 2022-05-03 21:34 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-05-03 21:34 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Greg Kroah-Hartman, Sasha Levin, Nick Desaulniers, Tom Rix,
	Paul Menzel, stable, linuxppc-dev, llvm

On Thu, Apr 21, 2022 at 08:13:13AM -0700, Nathan Chancellor wrote:
> On Thu, Apr 21, 2022 at 05:46:52PM +1000, Michael Ellerman wrote:
> > Nathan Chancellor <nathan@kernel.org> writes:
> > > Hi Greg, Sasha, and Michael,
> > >
> > > Commit d79976918852 ("powerpc/64: Add UADDR64 relocation support") fixes
> > > a boot failure with CONFIG_RELOCATABLE=y kernels linked with recent
> > > versions of ld.lld [1]. Additionally, it resolves a separate boot
> > > failure that Paul Menzel reported [2] with ld.lld 13.0.0. Is this a
> > > reasonable backport for 5.17 and 5.15? It applies cleanly, resolves both
> > > problems, and does not appear to cause any other issues in my testing
> > > for both trees but I was curious what Michael's opinion was, as I am far
> > > from a PowerPC expert.
> > >
> > > This change does apply cleanly to 5.10 (I did not try earlier branches)
> > > but there are other changes needed for ld.lld to link CONFIG_RELOCATABLE
> > > kernels in that branch so to avoid any regressions, I think it is safe
> > > to just focus on 5.15 and 5.17.
> > 
> > I considered tagging it for stable, but I wanted it to get a bit of
> > testing first, it's a reasonably big patch.
> > 
> > I think we're reasonably confident it doesn't introduce any new bugs,
> > but more testing time is always good.
> > 
> > So I guess I'd be inclined to wait another week or so before requesting
> > a stable backport?
> 
> Sure, thanks for the response! I'll ping this thread on Monday, May 2nd,
> so that we have two more RC releases to try and flush out any lingering
> issues. If you do receive any reports of regressions, please let me
> know.

I decided to wait an extra day just to give people the opportunity to
install -rc5 and run it through their tests. I have not heard of any
reports yet, are there any further objections?

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: Apply d799769188529abc6cbf035a10087a51f7832b6b to 5.17 and 5.15?
  @ 2022-04-21 15:13 99%   ` Nathan Chancellor
  2022-05-03 21:34 99%     ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-04-21 15:13 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Greg Kroah-Hartman, Sasha Levin, Nick Desaulniers, Tom Rix,
	Paul Menzel, stable, linuxppc-dev, llvm

On Thu, Apr 21, 2022 at 05:46:52PM +1000, Michael Ellerman wrote:
> Nathan Chancellor <nathan@kernel.org> writes:
> > Hi Greg, Sasha, and Michael,
> >
> > Commit d79976918852 ("powerpc/64: Add UADDR64 relocation support") fixes
> > a boot failure with CONFIG_RELOCATABLE=y kernels linked with recent
> > versions of ld.lld [1]. Additionally, it resolves a separate boot
> > failure that Paul Menzel reported [2] with ld.lld 13.0.0. Is this a
> > reasonable backport for 5.17 and 5.15? It applies cleanly, resolves both
> > problems, and does not appear to cause any other issues in my testing
> > for both trees but I was curious what Michael's opinion was, as I am far
> > from a PowerPC expert.
> >
> > This change does apply cleanly to 5.10 (I did not try earlier branches)
> > but there are other changes needed for ld.lld to link CONFIG_RELOCATABLE
> > kernels in that branch so to avoid any regressions, I think it is safe
> > to just focus on 5.15 and 5.17.
> 
> I considered tagging it for stable, but I wanted it to get a bit of
> testing first, it's a reasonably big patch.
> 
> I think we're reasonably confident it doesn't introduce any new bugs,
> but more testing time is always good.
> 
> So I guess I'd be inclined to wait another week or so before requesting
> a stable backport?

Sure, thanks for the response! I'll ping this thread on Monday, May 2nd,
so that we have two more RC releases to try and flush out any lingering
issues. If you do receive any reports of regressions, please let me
know.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Apply d799769188529abc6cbf035a10087a51f7832b6b to 5.17 and 5.15?
@ 2022-04-19 21:27 98% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-04-19 21:27 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Michael Ellerman
  Cc: Nick Desaulniers, Tom Rix, Paul Menzel, stable, linuxppc-dev, llvm

Hi Greg, Sasha, and Michael,

Commit d79976918852 ("powerpc/64: Add UADDR64 relocation support") fixes
a boot failure with CONFIG_RELOCATABLE=y kernels linked with recent
versions of ld.lld [1]. Additionally, it resolves a separate boot
failure that Paul Menzel reported [2] with ld.lld 13.0.0. Is this a
reasonable backport for 5.17 and 5.15? It applies cleanly, resolves both
problems, and does not appear to cause any other issues in my testing
for both trees but I was curious what Michael's opinion was, as I am far
from a PowerPC expert.

This change does apply cleanly to 5.10 (I did not try earlier branches)
but there are other changes needed for ld.lld to link CONFIG_RELOCATABLE
kernels in that branch so to avoid any regressions, I think it is safe
to just focus on 5.15 and 5.17.

Paul, it would not hurt to confirm the results of my testing with your
setup, just to make sure I did not miss anything :)

[1]: https://github.com/ClangBuiltLinux/linux/issues/1581
[2]: https://lore.kernel.org/Yg2h2Q2vXFkkLGTh@dev-arch.archlinux-ax161/

Cheers,
Nathan

^ permalink raw reply	[relevance 98%]

* btrfs warning fixes for 5.15 and 5.17
@ 2022-04-14 20:29 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-04-14 20:29 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, llvm, Nick Desaulniers, linux-btrfs

Hi Greg and Sasha,

Please apply

ad3fc7946b18 ("btrfs: remove no longer used counter when reading data page")
6d4a6b515c39 ("btrfs: remove unused variable in btrfs_{start,write}_dirty_block_groups()")

to 5.15 and 5.17 and

cd9255be6980 ("btrfs: remove unused parameter nr_pages in add_ra_bio_pages()")

to 5.15 (it landed in 5.16), as they all resolve build errors with
CONFIG_WERROR=y and tip of tree clang, which recently added support for
unary operations in -Wunused-but-set-variable. They all apply cleanly
and I do not see any additional build warnings and errors.

Commit 6d4a6b515c39 was specifically tagged for stable back to 5.4,
which should be fine, but it really only needs to go back to 5.12+, as
btrfs turned on W=1 (which includes this warning) for itself in commit
e9aa7c285d20 ("btrfs: enable W=1 checks for btrfs"), which landed in
5.12-rc1. Prior that that change, none of these warnings will be
visible under a normal build.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH 5.4 2/2] drm/amdkfd: Fix -Wstrict-prototypes from amdgpu_amdkfd_gfx_10_0_get_functions()
  2022-04-11 16:43 99% [PATCH 5.4 0/2] Fix two instances of -Wstrict-prototypes in drm/amd Nathan Chancellor
  2022-04-11 16:43 99% ` [PATCH 5.4 1/2] drm/amdkfd: add missing void argument to function kgd2kfd_init Nathan Chancellor
@ 2022-04-11 16:43 95% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-04-11 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Felix Kuehling, Alex Deucher, Nick Desaulniers, amd-gfx, llvm,
	stable, Nathan Chancellor

This patch is for linux-5.4.y only, it has no equivalent change
upstream.

When building x86_64 allmodconfig with tip of tree clang, there is an
instance of -Wstrict-prototypes:

  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c:168:59: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
  struct kfd2kgd_calls *amdgpu_amdkfd_gfx_10_0_get_functions()
                                                            ^
                                                             void
  1 error generated.

amdgpu_amdkfd_gfx_10_0_get_functions() is prototyped properly in
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h but its definition in
amdgpu_amdkfd_gfx_v10.c does not have the argument types specified,
which causes the warning. GCC does not warn because it permits an
old-style definition if the prototype has the argument types.

This code was eliminated by commit e392c887df97 ("drm/amdkfd: Use array
to probe kfd2kgd_calls"), which was a part of a larger series that does
not look very suitable for stable. Just fix this one location, as it was
the only instance of this new warning across a variety of builds.

Fixes: 6bdadb207224 ("drm/amdgpu: Add navi10 kfd support for amdgpu (v3)")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index ce30d4e8bf25..f7c4337c1ffe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -165,7 +165,7 @@ static const struct kfd2kgd_calls kfd2kgd = {
 	.get_tile_config = amdgpu_amdkfd_get_tile_config,
 };
 
-struct kfd2kgd_calls *amdgpu_amdkfd_gfx_10_0_get_functions()
+struct kfd2kgd_calls *amdgpu_amdkfd_gfx_10_0_get_functions(void)
 {
 	return (struct kfd2kgd_calls *)&kfd2kgd;
 }
-- 
2.35.1


^ permalink raw reply related	[relevance 95%]

* [PATCH 5.4 1/2] drm/amdkfd: add missing void argument to function kgd2kfd_init
  2022-04-11 16:43 99% [PATCH 5.4 0/2] Fix two instances of -Wstrict-prototypes in drm/amd Nathan Chancellor
@ 2022-04-11 16:43 99% ` Nathan Chancellor
  2022-04-11 16:43 95% ` [PATCH 5.4 2/2] drm/amdkfd: Fix -Wstrict-prototypes from amdgpu_amdkfd_gfx_10_0_get_functions() Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-04-11 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Felix Kuehling, Alex Deucher, Nick Desaulniers, amd-gfx, llvm,
	stable, Colin Ian King, Randy Dunlap, Nathan Chancellor

From: Colin Ian King <colin.king@canonical.com>

commit 63617d8b125ed9f674133dd000b6df58d6b2965a upstream.

Function kgd2kfd_init is missing a void argument, add it
to clean up the non-ANSI function declaration.

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/gpu/drm/amd/amdkfd/kfd_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_module.c b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
index 986ff52d5750..f4b7f7e6c40e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_module.c
@@ -82,7 +82,7 @@ static void kfd_exit(void)
 	kfd_chardev_exit();
 }
 
-int kgd2kfd_init()
+int kgd2kfd_init(void)
 {
 	return kfd_init();
 }
-- 
2.35.1


^ permalink raw reply related	[relevance 99%]

* [PATCH 5.4 0/2] Fix two instances of -Wstrict-prototypes in drm/amd
@ 2022-04-11 16:43 99% Nathan Chancellor
  2022-04-11 16:43 99% ` [PATCH 5.4 1/2] drm/amdkfd: add missing void argument to function kgd2kfd_init Nathan Chancellor
  2022-04-11 16:43 95% ` [PATCH 5.4 2/2] drm/amdkfd: Fix -Wstrict-prototypes from amdgpu_amdkfd_gfx_10_0_get_functions() Nathan Chancellor
  0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2022-04-11 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Felix Kuehling, Alex Deucher, Nick Desaulniers, amd-gfx, llvm,
	stable, Nathan Chancellor

Hi everyone,

These two patches resolve two instances of -Wstrict-prototypes with
newer versions of clang that are present in 5.4. The main Makefile makes
this a hard error.

The first patch is upstream commit 63617d8b125e ("drm/amdkfd: add
missing void argument to function kgd2kfd_init"), which showed up in
5.5.

The second patch has no upstream equivalent, as the code in question was
removed in commit e392c887df97 ("drm/amdkfd: Use array to probe
kfd2kgd_calls") upstream, which is part of a larger series that did not
look reasonable for stable. I opted to just fix the warning in the same
manner as the prior patch, which is less risky and accomplishes the same
end result of no warning.

Colin Ian King (1):
  drm/amdkfd: add missing void argument to function kgd2kfd_init

Nathan Chancellor (1):
  drm/amdkfd: Fix -Wstrict-prototypes from
    amdgpu_amdkfd_gfx_10_0_get_functions()

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_module.c            | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


base-commit: 2845ff3fd34499603249676495c524a35e795b45
-- 
2.35.1


^ permalink raw reply	[relevance 99%]

* Backport of 4013e26670c5 and 60210a3d86dc for 4.9 to 5.10
@ 2022-04-05 20:58 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-04-05 20:58 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, llvm, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Hi Greg and Sasha,

Please find attached backports for commits 4013e26670c5 ("arm64: module:
remove (NOLOAD) from linker script") and 60210a3d86dc ("riscv module:
remove (NOLOAD)") to 4.9 through 5.10, where applicable. They resolve a
spew of warnings when linking modules with ld.lld. 4013e26670c5 is
currently queued from 5.15 to 5.17 and 60210a3d86dc is queued for 5.10
through 5.17, as that is where they applied cleanly.

Cheers,
Nathan

[-- Attachment #2: 4.9.mbox --]
[-- Type: application/mbox, Size: 1874 bytes --]

[-- Attachment #3: 4.14.mbox --]
[-- Type: application/mbox, Size: 2015 bytes --]

[-- Attachment #4: 4.19.mbox --]
[-- Type: application/mbox, Size: 2015 bytes --]

[-- Attachment #5: 5.4.mbox --]
[-- Type: application/mbox, Size: 3984 bytes --]

[-- Attachment #6: 5.10.mbox --]
[-- Type: application/mbox, Size: 2093 bytes --]

^ permalink raw reply	[relevance 99%]

* [PATCH] btrfs: Remove unused variable in btrfs_{start,write}_dirty_block_groups()
@ 2022-03-24 15:36 92% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-03-24 15:36 UTC (permalink / raw)
  To: Chris Mason, Josef Bacik, David Sterba
  Cc: Nick Desaulniers, linux-btrfs, linux-kernel, llvm, patches,
	Nathan Chancellor, stable

Clang's version of -Wunused-but-set-variable recently gained support for
unary operations, which reveals two unused variables:

  fs/btrfs/block-group.c:2949:6: error: variable 'num_started' set but not used [-Werror,-Wunused-but-set-variable]
          int num_started = 0;
              ^
  fs/btrfs/block-group.c:3116:6: error: variable 'num_started' set but not used [-Werror,-Wunused-but-set-variable]
          int num_started = 0;
              ^
  2 errors generated.

These variables appear to be unused from their introduction, so just
remove them to silence the warnings.

Cc: stable@vger.kernel.org
Fixes: c9dc4c657850 ("Btrfs: two stage dirty block group writeout")
Fixes: 1bbc621ef284 ("Btrfs: allow block group cache writeout outside critical section in commit")
Link: https://github.com/ClangBuiltLinux/linux/issues/1614
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

I am requesting a stable backport because this is visible with
allmodconfig, which enables CONFIG_WERROR, breaking the build.

To quote Linus:

"EVERYBODY should have CONFIG_WERROR=y on at least x86-64 and other
serious architectures, unless you have some completely random
experimental (and broken) compiler."

https://lore.kernel.org/r/CAHk-=wifoM9VOp-55OZCRcO9MnqQ109UTuCiXeZ-eyX_JcNVGg@mail.gmail.com/

 fs/btrfs/block-group.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index c22d287e020b..9ad265066225 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -2946,7 +2946,6 @@ int btrfs_start_dirty_block_groups(struct btrfs_trans_handle *trans)
 	struct btrfs_path *path = NULL;
 	LIST_HEAD(dirty);
 	struct list_head *io = &cur_trans->io_bgs;
-	int num_started = 0;
 	int loops = 0;
 
 	spin_lock(&cur_trans->dirty_bgs_lock);
@@ -3012,7 +3011,6 @@ int btrfs_start_dirty_block_groups(struct btrfs_trans_handle *trans)
 			cache->io_ctl.inode = NULL;
 			ret = btrfs_write_out_cache(trans, cache, path);
 			if (ret == 0 && cache->io_ctl.inode) {
-				num_started++;
 				should_put = 0;
 
 				/*
@@ -3113,7 +3111,6 @@ int btrfs_write_dirty_block_groups(struct btrfs_trans_handle *trans)
 	int should_put;
 	struct btrfs_path *path;
 	struct list_head *io = &cur_trans->io_bgs;
-	int num_started = 0;
 
 	path = btrfs_alloc_path();
 	if (!path)
@@ -3171,7 +3168,6 @@ int btrfs_write_dirty_block_groups(struct btrfs_trans_handle *trans)
 			cache->io_ctl.inode = NULL;
 			ret = btrfs_write_out_cache(trans, cache, path);
 			if (ret == 0 && cache->io_ctl.inode) {
-				num_started++;
 				should_put = 0;
 				list_add_tail(&cache->io_list, io);
 			} else {

base-commit: d3e29967079c522ce1c5cab0e9fab2c280b977eb
-- 
2.35.1


^ permalink raw reply related	[relevance 92%]

* [PATCH] ARM: Do not use NOCROSSREFS directive with ld.lld
@ 2022-03-09 22:07 94% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-03-09 22:07 UTC (permalink / raw)
  To: Linus Torvalds, Russell King, Nick Desaulniers
  Cc: linux-arm-kernel, linux-kernel, llvm, Nathan Chancellor, stable

ld.lld does not support the NOCROSSREFS directive at the moment, which
breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB
workaround"):

  ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS

Support for this directive will eventually be implemented, at which
point a version check can be added. To avoid breaking the build in the
meantime, just define NOCROSSREFS to nothing when using ld.lld, with a
link to the issue for tracking.

Cc: stable@vger.kernel.org
Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Link: https://github.com/ClangBuiltLinux/linux/issues/1609
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

Since b9baf5c8c5c3 has been backported to stable, I have marked this for
stable as well, using a Fixes tag to notate that this should go back to
all releases that have b9baf5c8c5c3, not to indicate any blame of
b9baf5c8c5c3, as this is clearly an ld.lld deficiency.

It would be nice if this could be applied directly to unblock our CI if
there are no objections.

 arch/arm/include/asm/vmlinux.lds.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
index 0ef21bfae9f6..fad45c884e98 100644
--- a/arch/arm/include/asm/vmlinux.lds.h
+++ b/arch/arm/include/asm/vmlinux.lds.h
@@ -26,6 +26,14 @@
 #define ARM_MMU_DISCARD(x)	x
 #endif
 
+/*
+ * ld.lld does not support NOCROSSREFS:
+ * https://github.com/ClangBuiltLinux/linux/issues/1609
+ */
+#ifdef CONFIG_LD_IS_LLD
+#define NOCROSSREFS
+#endif
+
 /* Set start/end symbol names to the LMA for the section */
 #define ARM_LMA(sym, section)						\
 	sym##_start = LOADADDR(section);				\

base-commit: e7e19defa57580d679bf0d03f8a34933008a7930
-- 
2.35.1


^ permalink raw reply related	[relevance 94%]

* [PATCH] arm64: Do not include __READ_ONCE() block in assembly files
@ 2022-03-09 19:16 89% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-03-09 19:16 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon
  Cc: Nick Desaulniers, linux-arm-kernel, linux-kernel, llvm,
	Nathan Chancellor, stable, Marc Zyngier, James Morse

When building arm64 defconfig + CONFIG_LTO_CLANG_{FULL,THIN}=y after
commit 558c303c9734 ("arm64: Mitigate spectre style branch history side
channels"), the following error occurs:

  <instantiation>:4:2: error: invalid fixup for movz/movk instruction
   mov w0, #ARM_SMCCC_ARCH_WORKAROUND_3
   ^

Marc figured out that moving "#include <linux/init.h>" in
include/linux/arm-smccc.h into a !__ASSEMBLY__ block resolves it. The
full include chain with CONFIG_LTO=y from include/linux/arm-smccc.h:

include/linux/init.h
include/linux/compiler.h
arch/arm64/include/asm/rwonce.h
arch/arm64/include/asm/alternative-macros.h
arch/arm64/include/asm/assembler.h

The asm/alternative-macros.h include in asm/rwonce.h only happens when
CONFIG_LTO is set, which ultimately casues asm/assembler.h to be
included before the definition of ARM_SMCCC_ARCH_WORKAROUND_3. As a
result, the preprocessor does not expand ARM_SMCCC_ARCH_WORKAROUND_3 in
__mitigate_spectre_bhb_fw, which results in the error above.

Avoid this problem by just avoiding the CONFIG_LTO=y __READ_ONCE() block
in asm/rwonce.h with assembly files, as nothing in that block is useful
to assembly files, which allows ARM_SMCCC_ARCH_WORKAROUND_3 to be
properly expanded with CONFIG_LTO=y builds.

Cc: stable@vger.kernel.org
Fixes: e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y")
Link: https://lore.kernel.org/r/20220309155716.3988480-1-maz@kernel.org/
Reported-by: Marc Zyngier <maz@kernel.org>
Acked-by: James Morse <james.morse@arm.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

This is based on current mainline; if it should be based on a specific
arm64 branch, please let me know.

As 558c303c9734 is going to stable, I marked this for stable as well to
avoid breaking Android. I used e35123d83ee3 for the fixes tag to make it
clear to the stable team this should only go where that commit is
present. If a different fixes tag should be used, please feel free to
substitute.

 arch/arm64/include/asm/rwonce.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h
index 1bce62fa908a..56f7b1d4d54b 100644
--- a/arch/arm64/include/asm/rwonce.h
+++ b/arch/arm64/include/asm/rwonce.h
@@ -5,7 +5,7 @@
 #ifndef __ASM_RWONCE_H
 #define __ASM_RWONCE_H
 
-#ifdef CONFIG_LTO
+#if defined(CONFIG_LTO) && !defined(__ASSEMBLY__)
 
 #include <linux/compiler_types.h>
 #include <asm/alternative-macros.h>
@@ -66,7 +66,7 @@
 })
 
 #endif	/* !BUILD_VDSO */
-#endif	/* CONFIG_LTO */
+#endif	/* CONFIG_LTO && !__ASSEMBLY__ */
 
 #include <asm-generic/rwonce.h>
 

base-commit: 330f4c53d3c2d8b11d86ec03a964b86dc81452f5
-- 
2.35.1


^ permalink raw reply related	[relevance 89%]

* [PATCH 4.9 to 5.4] Makefile.extrawarn: Move -Wunaligned-access to W=1
@ 2022-02-14 16:16 94% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-02-14 16:16 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Nick Desaulniers, stable, llvm, Nathan Chancellor, Masahiro Yamada

commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream.

-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
1284 total/70 unique instances of this warning (most of the instances
are in header files), which is quite noisy.

To keep a normal build green through CONFIG_WERROR, only show this
warning with W=1, which will allow automated build systems to catch new
instances of the warning so that the total number can be driven down to
zero eventually since catching unaligned accesses at compile time would
be generally useful.

Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
Link: https://github.com/ClangBuiltLinux/linux/issues/1569
Link: https://github.com/ClangBuiltLinux/linux/issues/1576
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nathan: Fix conflict due to lack of afe956c577b2d]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

I am not sure how many people are using ToT clang with ARCH=arm on
stable but given how noisy this warning can be, I think it is worth
applying this to all applicable stable branches.

This applies to 4.9 through 5.4 with 'patch -Np1'.

 scripts/Makefile.extrawarn | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index ca08f2fe7c34..854e2ba9daa2 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -49,6 +49,7 @@ KBUILD_CFLAGS += -Wno-format
 KBUILD_CFLAGS += -Wno-sign-compare
 KBUILD_CFLAGS += -Wno-format-zero-length
 KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
+KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
 endif
 
 endif

base-commit: 52871671099d1bb3fca5ed076029e4b937bfc053
-- 
2.35.1


^ permalink raw reply related	[relevance 94%]

* Re: [PATCH 5.16 000/203] 5.16.10-rc1 review
  @ 2022-02-14 15:37 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-02-14 15:37 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Naresh Kamboju, llvm, Nick Desaulniers, linux-kernel, stable,
	torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
	jonathanh, f.fainelli, sudipm.mukherjee, slade, Arnd Bergmann

On Mon, Feb 14, 2022 at 12:27:33PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 04:29:43PM +0530, Naresh Kamboju wrote:
> > On Mon, 14 Feb 2022 at 15:23, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > This is the start of the stable review cycle for the 5.16.10 release.
> > > There are 203 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed, 16 Feb 2022 09:24:36 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.16.10-rc1.gz
> > > or in the git tree and branch at:
> > >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.16.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > On Linux mainline master branch with arm64 clang-nigtly build failed
> > due to following errors and warnings.
> > Now it is also noticed on stable-rc 5.15 and 5.16.
> 
> Sounds like a compiler error.  Do the clang developers know about this?

Yes, please see my response to Naresh in his other report for more
information:

https://lore.kernel.org/r/Ygp2wVo8JfWh5iOk@dev-arch.archlinux-ax161

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2] Makefile.extrawarn: Move -Wunaligned-access to W=1
  @ 2022-02-08 16:04 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-02-08 16:04 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Nick Desaulniers, Arnd Bergmann, Linux Kbuild mailing list,
	Linux Kernel Mailing List, llvm, stable

On Tue, Feb 08, 2022 at 01:23:32PM +0900, Masahiro Yamada wrote:
> On Thu, Feb 3, 2022 at 8:12 AM Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Feb 2, 2022 at 3:07 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > -Wunaligned-access is a new warning in clang that is default enabled for
> > > arm and arm64 under certain circumstances within the clang frontend (see
> > > LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
> > > 1284 total/70 unique instances of this warning (most of the instances
> > > are in header files), which is quite noisy.
> > >
> > > To keep a normal build green through CONFIG_WERROR, only show this
> > > warning with W=1, which will allow automated build systems to catch new
> > > instances of the warning so that the total number can be driven down to
> > > zero eventually since catching unaligned accesses at compile time would
> > > be generally useful.
> > >
> > > Cc: stable@vger.kernel.org
> > > Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1569
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1576
> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> >
> > Thanks to you and Arnd for working out whether this is important to
> > pursue. Sounds like it is.
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > > ---
> 
> 
> I assume this should be considered as a bug fix
> to avoid the error for the combination of CONFIG_WERROR=y
> and the latest Clang.
> 
> Applied to linux-kbuild/fixes.
> Thanks.

Yes, this is what I was hoping for! Thank you, I'll try to make that
more clear in the future.

Cheers,
Nathan

> > >
> > > v1 -> v2: https://lore.kernel.org/r/20220201232229.2992968-1-nathan@kernel.org/
> > >
> > > * Move to W=1 instead of W=2 so that new instances are caught (Arnd).
> > > * Add links to the ClangBuiltLinux issue tracker.
> > >
> > >  scripts/Makefile.extrawarn | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> > > index d53825503874..8be892887d71 100644
> > > --- a/scripts/Makefile.extrawarn
> > > +++ b/scripts/Makefile.extrawarn
> > > @@ -51,6 +51,7 @@ KBUILD_CFLAGS += -Wno-sign-compare
> > >  KBUILD_CFLAGS += -Wno-format-zero-length
> > >  KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
> > >  KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare
> > > +KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
> > >  endif
> > >
> > >  endif
> > >
> > > base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c
> > > --
> > > 2.35.1
> > >
> >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada

^ permalink raw reply	[relevance 99%]

* Re: [PATCH] ARM: davinci: da850-evm: Avoid NULL pointer dereference
  2021-12-23 22:21 96% [PATCH] ARM: davinci: da850-evm: Avoid NULL pointer dereference Nathan Chancellor
@ 2022-02-03 17:09 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-02-03 17:09 UTC (permalink / raw)
  To: Sekhar Nori
  Cc: Bartosz Golaszewski, linux-arm-kernel, linux-kernel, stable,
	Arnd Bergmann

On Thu, Dec 23, 2021 at 03:21:41PM -0700, Nathan Chancellor wrote:
> With newer versions of GCC, there is a panic in da850_evm_config_emac()
> when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000020
> pgd = (ptrval)
> [00000020] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1
> Hardware name: Generic DT based system
> PC is at da850_evm_config_emac+0x1c/0x120
> LR is at do_one_initcall+0x50/0x1e0
> 
> The emac_pdata pointer in soc_info is NULL because davinci_soc_info only
> gets populated on davinci machines but da850_evm_config_emac() is called
> on all machines via device_initcall().
> 
> Move the rmii_en assignment below the machine check so that it is only
> dereferenced when running on a supported SoC.
> 
> Cc: stable@vger.kernel.org
> Fixes: bae105879f2f ("davinci: DA850/OMAP-L138 EVM: implement autodetect of RMII PHY")
> Link: https://lore.kernel.org/r/YcS4xVWs6bQlQSPC@archlinux-ax161/
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/arm/mach-davinci/board-da850-evm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 428012687a80..7f7f6bae21c2 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1101,11 +1101,13 @@ static int __init da850_evm_config_emac(void)
>  	int ret;
>  	u32 val;
>  	struct davinci_soc_info *soc_info = &davinci_soc_info;
> -	u8 rmii_en = soc_info->emac_pdata->rmii_en;
> +	u8 rmii_en;
>  
>  	if (!machine_is_davinci_da850_evm())
>  		return 0;
>  
> +	rmii_en = soc_info->emac_pdata->rmii_en;
> +
>  	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
>  
>  	val = __raw_readl(cfg_chip3_base);
> 
> base-commit: a7904a538933c525096ca2ccde1e60d0ee62c08e
> -- 
> 2.34.1
> 
> 

Could someone pick this patch up? This is still broken on mainline and
-next.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH v2] Makefile.extrawarn: Move -Wunaligned-access to W=1
@ 2022-02-02 23:05 95% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-02-02 23:05 UTC (permalink / raw)
  To: Masahiro Yamada, Nick Desaulniers, Arnd Bergmann
  Cc: linux-kbuild, linux-kernel, llvm, Nathan Chancellor, stable

-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows
1284 total/70 unique instances of this warning (most of the instances
are in header files), which is quite noisy.

To keep a normal build green through CONFIG_WERROR, only show this
warning with W=1, which will allow automated build systems to catch new
instances of the warning so that the total number can be driven down to
zero eventually since catching unaligned accesses at compile time would
be generally useful.

Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
Link: https://github.com/ClangBuiltLinux/linux/issues/1569
Link: https://github.com/ClangBuiltLinux/linux/issues/1576
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

v1 -> v2: https://lore.kernel.org/r/20220201232229.2992968-1-nathan@kernel.org/

* Move to W=1 instead of W=2 so that new instances are caught (Arnd).
* Add links to the ClangBuiltLinux issue tracker.

 scripts/Makefile.extrawarn | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index d53825503874..8be892887d71 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -51,6 +51,7 @@ KBUILD_CFLAGS += -Wno-sign-compare
 KBUILD_CFLAGS += -Wno-format-zero-length
 KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast)
 KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare
+KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
 endif
 
 endif

base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c
-- 
2.35.1


^ permalink raw reply related	[relevance 95%]

* Re: [PATCH] Makefile.extrawarn: Move -Wunaligned-access to W=2
  @ 2022-02-02 16:26 91%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-02-02 16:26 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Masahiro Yamada, Nick Desaulniers, Linux Kbuild mailing list,
	Linux Kernel Mailing List, llvm, # 3.4.x

On Wed, Feb 02, 2022 at 09:12:06AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 2, 2022 at 12:22 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > -Wunaligned-access is a new warning in clang that is default enabled for
> > arm and arm64 under certain circumstances within the clang frontend (see
> > LLVM commit below). Under an ARCH=arm allmodconfig, there are
> > 1284 total/70 unique instances of this warning (most of the instances
> > are in header files), which is quite noisy.
> >
> > To keep the build green through CONFIG_WERROR, only allow this warning
> > with W=2, which seems appropriate according to its description:
> > "warnings which occur quite often but may still be relevant".
> >
> > This intentionally does not use the -Wno-... + -W... pattern that the
> > rest of the Makefile does because this warning is not enabled for
> > anything other than certain arm and arm64 configurations within clang so
> > it should only be "not disabled", rather than explicitly enabled, so
> > that other architectures are not disturbed by the warning.
> >
> > Cc: stable@vger.kernel.org
> > Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
> The warning seems important enough to be considered for W=1 on 32-bit arm,
> otherwise the chances of anyone actually fixing drivers for it is
> relatively slim.

Fair point, I suppose barely anyone does W=2 builds, which means we
might as well just disable it outright.

> Can you point post the (sufficiently trimmed) output that you get with
> the warning
> enabled in an allmodconfig build?

Sure thing.

Here is the trimmed version:

https://gist.github.com/nathanchance/6682e6894f75790059ca698c29212c71/raw/f63d54819afeb96f3ea0bb055096849912ac0185/trimmed.log

Here is the full output of 'make ARCH=arm LLVM=1 allmodconfig':

https://gist.github.com/nathanchance/6682e6894f75790059ca698c29212c71/raw/f63d54819afeb96f3ea0bb055096849912ac0185/full.log

> I'm not sure why this is enabled by default for arm64, which does not have
> the problem with fixup handlers.

It is not enabled for arm64 for the kernel. If I am reading the commit
right, it is only enabled for arm64 when -mno-unaligned-access is passed
or building for OpenBSD, which obviously don't apply to the kernel (see
AArch64.cpp).

For ARM, we see it in the kernel because it is enabled for any version less
than 7, according to this block in clang/lib/Driver/ToolChains/Arch/ARM.cpp:

    } else if (Triple.isOSLinux() || Triple.isOSNaCl() ||
               Triple.isOSWindows()) {
      if (VersionNum < 7) {
        Features.push_back("+strict-align");
        if (!ForAS)
          CmdArgs.push_back("-Wunaligned-access");
      }

There is this comment above this block in the source code:

    // Assume pre-ARMv6 doesn't support unaligned accesses.
    //
    // ARMv6 may or may not support unaligned accesses depending on the
    // SCTLR.U bit, which is architecture-specific. We assume ARMv6
    // Darwin and NetBSD targets support unaligned accesses, and others don't.
    //
    // ARMv7 always has SCTLR.U set to 1, but it has a new SCTLR.A bit
    // which raises an alignment fault on unaligned accesses. Linux
    // defaults this bit to 0 and handles it as a system-wide (not
    // per-process) setting. It is therefore safe to assume that ARMv7+
    // Linux targets support unaligned accesses. The same goes for NaCl
    // and Windows.
    //
    // The above behavior is consistent with GCC.

I notice that CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS under certain
conditions in arch/arm/Kconfig. Would it be worth telling clang that it
can generate unaligned accesses in those cases via -munaligned-access or
would that be too expensive? If we did, these warnings would be
eliminated for configs with CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y,
then it could be safely placed under W=1.

Cheers,
Nathan

^ permalink raw reply	[relevance 91%]

* [PATCH] Makefile.extrawarn: Move -Wunaligned-access to W=2
@ 2022-02-01 23:22 94% Nathan Chancellor
    0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2022-02-01 23:22 UTC (permalink / raw)
  To: Masahiro Yamada, Nick Desaulniers
  Cc: Arnd Bergmann, linux-kbuild, linux-kernel, llvm,
	Nathan Chancellor, stable

-Wunaligned-access is a new warning in clang that is default enabled for
arm and arm64 under certain circumstances within the clang frontend (see
LLVM commit below). Under an ARCH=arm allmodconfig, there are
1284 total/70 unique instances of this warning (most of the instances
are in header files), which is quite noisy.

To keep the build green through CONFIG_WERROR, only allow this warning
with W=2, which seems appropriate according to its description:
"warnings which occur quite often but may still be relevant".

This intentionally does not use the -Wno-... + -W... pattern that the
rest of the Makefile does because this warning is not enabled for
anything other than certain arm and arm64 configurations within clang so
it should only be "not disabled", rather than explicitly enabled, so
that other architectures are not disturbed by the warning.

Cc: stable@vger.kernel.org
Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 scripts/Makefile.extrawarn | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index d53825503874..5f75fec4d5ac 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -70,6 +70,20 @@ KBUILD_CFLAGS += $(call cc-option, -Wunused-macros)
 
 KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN2
 
+else
+
+ifdef CONFIG_CC_IS_CLANG
+# While this warning is architecture agnostic, it is only default enabled for
+# 32-bit and 64-bit ARM under certain conditions within clang:
+#
+# https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a
+#
+# To allow it to be disabled under a normal build or W=1 but show up under W=2
+# for those configurations, disable it when W=2 is not set, rather than enable
+# -Wunaligned-access in the above block explicitly.
+KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access)
+endif
+
 endif
 
 #

base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c
-- 
2.35.1


^ permalink raw reply related	[relevance 94%]

* Re: [PATCH] usb: dwc3: xilinx: fix uninitialized return value
  @ 2022-01-29 20:55 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-29 20:55 UTC (permalink / raw)
  To: Robert Hancock
  Cc: linux-usb, balbi, gregkh, michal.simek, manish.narani,
	sean.anderson, robh+dt, devicetree, piyush.mehta, stable

On Thu, Jan 27, 2022 at 04:15:00PM -0600, Robert Hancock wrote:
> A previous patch to skip part of the initialization when a USB3 PHY was
> not present could result in the return value being uninitialized in that
> case, causing spurious probe failures. Initialize ret to 0 to avoid this.
> 
> Fixes: 9678f3361afc ("usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Robert Hancock <robert.hancock@calian.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

This resolves a clang warning that is now in mainline:

$ make -sj"$(nproc)" ARCH=arm64 LLVM=1 allmodconfig drivers/usb/dwc3/dwc3-xilinx.o
drivers/usb/dwc3/dwc3-xilinx.c:122:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
        if (!usb3_phy)
            ^~~~~~~~~
drivers/usb/dwc3/dwc3-xilinx.c:216:9: note: uninitialized use occurs here
        return ret;
               ^~~
drivers/usb/dwc3/dwc3-xilinx.c:122:2: note: remove the 'if' if its condition is always false
        if (!usb3_phy)
        ^~~~~~~~~~~~~~
drivers/usb/dwc3/dwc3-xilinx.c:102:11: note: initialize the variable 'ret' to silence this warning
        int                     ret;
                                   ^
                                    = 0
1 error generated.

It might be worth moving the initialization into the if statement

    if (!usb3_phy) {
        ret = 0;
        goto skip_usb3_phy;
    }

as that will avoid hiding warnings of this nature if someone forgets to
set ret on an error path but that is ultimately up to the maintainer.

> ---
>  drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> index e14ac15e24c3..a6f3a9b38789 100644
> --- a/drivers/usb/dwc3/dwc3-xilinx.c
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -99,7 +99,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
>  	struct device		*dev = priv_data->dev;
>  	struct reset_control	*crst, *hibrst, *apbrst;
>  	struct phy		*usb3_phy;
> -	int			ret;
> +	int			ret = 0;
>  	u32			reg;
>  
>  	usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
> -- 
> 2.31.1
> 
> 

^ permalink raw reply	[relevance 99%]

* Re: stable-rc 5.4 queue riscv tinyconfig build failed
  @ 2022-01-25 17:27 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-25 17:27 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Greg Kroah-Hartman, Sasha Levin, lkft-triage, linux-stable, llvm

Hi Naresh,

On Tue, Jan 25, 2022 at 07:18:16PM +0530, Naresh Kamboju wrote:
> Hi Greg,
> 
> Regression found on
> stable-rc 5.4 queue riscv tinyconfig build failed.
> 
> Not sure which patch is causing build failures.
> We will bisect and get back to you.

These should not be recent failures on 5.4, they should have always been
there.

> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/current LLVM_IAS=1 ARCH=riscv
> CROSS_COMPILE=riscv64-linux-gnu- HOSTCC=clang CC=clang
> 
> In file included from /builds/linux/kernel/dma/mapping.c:8:
> In file included from /builds/linux/include/linux/memblock.h:13:
> In file included from /builds/linux/include/linux/mm.h:10:
> In file included from /builds/linux/include/linux/gfp.h:6:
> In file included from /builds/linux/include/linux/mmzone.h:8:
> In file included from /builds/linux/include/linux/spinlock.h:51:
> In file included from /builds/linux/include/linux/preempt.h:78:
> In file included from ./arch/riscv/include/generated/asm/preempt.h:1:
> In file included from /builds/linux/include/asm-generic/preempt.h:5:
> In file included from /builds/linux/include/linux/thread_info.h:22:
> /builds/linux/arch/riscv/include/asm/current.h:30:9: warning: variable
> 'tp' is uninitialized when used here [-Wuninitialized]
>         return tp;
>                ^~
> /builds/linux/arch/riscv/include/asm/current.h:29:33: note: initialize
> the variable 'tp' to silence this warning
>         register struct task_struct *tp __asm__("tp");
>                                        ^
>                                         = NULL

Resolved by commit 52e7c52d2ded ("RISC-V: Stop relying on GCC's register
allocator's hueristics").

It had two follow up fixes:

af2bdf828f79 ("RISC-V: stacktrace: Declare sp_in_global outside ifdef")
8356c379cfba ("RISC-V: gp_in_global needs register keyword")

> clang: warning: argument unused during compilation: '-no-pie'
> [-Wunused-command-line-argument]

Resolved by commit 7f3d349065d0 ("riscv: Use $(LD) instead of $(CC) to
link vDSO"). I don't think that will backport clean but it is not an
error so I would not worry about it.

> In file included from /builds/linux/arch/riscv/kernel/cpu.c:7:
> In file included from /builds/linux/include/linux/seq_file.h:8:
> In file included from /builds/linux/include/linux/mutex.h:14:
> /builds/linux/arch/riscv/include/asm/current.h:30:9: warning: variable
> 'tp' is uninitialized when used here [-Wuninitialized]
>         return tp;
>                ^~
> /builds/linux/arch/riscv/include/asm/current.h:29:33: note: initialize
> the variable 'tp' to silence this warning
>         register struct task_struct *tp __asm__("tp");
>                                        ^
>                                         = NULL
> 1 warning generated.
> 1 warning generated.
> 1 warning generated.
> 1 warning generated.
> <instantiation>:1:1: error: unrecognized instruction mnemonic
> LOCAL _restore_kernel_tpsp
> ^
> /builds/linux/arch/riscv/kernel/entry.S:163:2: note: while in macro
> instantiation
>  SAVE_ALL
>  ^
> <instantiation>:2:2: error: unrecognized instruction mnemonic
>  LOCAL _save_context
>  ^

Should be resolved with commits fdff9911f266 ("RISC-V: Inline the
assembly register save/restore macros") and abc71bf0a703 ("RISC-V: Stop
using LOCAL for the uaccess fixups").

There might be other issues lurking, I would not say we had decent
RISC-V build support with LLVM until maybe 5.10 or so (that is the
version that we start testing RISC-V at in our CI).

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Patches for clang and CONFIG_WERROR (arm64/x86_64)
@ 2022-01-13 22:38 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-13 22:38 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable, llvm, Nick Desaulniers

Hi Greg and Sasha,

Please consider applying the following commits to allow arm64 and x86_64
allmodconfig to compile with CONFIG_WERROR enabled with clang-11 through
clang-14 (the currently supported releases upstream).

502408a61f4b ("staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn()") [5.15, 5.10, 5.4, 4.19, 4.14, 4.9]
2e70570656ad ("drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()") [5.16, 5.15, 5.10, 5.4, 4.19, 4.14, 4.9, 4.4]
144779edf598 ("staging: greybus: fix stack size warning with UBSAN") [5.16, 5.15, 5.10, 5.4]

I primarily care about 5.16 and 5.15, as those are the releases that
have CONFIG_WERROR, but I included all the versions that those patches
should apply cleanly to, as they do fix warnings in the build that
people might see, although I don't think they are worth backporting
further manually until someone complains. 502408a61f4b is already in
5.16.

If there are any issues or objections, please let me know!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH 4.4,4.9] power: reset: ltc2952: Fix use of floating point literals
  @ 2022-01-09 18:59 92% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-09 18:59 UTC (permalink / raw)
  To: gregkh; +Cc: ndesaulniers, sebastian.reichel, stable, Nathan Chancellor

commit 644106cdb89844be2496b21175b7c0c2e0fab381 upstream.

A new commit in LLVM causes an error on the use of 'long double' when
'-mno-x87' is used, which the kernel does through an alias,
'-mno-80387' (see the LLVM commit below for more details around why it
does this).

drivers/power/reset/ltc2952-poweroff.c:162:28: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
        data->wde_interval = 300L * 1E6L;
                                  ^
drivers/power/reset/ltc2952-poweroff.c:162:21: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
        data->wde_interval = 300L * 1E6L;
                           ^
drivers/power/reset/ltc2952-poweroff.c:163:41: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
        data->trigger_delay = ktime_set(2, 500L*1E6L);
                                               ^
3 errors generated.

This happens due to the use of a 'long double' literal. The 'E6' part of
'1E6L' causes the literal to be a 'double' then the 'L' suffix promotes
it to 'long double'.

There is no visible reason for floating point values in this driver, as
the values are only assigned to integer types. Use NSEC_PER_MSEC, which
is the same integer value as '1E6L', to avoid changing functionality but
fix the error.

Fixes: 6647156c00cc ("power: reset: add LTC2952 poweroff driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1497
Link: https://github.com/llvm/llvm-project/commit/a8083d42b1c346e21623a1d36d1f0cadd7801d83
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
[nathan: Resolve conflict due to lack of 8b0e195314fab]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/power/reset/ltc2952-poweroff.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/ltc2952-poweroff.c b/drivers/power/reset/ltc2952-poweroff.c
index 15fed9d8f871..ec54cff108b3 100644
--- a/drivers/power/reset/ltc2952-poweroff.c
+++ b/drivers/power/reset/ltc2952-poweroff.c
@@ -169,8 +169,8 @@ static void ltc2952_poweroff_kill(void)
 
 static void ltc2952_poweroff_default(struct ltc2952_poweroff *data)
 {
-	data->wde_interval = ktime_set(0, 300L*1E6L);
-	data->trigger_delay = ktime_set(2, 500L*1E6L);
+	data->wde_interval = ktime_set(0, 300L * NSEC_PER_MSEC);
+	data->trigger_delay = ktime_set(2, 500L * NSEC_PER_MSEC);
 
 	hrtimer_init(&data->timer_trigger, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
 	data->timer_trigger.function = ltc2952_poweroff_timer_trigger;

base-commit: 710bf39c7aec32641ea63f6593db1df8c3e4a4d7
-- 
2.34.1


^ permalink raw reply related	[relevance 92%]

* [PATCH RFC 4.9 5/5] arm64: sysreg: Move to use definitions for all the SCTLR bits
  2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
                   ` (3 preceding siblings ...)
  2022-01-07 19:43 89% ` [PATCH RFC 4.9 4/5] arm64: move !VHE work to end of el2_setup Nathan Chancellor
@ 2022-01-07 19:43 75% ` Nathan Chancellor
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

From: James Morse <james.morse@arm.com>

[ Upstream commit 7a00d68ebe5f07cb1db17e7fedfd031f0d87e8bb ]

__cpu_setup() configures SCTLR_EL1 using some hard coded hex masks,
and el2_setup() duplicates some this when setting RES1 bits.

Lets make this the same as KVM's hyp_init, which uses named bits.

First, we add definitions for all the SCTLR_EL{1,2} bits, the RES{1,0}
bits, and those we want to set or clear.

Add a build_bug checks to ensures all bits are either set or clear.
This means we don't need to preserve endian-ness configuration
generated elsewhere.

Finally, move the head.S and proc.S users of these hard-coded masks
over to the macro versions.

Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 65 ++++++++++++++++++++++++++++++++-
 arch/arm64/kernel/head.S        | 13 ++-----
 arch/arm64/mm/proc.S            | 24 +-----------
 3 files changed, 67 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 7a9f0a71f441..ae1b31d02784 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -20,6 +20,7 @@
 #ifndef __ASM_SYSREG_H
 #define __ASM_SYSREG_H
 
+#include <asm/compiler.h>
 #include <linux/stringify.h>
 
 #include <asm/opcodes.h>
@@ -88,25 +89,81 @@
 
 /* Common SCTLR_ELx flags. */
 #define SCTLR_ELx_EE    (1 << 25)
+#define SCTLR_ELx_WXN	(1 << 19)
 #define SCTLR_ELx_I	(1 << 12)
 #define SCTLR_ELx_SA	(1 << 3)
 #define SCTLR_ELx_C	(1 << 2)
 #define SCTLR_ELx_A	(1 << 1)
 #define SCTLR_ELx_M	1
 
+#define SCTLR_ELx_FLAGS	(SCTLR_ELx_M | SCTLR_ELx_A | SCTLR_ELx_C | \
+			 SCTLR_ELx_SA | SCTLR_ELx_I)
+
+/* SCTLR_EL2 specific flags. */
 #define SCTLR_EL2_RES1	((1 << 4)  | (1 << 5)  | (1 << 11) | (1 << 16) | \
 			 (1 << 18) | (1 << 22) | (1 << 23) | (1 << 28) | \
 			 (1 << 29))
+#define SCTLR_EL2_RES0	((1 << 6)  | (1 << 7)  | (1 << 8)  | (1 << 9)  | \
+			 (1 << 10) | (1 << 13) | (1 << 14) | (1 << 15) | \
+			 (1 << 17) | (1 << 20) | (1 << 21) | (1 << 24) | \
+			 (1 << 26) | (1 << 27) | (1 << 30) | (1 << 31))
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define ENDIAN_SET_EL2		SCTLR_ELx_EE
+#define ENDIAN_CLEAR_EL2	0
+#else
+#define ENDIAN_SET_EL2		0
+#define ENDIAN_CLEAR_EL2	SCTLR_ELx_EE
+#endif
+
+/* SCTLR_EL2 value used for the hyp-stub */
+#define SCTLR_EL2_SET	(ENDIAN_SET_EL2   | SCTLR_EL2_RES1)
+#define SCTLR_EL2_CLEAR	(SCTLR_ELx_M      | SCTLR_ELx_A    | SCTLR_ELx_C   | \
+			 SCTLR_ELx_SA     | SCTLR_ELx_I    | SCTLR_ELx_WXN | \
+			 ENDIAN_CLEAR_EL2 | SCTLR_EL2_RES0)
+
+/* Check all the bits are accounted for */
+#define SCTLR_EL2_BUILD_BUG_ON_MISSING_BITS	BUILD_BUG_ON((SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != ~0)
 
-#define SCTLR_ELx_FLAGS	(SCTLR_ELx_M | SCTLR_ELx_A | SCTLR_ELx_C | \
-			 SCTLR_ELx_SA | SCTLR_ELx_I)
 
 /* SCTLR_EL1 specific flags. */
 #define SCTLR_EL1_UCI		(1 << 26)
+#define SCTLR_EL1_E0E		(1 << 24)
 #define SCTLR_EL1_SPAN		(1 << 23)
+#define SCTLR_EL1_NTWE		(1 << 18)
+#define SCTLR_EL1_NTWI		(1 << 16)
 #define SCTLR_EL1_UCT		(1 << 15)
+#define SCTLR_EL1_DZE		(1 << 14)
+#define SCTLR_EL1_UMA		(1 << 9)
 #define SCTLR_EL1_SED		(1 << 8)
+#define SCTLR_EL1_ITD		(1 << 7)
 #define SCTLR_EL1_CP15BEN	(1 << 5)
+#define SCTLR_EL1_SA0		(1 << 4)
+
+#define SCTLR_EL1_RES1	((1 << 11) | (1 << 20) | (1 << 22) | (1 << 28) | \
+			 (1 << 29))
+#define SCTLR_EL1_RES0  ((1 << 6)  | (1 << 10) | (1 << 13) | (1 << 17) | \
+			 (1 << 21) | (1 << 27) | (1 << 30) | (1 << 31))
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define ENDIAN_SET_EL1		(SCTLR_EL1_E0E | SCTLR_ELx_EE)
+#define ENDIAN_CLEAR_EL1	0
+#else
+#define ENDIAN_SET_EL1		0
+#define ENDIAN_CLEAR_EL1	(SCTLR_EL1_E0E | SCTLR_ELx_EE)
+#endif
+
+#define SCTLR_EL1_SET	(SCTLR_ELx_M    | SCTLR_ELx_C    | SCTLR_ELx_SA   |\
+			 SCTLR_EL1_SA0  | SCTLR_EL1_SED  | SCTLR_ELx_I    |\
+			 SCTLR_EL1_DZE  | SCTLR_EL1_UCT  | SCTLR_EL1_NTWI |\
+			 SCTLR_EL1_NTWE | SCTLR_EL1_SPAN | ENDIAN_SET_EL1 |\
+			 SCTLR_EL1_UCI  | SCTLR_EL1_RES1)
+#define SCTLR_EL1_CLEAR	(SCTLR_ELx_A   | SCTLR_EL1_CP15BEN | SCTLR_EL1_ITD    |\
+			 SCTLR_EL1_UMA | SCTLR_ELx_WXN     | ENDIAN_CLEAR_EL1 |\
+			 SCTLR_EL1_RES0)
+
+/* Check all the bits are accounted for */
+#define SCTLR_EL1_BUILD_BUG_ON_MISSING_BITS	BUILD_BUG_ON((SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != ~0)
 
 /* id_aa64isar0 */
 #define ID_AA64ISAR0_RDM_SHIFT		28
@@ -244,6 +301,7 @@
 
 #else
 
+#include <linux/build_bug.h>
 #include <linux/types.h>
 
 asm(
@@ -300,6 +358,9 @@ static inline void config_sctlr_el1(u32 clear, u32 set)
 {
 	u32 val;
 
+	SCTLR_EL2_BUILD_BUG_ON_MISSING_BITS;
+	SCTLR_EL1_BUILD_BUG_ON_MISSING_BITS;
+
 	val = read_sysreg(sctlr_el1);
 	val &= ~clear;
 	val |= set;
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index c067b13e93cc..04f81675b6b3 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -490,17 +490,13 @@ ENTRY(el2_setup)
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
 	b.eq	1f
-	mrs	x0, sctlr_el1
-CPU_BE(	orr	x0, x0, #(3 << 24)	)	// Set the EE and E0E bits for EL1
-CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
+	mov_q	x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
 	msr	sctlr_el1, x0
 	mov	w0, #BOOT_CPU_MODE_EL1		// This cpu booted in EL1
 	isb
 	ret
 
-1:	mrs	x0, sctlr_el2
-CPU_BE(	orr	x0, x0, #(1 << 25)	)	// Set the EE bit for EL2
-CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
+1:	mov_q	x0, (SCTLR_EL2_RES1 | ENDIAN_SET_EL2)
 	msr	sctlr_el2, x0
 
 #ifdef CONFIG_ARM64_VHE
@@ -585,10 +581,7 @@ install_el2_stub:
 	 * requires no configuration, and all non-hyp-specific EL2 setup
 	 * will be done via the _EL1 system register aliases in __cpu_setup.
 	 */
-	/* sctlr_el1 */
-	mov	x0, #0x0800			// Set/clear RES{1,0} bits
-CPU_BE(	movk	x0, #0x33d0, lsl #16	)	// Set EE and E0E on BE systems
-CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
+	mov_q	x0, (SCTLR_EL1_RES1 | ENDIAN_SET_EL1)
 	msr	sctlr_el1, x0
 
 	/* Coprocessor traps. */
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 1b91b8c8999b..266211a0ecd6 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -413,11 +413,7 @@ ENTRY(__cpu_setup)
 	/*
 	 * Prepare SCTLR
 	 */
-	adr	x5, crval
-	ldp	w5, w6, [x5]
-	mrs	x0, sctlr_el1
-	bic	x0, x0, x5			// clear bits
-	orr	x0, x0, x6			// set bits
+	mov_q	x0, SCTLR_EL1_SET
 	/*
 	 * Set/prepare TCR and TTBR. We use 512GB (39-bit) address range for
 	 * both user and kernel.
@@ -453,21 +449,3 @@ ENTRY(__cpu_setup)
 	msr	tcr_el1, x10
 	ret					// return to head.S
 ENDPROC(__cpu_setup)
-
-	/*
-	 * We set the desired value explicitly, including those of the
-	 * reserved bits. The values of bits EE & E0E were set early in
-	 * el2_setup, which are left untouched below.
-	 *
-	 *                 n n            T
-	 *       U E      WT T UD     US IHBS
-	 *       CE0      XWHW CZ     ME TEEA S
-	 * .... .IEE .... NEAI TE.I ..AD DEN0 ACAM
-	 * 0011 0... 1101 ..0. ..0. 10.. .0.. .... < hardware reserved
-	 * .... .1.. .... 01.1 11.1 ..01 0.01 1101 < software settings
-	 */
-	.type	crval, #object
-crval:
-	.word	0xfcffffff			// clear
-	.word	0x34d5d91d			// set
-	.popsection
-- 
2.34.1


^ permalink raw reply related	[relevance 75%]

* [PATCH RFC 4.9 4/5] arm64: move !VHE work to end of el2_setup
  2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
                   ` (2 preceding siblings ...)
  2022-01-07 19:43 93% ` [PATCH RFC 4.9 3/5] arm64: reduce el2_setup branching Nathan Chancellor
@ 2022-01-07 19:43 89% ` Nathan Chancellor
  2022-01-07 19:43 75% ` [PATCH RFC 4.9 5/5] arm64: sysreg: Move to use definitions for all the SCTLR bits Nathan Chancellor
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

From: Mark Rutland <mark.rutland@arm.com>

commit d61c97a7773d0848b4bf5c4697855c7ce117362c upstream.

We only need to initialise sctlr_el1 if we're installing an EL2 stub, so
we may as well defer this until we're doing so. Similarly, we can defer
intialising CPTR_EL2 until then, as we do not access any trapped
functionality as part of el2_setup.

This patch modified el2_setup accordingly, allowing us to remove a
branch and simplify the code flow.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/arm64/kernel/head.S | 37 +++++++++++++++++--------------------
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index b15abc6ae4af..c067b13e93cc 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -553,26 +553,6 @@ set_hcr:
 	msr	vpidr_el2, x0
 	msr	vmpidr_el2, x1
 
-	/*
-	 * When VHE is not in use, early init of EL2 and EL1 needs to be
-	 * done here.
-	 * When VHE _is_ in use, EL1 will not be used in the host and
-	 * requires no configuration, and all non-hyp-specific EL2 setup
-	 * will be done via the _EL1 system register aliases in __cpu_setup.
-	 */
-	cbnz	x2, 1f
-
-	/* sctlr_el1 */
-	mov	x0, #0x0800			// Set/clear RES{1,0} bits
-CPU_BE(	movk	x0, #0x33d0, lsl #16	)	// Set EE and E0E on BE systems
-CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
-	msr	sctlr_el1, x0
-
-	/* Coprocessor traps. */
-	mov	x0, #0x33ff
-	msr	cptr_el2, x0			// Disable copro. traps to EL2
-1:
-
 #ifdef CONFIG_COMPAT
 	msr	hstr_el2, xzr			// Disable CP15 traps to EL2
 #endif
@@ -598,6 +578,23 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
 	ret
 
 install_el2_stub:
+	/*
+	 * When VHE is not in use, early init of EL2 and EL1 needs to be
+	 * done here.
+	 * When VHE _is_ in use, EL1 will not be used in the host and
+	 * requires no configuration, and all non-hyp-specific EL2 setup
+	 * will be done via the _EL1 system register aliases in __cpu_setup.
+	 */
+	/* sctlr_el1 */
+	mov	x0, #0x0800			// Set/clear RES{1,0} bits
+CPU_BE(	movk	x0, #0x33d0, lsl #16	)	// Set EE and E0E on BE systems
+CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
+	msr	sctlr_el1, x0
+
+	/* Coprocessor traps. */
+	mov	x0, #0x33ff
+	msr	cptr_el2, x0			// Disable copro. traps to EL2
+
 	/* Hypervisor stub */
 	adrp	x0, __hyp_stub_vectors
 	add	x0, x0, #:lo12:__hyp_stub_vectors
-- 
2.34.1


^ permalink raw reply related	[relevance 89%]

* [PATCH RFC 4.9 3/5] arm64: reduce el2_setup branching
  2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
  2022-01-07 19:43 69% ` [PATCH RFC 4.9 1/5] bug: split BUILD_BUG stuff out into <linux/build_bug.h> Nathan Chancellor
  2022-01-07 19:43 99% ` [PATCH RFC 4.9 2/5] arm64: Remove a redundancy in sysreg.h Nathan Chancellor
@ 2022-01-07 19:43 93% ` Nathan Chancellor
  2022-01-07 19:43 89% ` [PATCH RFC 4.9 4/5] arm64: move !VHE work to end of el2_setup Nathan Chancellor
  2022-01-07 19:43 75% ` [PATCH RFC 4.9 5/5] arm64: sysreg: Move to use definitions for all the SCTLR bits Nathan Chancellor
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

From: Mark Rutland <mark.rutland@arm.com>

commit 3ad47d055aa88d9f4189253f5b5c485f4c4626b2 upstream.

The early el2_setup code is a little convoluted, with two branches where
one would do. This makes the code more painful to read than is
necessary.

We can remove a branch and simplify the logic by moving the early return
in the booted-at-EL1 case earlier in the function. This separates it
from all the setup logic that only makes sense for EL2.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/arm64/kernel/head.S | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 387542383662..b15abc6ae4af 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -489,13 +489,8 @@ ENTRY(el2_setup)
 	msr	SPsel, #1			// We want to use SP_EL{1,2}
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
-	b.ne	1f
-	mrs	x0, sctlr_el2
-CPU_BE(	orr	x0, x0, #(1 << 25)	)	// Set the EE bit for EL2
-CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
-	msr	sctlr_el2, x0
-	b	2f
-1:	mrs	x0, sctlr_el1
+	b.eq	1f
+	mrs	x0, sctlr_el1
 CPU_BE(	orr	x0, x0, #(3 << 24)	)	// Set the EE and E0E bits for EL1
 CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	msr	sctlr_el1, x0
@@ -503,7 +498,11 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	isb
 	ret
 
-2:
+1:	mrs	x0, sctlr_el2
+CPU_BE(	orr	x0, x0, #(1 << 25)	)	// Set the EE bit for EL2
+CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
+	msr	sctlr_el2, x0
+
 #ifdef CONFIG_ARM64_VHE
 	/*
 	 * Check for VHE being present. For the rest of the EL2 setup,
-- 
2.34.1


^ permalink raw reply related	[relevance 93%]

* [PATCH RFC 4.9 2/5] arm64: Remove a redundancy in sysreg.h
  2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
  2022-01-07 19:43 69% ` [PATCH RFC 4.9 1/5] bug: split BUILD_BUG stuff out into <linux/build_bug.h> Nathan Chancellor
@ 2022-01-07 19:43 99% ` Nathan Chancellor
  2022-01-07 19:43 93% ` [PATCH RFC 4.9 3/5] arm64: reduce el2_setup branching Nathan Chancellor
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

From: Stefan Traby <stefan@hello-penguin.com>

commit d38338e396ee0571b3502962fd2fbaec4d2d9a8f upstream.

This is really trivial; there is a dup (1 << 16) in the code

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Stefan Traby <stefan@hello-penguin.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/arm64/include/asm/sysreg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 88bbe364b6ae..7a9f0a71f441 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -95,8 +95,8 @@
 #define SCTLR_ELx_M	1
 
 #define SCTLR_EL2_RES1	((1 << 4)  | (1 << 5)  | (1 << 11) | (1 << 16) | \
-			 (1 << 16) | (1 << 18) | (1 << 22) | (1 << 23) | \
-			 (1 << 28) | (1 << 29))
+			 (1 << 18) | (1 << 22) | (1 << 23) | (1 << 28) | \
+			 (1 << 29))
 
 #define SCTLR_ELx_FLAGS	(SCTLR_ELx_M | SCTLR_ELx_A | SCTLR_ELx_C | \
 			 SCTLR_ELx_SA | SCTLR_ELx_I)
-- 
2.34.1


^ permalink raw reply related	[relevance 99%]

* [PATCH RFC 4.9 1/5] bug: split BUILD_BUG stuff out into <linux/build_bug.h>
  2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
@ 2022-01-07 19:43 69% ` Nathan Chancellor
  2022-01-07 19:43 99% ` [PATCH RFC 4.9 2/5] arm64: Remove a redundancy in sysreg.h Nathan Chancellor
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

From: Ian Abbott <abbotti@mev.co.uk>

commit bc6245e5efd70c41eaf9334b1b5e646745cb0fb3 upstream.

Including <linux/bug.h> pulls in a lot of bloat from <asm/bug.h> and
<asm-generic/bug.h> that is not needed to call the BUILD_BUG() family of
macros.  Split them out into their own header, <linux/build_bug.h>.

Also correct some checkpatch.pl errors for the BUILD_BUG_ON_ZERO() and
BUILD_BUG_ON_NULL() macros by adding parentheses around the bitfield
widths that begin with a minus sign.

Link: http://lkml.kernel.org/r/20170525120316.24473-6-abbotti@mev.co.uk
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[nathan: Just take this patch, not the checkpatch.pl patches before it]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 include/linux/bug.h       | 72 +--------------------------------
 include/linux/build_bug.h | 84 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+), 71 deletions(-)
 create mode 100644 include/linux/build_bug.h

diff --git a/include/linux/bug.h b/include/linux/bug.h
index 0faae96302bd..eafb6213e582 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -3,6 +3,7 @@
 
 #include <asm/bug.h>
 #include <linux/compiler.h>
+#include <linux/build_bug.h>
 
 enum bug_trap_type {
 	BUG_TRAP_TYPE_NONE = 0,
@@ -13,80 +14,9 @@ enum bug_trap_type {
 struct pt_regs;
 
 #ifdef __CHECKER__
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
-#define BUILD_BUG_ON_ZERO(e) (0)
-#define BUILD_BUG_ON_NULL(e) ((void*)0)
-#define BUILD_BUG_ON_INVALID(e) (0)
-#define BUILD_BUG_ON_MSG(cond, msg) (0)
-#define BUILD_BUG_ON(condition) (0)
-#define BUILD_BUG() (0)
 #define MAYBE_BUILD_BUG_ON(cond) (0)
 #else /* __CHECKER__ */
 
-/* Force a compilation error if a constant expression is not a power of 2 */
-#define __BUILD_BUG_ON_NOT_POWER_OF_2(n)	\
-	BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
-#define BUILD_BUG_ON_NOT_POWER_OF_2(n)			\
-	BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
-
-/* Force a compilation error if condition is true, but also produce a
-   result (of value 0 and type size_t), so the expression can be used
-   e.g. in a structure initializer (or where-ever else comma expressions
-   aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
-#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
-
-/*
- * BUILD_BUG_ON_INVALID() permits the compiler to check the validity of the
- * expression but avoids the generation of any code, even if that expression
- * has side-effects.
- */
-#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
-
-/**
- * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
- *		      error message.
- * @condition: the condition which the compiler should know is false.
- *
- * See BUILD_BUG_ON for description.
- */
-#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
-
-/**
- * BUILD_BUG_ON - break compile if a condition is true.
- * @condition: the condition which the compiler should know is false.
- *
- * If you have some code which relies on certain constants being equal, or
- * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
- * detect if someone changes it.
- *
- * The implementation uses gcc's reluctance to create a negative array, but gcc
- * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
- * inline functions).  Luckily, in 4.3 they added the "error" function
- * attribute just for this type of case.  Thus, we use a negative sized array
- * (should always create an error on gcc versions older than 4.4) and then call
- * an undefined function with the error attribute (should always create an
- * error on gcc 4.3 and later).  If for some reason, neither creates a
- * compile-time error, we'll still have a link-time error, which is harder to
- * track down.
- */
-#ifndef __OPTIMIZE__
-#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
-#else
-#define BUILD_BUG_ON(condition) \
-	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
-#endif
-
-/**
- * BUILD_BUG - break compile if used.
- *
- * If you have some code that you expect the compiler to eliminate at
- * build time, you should use BUILD_BUG to detect if it is
- * unexpectedly used.
- */
-#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
-
 #define MAYBE_BUILD_BUG_ON(cond)			\
 	do {						\
 		if (__builtin_constant_p((cond)))       \
diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
new file mode 100644
index 000000000000..b7d22d60008a
--- /dev/null
+++ b/include/linux/build_bug.h
@@ -0,0 +1,84 @@
+#ifndef _LINUX_BUILD_BUG_H
+#define _LINUX_BUILD_BUG_H
+
+#include <linux/compiler.h>
+
+#ifdef __CHECKER__
+#define __BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n) (0)
+#define BUILD_BUG_ON_ZERO(e) (0)
+#define BUILD_BUG_ON_NULL(e) ((void *)0)
+#define BUILD_BUG_ON_INVALID(e) (0)
+#define BUILD_BUG_ON_MSG(cond, msg) (0)
+#define BUILD_BUG_ON(condition) (0)
+#define BUILD_BUG() (0)
+#else /* __CHECKER__ */
+
+/* Force a compilation error if a constant expression is not a power of 2 */
+#define __BUILD_BUG_ON_NOT_POWER_OF_2(n)	\
+	BUILD_BUG_ON(((n) & ((n) - 1)) != 0)
+#define BUILD_BUG_ON_NOT_POWER_OF_2(n)			\
+	BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
+
+/*
+ * Force a compilation error if condition is true, but also produce a
+ * result (of value 0 and type size_t), so the expression can be used
+ * e.g. in a structure initializer (or where-ever else comma expressions
+ * aren't permitted).
+ */
+#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
+#define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:(-!!(e)); }))
+
+/*
+ * BUILD_BUG_ON_INVALID() permits the compiler to check the validity of the
+ * expression but avoids the generation of any code, even if that expression
+ * has side-effects.
+ */
+#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
+
+/**
+ * BUILD_BUG_ON_MSG - break compile if a condition is true & emit supplied
+ *		      error message.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * See BUILD_BUG_ON for description.
+ */
+#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
+
+/**
+ * BUILD_BUG_ON - break compile if a condition is true.
+ * @condition: the condition which the compiler should know is false.
+ *
+ * If you have some code which relies on certain constants being equal, or
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * detect if someone changes it.
+ *
+ * The implementation uses gcc's reluctance to create a negative array, but gcc
+ * (as of 4.4) only emits that error for obvious cases (e.g. not arguments to
+ * inline functions).  Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case.  Thus, we use a negative sized array
+ * (should always create an error on gcc versions older than 4.4) and then call
+ * an undefined function with the error attribute (should always create an
+ * error on gcc 4.3 and later).  If for some reason, neither creates a
+ * compile-time error, we'll still have a link-time error, which is harder to
+ * track down.
+ */
+#ifndef __OPTIMIZE__
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+#else
+#define BUILD_BUG_ON(condition) \
+	BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
+#endif
+
+/**
+ * BUILD_BUG - break compile if used.
+ *
+ * If you have some code that you expect the compiler to eliminate at
+ * build time, you should use BUILD_BUG to detect if it is
+ * unexpectedly used.
+ */
+#define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
+
+#endif	/* __CHECKER__ */
+
+#endif	/* _LINUX_BUILD_BUG_H */
-- 
2.34.1


^ permalink raw reply related	[relevance 69%]

* [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+
@ 2022-01-07 19:43 85% Nathan Chancellor
  2022-01-07 19:43 69% ` [PATCH RFC 4.9 1/5] bug: split BUILD_BUG stuff out into <linux/build_bug.h> Nathan Chancellor
                   ` (4 more replies)
  0 siblings, 5 replies; 200+ results
From: Nathan Chancellor @ 2022-01-07 19:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Catalin Marinas, Will Deacon
  Cc: Mark Rutland, Marc Zyngier, Nick Desaulniers, linux-arm-kernel,
	stable, llvm

Hello everyone,

After upgrading the version of QEMU used in our CI from 4.2.0 to 6.2.0,
I noticed that our 4.9 arm64 big endian builds stopped booting properly.
This is not something that is clang specific, I could reproduce it with
GCC 8.3.0 (the rootfs is at [1]).

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- distclean defconfig

$ scripts/config -e CPU_BIG_ENDIAN

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- olddefconfig Image.gz

$ qemu-system-aarch64 \
    -initrd rootfs.cpio \
    -append 'console=ttyAMA0 earlycon' \
    -cpu max \
    -machine virt,gic-version=max \
    -machine virtualization=true \
    -display none \
    -kernel arch/arm64/boot/Image.gz \
    -m 512m \
    -nodefaults \
    -serial mon:stdio
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.296 (nathan@archlinux-ax161) (gcc version 8.3.0 (Debian 8.3.0-2) ) #1 SMP PREEMPT Fri Jan 7 19:10:49 UTC 2022
...
[    0.773924] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    0.773924]
[    0.776016] CPU: 0 PID: 1 Comm: init Not tainted 4.9.296 #1
[    0.776149] Hardware name: linux,dummy-virt (DT)
[    0.776375] Call trace:
[    0.777063] [<ffff000008088ba0>] dump_backtrace+0x0/0x1b0
[    0.777293] [<ffff000008088d64>] show_stack+0x14/0x20
[    0.777420] [<ffff0000088c2d18>] dump_stack+0x98/0xb8
[    0.777555] [<ffff0000088c0ee8>] panic+0x11c/0x278
[    0.777684] [<ffff0000080c4d20>] do_exit+0x940/0x970
[    0.777816] [<ffff0000080c4db8>] do_group_exit+0x38/0xa0
[    0.777974] [<ffff0000080cf698>] get_signal+0xb8/0x678
[    0.778111] [<ffff000008087ca8>] do_signal+0xd8/0x9b0
[    0.778248] [<ffff0000080888dc>] do_notify_resume+0x8c/0xa8
[    0.778392] [<ffff000008082ff4>] work_pending+0x8/0x10
[    0.778790] Kernel Offset: disabled
[    0.778891] Memory Limit: none
[    0.779241] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

I ended up bisecting QEMU down to cd3f80aba0 ("target/arm: Enable
ARMv8.1-VHE in -cpu max") [2], which did not seem obviously broken. I
noticed that our 4.14 builds were fine so I ended up doing a reverse
bisect down to commit ec347012bbec ("arm64: sysreg: Move to use
definitions for all the SCTLR bits"). Getting that change to apply
cleanly involved applying the three other arm64 patches in this series
and making it build properly required the BUILD_BUG_ON header split
(including bug.h might have been sufficient but I did not want to risk
any further breakage). I searched through mainline to see if there were
any fixes commits that I missed and I did not find any.

I am not sure if this series would be acceptable in 4.9, hence the RFC
tag. If not, I am happy to just spin down our boot tests of arm64 big
endian on 4.9, which is not a super valuable target, but I figured I
would send the series and let others decide!

[1]: https://github.com/ClangBuiltLinux/boot-utils/tree/6cfa15992d375dfb874ca0677abdaebfba4f74e6/images/arm64be
[2]: https://gitlab.com/qemu-project/qemu/-/commit/cd3f80aba0c559a6291f7c3e686422b15381f6b7

Cheers,
Nathan

Ian Abbott (1):
  bug: split BUILD_BUG stuff out into <linux/build_bug.h>

James Morse (1):
  arm64: sysreg: Move to use definitions for all the SCTLR bits

Mark Rutland (2):
  arm64: reduce el2_setup branching
  arm64: move !VHE work to end of el2_setup

Stefan Traby (1):
  arm64: Remove a redundancy in sysreg.h

 arch/arm64/include/asm/sysreg.h | 69 +++++++++++++++++++++++++--
 arch/arm64/kernel/head.S        | 49 ++++++++-----------
 arch/arm64/mm/proc.S            | 24 +---------
 include/linux/bug.h             | 72 +---------------------------
 include/linux/build_bug.h       | 84 +++++++++++++++++++++++++++++++++
 5 files changed, 170 insertions(+), 128 deletions(-)
 create mode 100644 include/linux/build_bug.h


base-commit: 710bf39c7aec32641ea63f6593db1df8c3e4a4d7
-- 
2.34.1


^ permalink raw reply	[relevance 85%]

* [PATCH 5.4] Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40
@ 2022-01-03 19:29 92% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2022-01-03 19:29 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Nick Desaulniers, stable, llvm, Anders Roxell, Nathan Chancellor

Upstream commit a02dcde595f7 ("Input: touchscreen - avoid bitwise vs
logical OR warning") was applied as commit f6e9e7be9b80 ("Input:
touchscreen - avoid bitwise vs logical OR warning") in linux-5.4.y but
it did not properly account for commit d9265e8a878a ("Input:
of_touchscreen - add support for touchscreen-min-x|y"), which means the
warning mentioned in the commit message is not fully fixed:

drivers/input/touchscreen/of_touchscreen.c:78:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
        data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:78:17: note: cast one or both operands to int to silence this warning
drivers/input/touchscreen/of_touchscreen.c:92:17: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
        data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/touchscreen/of_touchscreen.c:92:17: note: cast one or both operands to int to silence this warning
2 warnings generated.

It seems like the 4.19 backport was applied to the 5.4 tree, which did
not have any conflicts so no issue was noticed at that point.

Fix up the backport to bring it more in line with the upstream version
so that there is no warning.

Fixes: f6e9e7be9b80 ("Input: touchscreen - avoid bitwise vs logical OR warning")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/input/touchscreen/of_touchscreen.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/of_touchscreen.c b/drivers/input/touchscreen/of_touchscreen.c
index 2962c3747adc..ed5fbcb40e3f 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -77,8 +77,8 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 	axis = multitouch ? ABS_MT_POSITION_X : ABS_X;
 	data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-x",
 						input_abs_get_min(input, axis),
-						&minimum) |
-		       touchscreen_get_prop_u32(dev, "touchscreen-size-x",
+						&minimum);
+	data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-x",
 						input_abs_get_max(input,
 								  axis) + 1,
 						&maximum);
@@ -91,8 +91,8 @@ void touchscreen_parse_properties(struct input_dev *input, bool multitouch,
 	axis = multitouch ? ABS_MT_POSITION_Y : ABS_Y;
 	data_present = touchscreen_get_prop_u32(dev, "touchscreen-min-y",
 						input_abs_get_min(input, axis),
-						&minimum) |
-		       touchscreen_get_prop_u32(dev, "touchscreen-size-y",
+						&minimum);
+	data_present |= touchscreen_get_prop_u32(dev, "touchscreen-size-y",
 						input_abs_get_max(input,
 								  axis) + 1,
 						&maximum);

base-commit: 4ca2eaf1d477ce4316989b22e765fb915652b86e
-- 
2.34.1


^ permalink raw reply related	[relevance 92%]

* [PATCH] ARM: davinci: da850-evm: Avoid NULL pointer dereference
@ 2021-12-23 22:21 96% Nathan Chancellor
  2022-02-03 17:09 99% ` Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-12-23 22:21 UTC (permalink / raw)
  To: Sekhar Nori
  Cc: Bartosz Golaszewski, linux-arm-kernel, linux-kernel,
	Nathan Chancellor, stable, Arnd Bergmann

With newer versions of GCC, there is a panic in da850_evm_config_emac()
when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine:

Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = (ptrval)
[00000020] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1
Hardware name: Generic DT based system
PC is at da850_evm_config_emac+0x1c/0x120
LR is at do_one_initcall+0x50/0x1e0

The emac_pdata pointer in soc_info is NULL because davinci_soc_info only
gets populated on davinci machines but da850_evm_config_emac() is called
on all machines via device_initcall().

Move the rmii_en assignment below the machine check so that it is only
dereferenced when running on a supported SoC.

Cc: stable@vger.kernel.org
Fixes: bae105879f2f ("davinci: DA850/OMAP-L138 EVM: implement autodetect of RMII PHY")
Link: https://lore.kernel.org/r/YcS4xVWs6bQlQSPC@archlinux-ax161/
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/arm/mach-davinci/board-da850-evm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 428012687a80..7f7f6bae21c2 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1101,11 +1101,13 @@ static int __init da850_evm_config_emac(void)
 	int ret;
 	u32 val;
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
-	u8 rmii_en = soc_info->emac_pdata->rmii_en;
+	u8 rmii_en;
 
 	if (!machine_is_davinci_da850_evm())
 		return 0;
 
+	rmii_en = soc_info->emac_pdata->rmii_en;
+
 	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
 
 	val = __raw_readl(cfg_chip3_base);

base-commit: a7904a538933c525096ca2ccde1e60d0ee62c08e
-- 
2.34.1


^ permalink raw reply related	[relevance 96%]

* Apply a52f8a59aef46b59753e583bf4b28fccb069ce64 to 5.15 through 4.19
@ 2021-11-15 18:39 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-11-15 18:39 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Kees Cook, Nick Desaulniers; +Cc: stable, llvm

Hi Greg and Sasha,

There is a build error with newer versions of clang due to a broken
FORTIFY_SOURCE implementation, which has never worked:

https://github.com/ClangBuiltLinux/linux/issues/1496
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/1457787760

Please apply upstream commit a52f8a59aef4 ("fortify: Explicitly disable
Clang support") to 5.15 through 4.19 to resolve this. It should apply
cleanly.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH v2 2/3] hexagon: Clean up timer-regs.h
       [not found]     <20211115174250.1994179-1-nathan@kernel.org>
  2021-11-15 17:42 96% ` [PATCH v2 1/3] hexagon: Export raw I/O routines for modules Nathan Chancellor
@ 2021-11-15 17:42 86% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-11-15 17:42 UTC (permalink / raw)
  To: Andrew Morton, Brian Cain
  Cc: linux-hexagon, Nick Desaulniers, linux-kernel, llvm,
	Nathan Chancellor, stable

When building allmodconfig, there is a warning about TIMER_ENABLE being
redefined:

 drivers/clocksource/timer-oxnas-rps.c:39:9: error: 'TIMER_ENABLE' macro redefined [-Werror,-Wmacro-redefined]
 #define TIMER_ENABLE            BIT(7)
         ^
 ./arch/hexagon/include/asm/timer-regs.h:13:9: note: previous definition is here
 #define TIMER_ENABLE            0
         ^
 1 error generated.

The values in this header are only used in one file each, if they are
used at all. Remove the header and sink all of the constants into their
respective files.

TCX0_CLK_RATE is only used in arch/hexagon/include/asm/timex.h

TIMER_ENABLE, RTOS_TIMER_INT, RTOS_TIMER_REGS_ADDR are only used in
arch/hexagon/kernel/time.c.

SLEEP_CLK_RATE and TIMER_CLR_ON_MATCH have both been unused since the
file's introduction in commit 71e4a47f32f4 ("Hexagon: Add time and timer
functions").

TIMER_ENABLE is redefined as BIT(0) so the shift is moved into the
definition, rather than its use.

Cc: stable@vger.kernel.org
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Brian Cain <bcain@codeaurora.org>
---
 arch/hexagon/include/asm/timer-regs.h | 26 --------------------------
 arch/hexagon/include/asm/timex.h      |  3 +--
 arch/hexagon/kernel/time.c            | 12 ++++++++++--
 3 files changed, 11 insertions(+), 30 deletions(-)
 delete mode 100644 arch/hexagon/include/asm/timer-regs.h

diff --git a/arch/hexagon/include/asm/timer-regs.h b/arch/hexagon/include/asm/timer-regs.h
deleted file mode 100644
index ee6c61423a05..000000000000
--- a/arch/hexagon/include/asm/timer-regs.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Timer support for Hexagon
- *
- * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
- */
-
-#ifndef _ASM_TIMER_REGS_H
-#define _ASM_TIMER_REGS_H
-
-/*  This stuff should go into a platform specific file  */
-#define TCX0_CLK_RATE		19200
-#define TIMER_ENABLE		0
-#define TIMER_CLR_ON_MATCH	1
-
-/*
- * 8x50 HDD Specs 5-8.  Simulator co-sim not fixed until
- * release 1.1, and then it's "adjustable" and probably not defaulted.
- */
-#define RTOS_TIMER_INT		3
-#ifdef CONFIG_HEXAGON_COMET
-#define RTOS_TIMER_REGS_ADDR	0xAB000000UL
-#endif
-#define SLEEP_CLK_RATE		32000
-
-#endif
diff --git a/arch/hexagon/include/asm/timex.h b/arch/hexagon/include/asm/timex.h
index 8d4ec76fceb4..dfe69e118b2b 100644
--- a/arch/hexagon/include/asm/timex.h
+++ b/arch/hexagon/include/asm/timex.h
@@ -7,11 +7,10 @@
 #define _ASM_TIMEX_H
 
 #include <asm-generic/timex.h>
-#include <asm/timer-regs.h>
 #include <asm/hexagon_vm.h>
 
 /* Using TCX0 as our clock.  CLOCK_TICK_RATE scheduled to be removed. */
-#define CLOCK_TICK_RATE              TCX0_CLK_RATE
+#define CLOCK_TICK_RATE              19200
 
 #define ARCH_HAS_READ_CURRENT_TIMER
 
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index feffe527ac92..febc95714d75 100644
--- a/arch/hexagon/kernel/time.c
+++ b/arch/hexagon/kernel/time.c
@@ -17,9 +17,10 @@
 #include <linux/of_irq.h>
 #include <linux/module.h>
 
-#include <asm/timer-regs.h>
 #include <asm/hexagon_vm.h>
 
+#define TIMER_ENABLE		BIT(0)
+
 /*
  * For the clocksource we need:
  *	pcycle frequency (600MHz)
@@ -33,6 +34,13 @@ cycles_t	pcycle_freq_mhz;
 cycles_t	thread_freq_mhz;
 cycles_t	sleep_clk_freq;
 
+/*
+ * 8x50 HDD Specs 5-8.  Simulator co-sim not fixed until
+ * release 1.1, and then it's "adjustable" and probably not defaulted.
+ */
+#define RTOS_TIMER_INT		3
+#define RTOS_TIMER_REGS_ADDR	0xAB000000UL
+
 static struct resource rtos_timer_resources[] = {
 	{
 		.start	= RTOS_TIMER_REGS_ADDR,
@@ -80,7 +88,7 @@ static int set_next_event(unsigned long delta, struct clock_event_device *evt)
 	iowrite32(0, &rtos_timer->clear);
 
 	iowrite32(delta, &rtos_timer->match);
-	iowrite32(1 << TIMER_ENABLE, &rtos_timer->enable);
+	iowrite32(TIMER_ENABLE, &rtos_timer->enable);
 	return 0;
 }
 
-- 
2.34.0.rc0


^ permalink raw reply related	[relevance 86%]

* [PATCH v2 1/3] hexagon: Export raw I/O routines for modules
       [not found]     <20211115174250.1994179-1-nathan@kernel.org>
@ 2021-11-15 17:42 96% ` Nathan Chancellor
  2021-11-15 17:42 86% ` [PATCH v2 2/3] hexagon: Clean up timer-regs.h Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-11-15 17:42 UTC (permalink / raw)
  To: Andrew Morton, Brian Cain
  Cc: linux-hexagon, Nick Desaulniers, linux-kernel, llvm,
	Nathan Chancellor, stable

When building ARCH=hexagon allmodconfig, the following errors occur:

ERROR: modpost: "__raw_readsl" [drivers/i3c/master/svc-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!

Export these symbols so that modules can use them without any errors.

Cc: stable@vger.kernel.org
Fixes: 013bf24c3829 ("Hexagon: Provide basic implementation and/or stubs for I/O routines.")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Brian Cain <bcain@codeaurora.org>
---
 arch/hexagon/lib/io.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/hexagon/lib/io.c b/arch/hexagon/lib/io.c
index d35d69d6588c..55f75392857b 100644
--- a/arch/hexagon/lib/io.c
+++ b/arch/hexagon/lib/io.c
@@ -27,6 +27,7 @@ void __raw_readsw(const void __iomem *addr, void *data, int len)
 		*dst++ = *src;
 
 }
+EXPORT_SYMBOL(__raw_readsw);
 
 /*
  * __raw_writesw - read words a short at a time
@@ -47,6 +48,7 @@ void __raw_writesw(void __iomem *addr, const void *data, int len)
 
 
 }
+EXPORT_SYMBOL(__raw_writesw);
 
 /*  Pretty sure len is pre-adjusted for the length of the access already */
 void __raw_readsl(const void __iomem *addr, void *data, int len)
@@ -62,6 +64,7 @@ void __raw_readsl(const void __iomem *addr, void *data, int len)
 
 
 }
+EXPORT_SYMBOL(__raw_readsl);
 
 void __raw_writesl(void __iomem *addr, const void *data, int len)
 {
@@ -76,3 +79,4 @@ void __raw_writesl(void __iomem *addr, const void *data, int len)
 
 
 }
+EXPORT_SYMBOL(__raw_writesl);
-- 
2.34.0.rc0


^ permalink raw reply related	[relevance 96%]

* [PATCH 5.10] scripts/lld-version.sh: Rewrite based on upstream ld-version.sh
@ 2021-11-15 16:43 86% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-11-15 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Nick Desaulniers, stable, llvm, Nathan Chancellor

This patch is for linux-5.10.y only.

When scripts/lld-version.sh was initially written, it did not account
for the LLD_VENDOR cmake flag, which changes the output of ld.lld's
--version flag slightly.

Without LLD_VENDOR:

$ ld.lld --version
LLD 14.0.0 (compatible with GNU linkers)

With LLD_VENDOR:

$ ld.lld --version
Debian LLD 14.0.0 (compatible with GNU linkers)

As a result, CONFIG_LLD_VERSION is messed up and configuration values
that are dependent on it cannot be selected:

scripts/lld-version.sh: 20: printf: LLD: expected numeric value
scripts/lld-version.sh: 20: printf: LLD: expected numeric value
scripts/lld-version.sh: 20: printf: LLD: expected numeric value
init/Kconfig:52:warning: 'LLD_VERSION': number is invalid
.config:11:warning: symbol value '00000' invalid for LLD_VERSION
.config:8800:warning: override: CPU_BIG_ENDIAN changes choice state

This was fixed upstream by commit 1f09af062556 ("kbuild: Fix
ld-version.sh script if LLD was built with LLD_VENDOR") in 5.12 but that
was done to ld-version.sh after it was massively rewritten in
commit 02aff8592204 ("kbuild: check the minimum linker version in
Kconfig").

To avoid bringing in that change plus its prerequisites and fixes, just
modify lld-version.sh to make it similar to the upstream ld-version.sh,
which handles ld.lld with or without LLD_VENDOR and ld.bfd without any
errors.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

Our CI caught this error with newer versions of Debian's ld.lld, which
added LLD_VENDOR it seems:

https://github.com/ClangBuiltLinux/continuous-integration2/runs/4206343929?check_suite_focus=true

A similar change was done by me for Android, where it has seen no
issues:

https://android-review.googlesource.com/c/kernel/common/+/1744324

I believe this is a safer change than backporting the fixes from
upstream but if you guys feel otherwise, I can do so. This is only
needed in 5.10 as CONFIG_LLD_VERSION does not exist in 5.4 and it was
fixed in 5.12 upstream.

 scripts/lld-version.sh | 35 ++++++++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
index d70edb4d8a4f..f1eeee450a23 100755
--- a/scripts/lld-version.sh
+++ b/scripts/lld-version.sh
@@ -6,15 +6,32 @@
 # Print the linker version of `ld.lld' in a 5 or 6-digit form
 # such as `100001' for ld.lld 10.0.1 etc.
 
-linker_string="$($* --version)"
+set -e
 
-if ! ( echo $linker_string | grep -q LLD ); then
+# Convert the version string x.y.z to a canonical 5 or 6-digit form.
+get_canonical_version()
+{
+	IFS=.
+	set -- $1
+
+	# If the 2nd or 3rd field is missing, fill it with a zero.
+	echo $((10000 * $1 + 100 * ${2:-0} + ${3:-0}))
+}
+
+# Get the first line of the --version output.
+IFS='
+'
+set -- $(LC_ALL=C "$@" --version)
+
+# Split the line on spaces.
+IFS=' '
+set -- $1
+
+while [ $# -gt 1 -a "$1" != "LLD" ]; do
+	shift
+done
+if [ "$1" = LLD ]; then
+	echo $(get_canonical_version ${2%-*})
+else
 	echo 0
-	exit 1
 fi
-
-VERSION=$(echo $linker_string | cut -d ' ' -f 2)
-MAJOR=$(echo $VERSION | cut -d . -f 1)
-MINOR=$(echo $VERSION | cut -d . -f 2)
-PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
-printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL

base-commit: bd816c278316f20a5575debc64dde4422229a880
-- 
2.34.0.rc0


^ permalink raw reply related	[relevance 86%]

* Please apply 3d5e7a28b1ea2d603dea478e58e37ce75b9597ab to 5.15, 5.14, and 5.10
@ 2021-11-04 18:17 92% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-11-04 18:17 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin, Paolo Bonzini
  Cc: stable, llvm, Nick Desaulniers

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Hi Greg and Sasha,

Please apply commit 3d5e7a28b1ea ("KVM: x86: avoid warning with
-Wbitwise-instead-of-logical") to 5.10, 5.14, and 5.15, where it
resolves a build error with tip of tree clang due to -Werror:

arch/x86/kvm/mmu/mmu.c:3548:15: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
                reserved |= __is_bad_mt_xwr(rsvd_check, sptes[level - 1]) |
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                          ||
arch/x86/kvm/mmu/mmu.c:3548:15: note: cast one or both operands to int to silence this warning
1 error generated.

It applies cleanly to 5.14 and 5.15 and I have attached a backport for
5.10. I have added Paolo in case he has any objections to this.

Cheers,
Nathan

[-- Attachment #2: 0001-KVM-x86-avoid-warning-with-Wbitwise-instead-of-logic.patch --]
[-- Type: text/plain, Size: 1773 bytes --]

From e632639ddfc5e0a6a9f71c38ef840b6a0439b869 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 15 Oct 2021 04:50:01 -0400
Subject: [PATCH 5.10] KVM: x86: avoid warning with
 -Wbitwise-instead-of-logical

commit 3d5e7a28b1ea2d603dea478e58e37ce75b9597ab upstream.

This is a new warning in clang top-of-tree (will be clang 14):

In file included from arch/x86/kvm/mmu/mmu.c:27:
arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
        return __is_bad_mt_xwr(rsvd_check, spte) |
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                 ||
arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning

The code is fine, but change it anyway to shut up this clever clogs
of a compiler.

Reported-by: torvic9@mailbox.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[nathan: Backport to 5.10, which does not have 961f84457cd4]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/x86/kvm/mmu/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 060d9a906535..770d18dc4650 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3545,7 +3545,7 @@ static bool get_mmio_spte(struct kvm_vcpu *vcpu, u64 addr, u64 *sptep)
 		 * reserved bit and EPT's invalid memtype/XWR checks to avoid
 		 * adding a Jcc in the loop.
 		 */
-		reserved |= __is_bad_mt_xwr(rsvd_check, sptes[level - 1]) |
+		reserved |= __is_bad_mt_xwr(rsvd_check, sptes[level - 1]) ||
 			    __is_rsvd_bits_set(rsvd_check, sptes[level - 1],
 					       level);
 	}

base-commit: 09df347cfd189774130f8ae8267324b97aaf868e
-- 
2.34.0.rc0


^ permalink raw reply related	[relevance 92%]

* Apply 091bb549f7722723b284f63ac665e2aedcf9dec9 to 4.19
@ 2021-10-27 16:27 99% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-10-27 16:27 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: Nick Desaulniers, Fangrui Song, stable, llvm

Hi Greg and Sasha,

Please apply commit 091bb549f772 ("ARM: 8819/1: Remove '-p' from
LDFLAGS") to 4.19 (and earlier if so desired). LLD 14 will remove the
'-p' flag [1] for reasons outlined in both the Linux and LLD commit,
which will cause our builds to break [2]. I have verified that it
applies cleanly back to 4.4, although we only build ARM kernels with LLD
on 4.19 and newer, so it is not strictly necessary there.

[1]: https://github.com/llvm/llvm-project/commit/815a1207bfe121c8dcf3804a4f4638e580f63519
[2]: https://github.com/ClangBuiltLinux/continuous-integration2/runs/4016787082?check_suite_focus=true

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: i386: tinyconfig: perf_event.h:838:21: error: invalid output size for constraint '=q'
  @ 2021-10-25 14:41 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-10-25 14:41 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: clang-built-linux, linux-stable, llvm, Greg Kroah-Hartman,
	Sasha Levin, Nick Desaulniers, Arnaldo Carvalho de Melo,
	Arnaldo Carvalho de Melo

Hi Naresh,

On Sun, Oct 24, 2021 at 08:05:01AM +0530, Naresh Kamboju wrote:
> Following i386 tinyconfig  clang-13 and clang-nightly failed on
> stable-rc queue/5.4.
> 
> Fail (119 errors) with status message
> 'failure while building tuxmake target(s): default': ea3681525113
>  ("net: enetc: fix ethtool counter name for PM0_TERR")
>  i386 (tinyconfig) with clang-nightly
> @ https://builds.tuxbuild.com/1zvtvNS4eyYkOMiXtFgR7n1k0Yc/
> 
> 
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/current ARCH=i386
> CROSS_COMPILE=i686-linux-gnu- HOSTCC=clang CC=clang
> In file included from /builds/linux/arch/x86/events/amd/core.c:12:
> /builds/linux/arch/x86/events/amd/../perf_event.h:838:21: error:
> invalid output size for constraint '=q'
>         u64 disable_mask = __this_cpu_read(cpu_hw_events.perf_ctr_virt_mask);
> 
> build link,
> https://builds.tuxbuild.com/1zvtvNS4eyYkOMiXtFgR7n1k0Yc/
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

I am surprised this is being reported as a new issue for 5.4, as it
should have always had this error [1]. We did not fix this until 5.9
[2], meaning that 5.10 and beyond is fine. The series that did fix it
was rather long so I am not sure it is suitable for stable. My
recommendation is to disable i386 testing for 5.4 and earlier with
clang.

[1]: https://github.com/ClangBuiltLinux/linux/issues/194
[2]: https://git.kernel.org/linus/ba77c568f3160657a5f7905289c07d18c2dfde78

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: [PATCH v2] x86/setup: call early_reserve_memory() earlier
  @ 2021-09-21  3:59 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-09-21  3:59 UTC (permalink / raw)
  To: Juergen Gross
  Cc: xen-devel, x86, linux-kernel, efault, Thomas Gleixner,
	Ingo Molnar, Borislav Petkov, H. Peter Anvin, stable,
	Marek Marczykowski-Górecki

On Mon, Sep 20, 2021 at 02:04:21PM +0200, Juergen Gross wrote:
> Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
> reservations") introduced early_reserve_memory() to do all needed
> initial memblock_reserve() calls in one function. Unfortunately the
> call of early_reserve_memory() is done too late for Xen dom0, as in
> some cases a Xen hook called by e820__memory_setup() will need those
> memory reservations to have happened already.
> 
> Move the call of early_reserve_memory() before the call of
> e820__memory_setup() in order to avoid such problems.
> 
> Cc: stable@vger.kernel.org
> Fixes: a799c2bd29d19c565 ("x86/setup: Consolidate early memory reservations")
> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

I had issues on an AMD Ryzen 3 4300G based system with v1. v2 does not
trigger any boot issues on that same machine or an Intel i5-4210U based
system that I also test with.

Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
> V2:
> - update comment (Jan Beulich, Boris Petkov)
> - move call down in setup_arch() (Mike Galbraith)
> ---
>  arch/x86/kernel/setup.c | 26 ++++++++++++++------------
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 79f164141116..40ed44ead063 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -830,6 +830,20 @@ void __init setup_arch(char **cmdline_p)
>  
>  	x86_init.oem.arch_setup();
>  
> +	/*
> +	 * Do some memory reservations *before* memory is added to memblock, so
> +	 * memblock allocations won't overwrite it.
> +	 *
> +	 * After this point, everything still needed from the boot loader or
> +	 * firmware or kernel text should be early reserved or marked not RAM in
> +	 * e820. All other memory is free game.
> +	 *
> +	 * This call needs to happen before e820__memory_setup() which calls the
> +	 * xen_memory_setup() on Xen dom0 which relies on the fact that those
> +	 * early reservations have happened already.
> +	 */
> +	early_reserve_memory();
> +
>  	iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
>  	e820__memory_setup();
>  	parse_setup_data();
> @@ -876,18 +890,6 @@ void __init setup_arch(char **cmdline_p)
>  
>  	parse_early_param();
>  
> -	/*
> -	 * Do some memory reservations *before* memory is added to
> -	 * memblock, so memblock allocations won't overwrite it.
> -	 * Do it after early param, so we could get (unlikely) panic from
> -	 * serial.
> -	 *
> -	 * After this point everything still needed from the boot loader or
> -	 * firmware or kernel text should be early reserved or marked not
> -	 * RAM in e820. All other memory is free game.
> -	 */
> -	early_reserve_memory();
> -
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  	/*
>  	 * Memory used by the kernel cannot be hot-removed because Linux
> -- 
> 2.26.2
> 
> 

^ permalink raw reply	[relevance 99%]

* Re: [tip: x86/urgent] x86/setup: Call early_reserve_memory() earlier
  @ 2021-09-20 22:48 99%       ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-09-20 22:48 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Mike Galbraith, Thomas Gleixner, linux-kernel, linux-tip-commits,
	marmarek, Juergen Gross, Borislav Petkov, Mike Rapoport, stable,
	x86

On Sun, Sep 19, 2021 at 07:15:30PM +0200, Borislav Petkov wrote:
> On Sun, Sep 19, 2021 at 06:55:16PM +0200, Mike Galbraith wrote:
> > On Thu, 2021-09-16 at 10:50 +0000, tip-bot2 for Juergen Gross wrote:
> > > The following commit has been merged into the x86/urgent branch of
> > > tip:
> > >
> > > Commit-ID:     1c1046581f1a3809e075669a3df0191869d96dd1
> > > Gitweb:       
> > > https://git.kernel.org/tip/1c1046581f1a3809e075669a3df0191869d96dd1
> > > Author:        Juergen Gross <jgross@suse.com>
> > > AuthorDate:    Tue, 14 Sep 2021 11:41:08 +02:00
> > > Committer:     Borislav Petkov <bp@suse.de>
> > > CommitterDate: Thu, 16 Sep 2021 12:38:05 +02:00
> > >
> > > x86/setup: Call early_reserve_memory() earlier
> > 
> > This commit rendered tip toxic to my i4790 desktop box and i5-6200U
> > lappy.  Boot for both is instantly over without so much as a twitch.
> > 
> > Post bisect revert made both all better.
> 
> I had a suspicion that moving stuff around like that would not just
> simply work in all cases, as our boot order is very lovely and fragile.
> 
> And it booted just fine on my machines here.
> 
> ;-\
> 
> Anyway, commit zapped from the x86/urgent lineup. We'll have to have a
> third try later.

Could auto-latest get updated too so that it does not show up in -next?
I just spent a solid chunk of my day bisecting a boot failure on one of
my test boxes on -next down to this change, only to find out it was
already reported :/

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Re: Patch "vmlinux.lds.h: Handle clang's module.{c,d}tor sections" has been added to the 5.13-stable tree
       [not found]     <16290320662366@kroah.com>
@ 2021-08-15 22:54 77% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-15 22:54 UTC (permalink / raw)
  To: gregkh
  Cc: elver, keescook, maskray, ndesaulniers, stable-commits, stable, sashal

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Hi Greg,

On Sun, Aug 15, 2021 at 02:54:26PM +0200, gregkh@linuxfoundation.org wrote:
> 
> This is a note to let you know that I've just added the patch titled
> 
>     vmlinux.lds.h: Handle clang's module.{c,d}tor sections
> 
> to the 5.13-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      vmlinux.lds.h-handle-clang-s-module.-c-d-tor-sections.patch
> and it can be found in the queue-5.13 subdirectory.

Attached are backports for 4.4 to 5.10. I am not sure if anyone is
actually using KASAN with clang on 4.4 (ChromeOS maybe?) but it does not
hurt to have it just in case.

I did not get any emails that the patch failed to apply on the older
versions, I assume this is because I did just a "Cc: stable@vger.kernel.org"
without any version or fixes tag. Is there any "official" way to notate
that I want a particular patch applied to all supported kernel versions
aside from adding "# v4.4+" to the Cc tag so that I can provide manual
backports for those versions?

Cheers,
Nathan

[-- Attachment #2: 4.4-4.14-848378812e401.patch --]
[-- Type: text/plain, Size: 2365 bytes --]

From fd073a15e9941b70d0db84d28d539cf3535e1b59 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 30 Jul 2021 19:31:08 -0700
Subject: [PATCH 4.4 to 4.14] vmlinux.lds.h: Handle clang's module.{c,d}tor
 sections

commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.

A recent change in LLVM causes module_{c,d}tor sections to appear when
CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN
flag, so it is in a separate section even with -fno-function-sections
(default)".

Place them in the TEXT_TEXT section so that these technologies continue
to work with the newer compiler versions. All of the KASAN and KCSAN
KUnit tests continue to pass after this change.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1432
Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210731023107.1932981-1-nathan@kernel.org
[nc: Fix conflicts due to lack of cf68fffb66d60 and 266ff2a8f51f0]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c9790b2cdf34..45fe7295051f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -465,6 +465,7 @@
 		*(.text.unknown .text.unknown.*)			\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 	MEM_KEEP(init.text)						\
 	MEM_KEEP(exit.text)						\
 

base-commit: 162b95d01320370b80cb2d5724cea4ae538ac740
-- 
2.33.0.rc2


[-- Attachment #3: 4.19-5.10-848378812e401.patch --]
[-- Type: text/plain, Size: 2336 bytes --]

From 07154ab1ed7ce98f9418421152753e1bc8029829 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 30 Jul 2021 19:31:08 -0700
Subject: [PATCH 4.19 to 5.10] vmlinux.lds.h: Handle clang's module.{c,d}tor
 sections

commit 848378812e40152abe9b9baf58ce2004f76fb988 upstream.

A recent change in LLVM causes module_{c,d}tor sections to appear when
CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN
flag, so it is in a separate section even with -fno-function-sections
(default)".

Place them in the TEXT_TEXT section so that these technologies continue
to work with the newer compiler versions. All of the KASAN and KCSAN
KUnit tests continue to pass after this change.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1432
Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Acked-by: Marco Elver <elver@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210731023107.1932981-1-nathan@kernel.org
[nc: Resolve conflict due to lack of cf68fffb66d60]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 18468b46c450..a774361f28d4 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -599,6 +599,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 

base-commit: 5805e5eec901e830c7741d4916270d0b9cfd6743
-- 
2.33.0.rc2


^ permalink raw reply related	[relevance 77%]

* Re: [linux-stable-rc:linux-4.19.y 1181/1498] ERROR: "__compiletime_assert_491" [drivers/gpu/drm/i915/i915.ko] undefined!
       [not found]     ` <CAKwvOdk6PNK1unJ2Yym4WHV=AXjdYwEyfWf_fPxO013ZtJa6Yw@mail.gmail.com>
@ 2021-08-06  0:11 97%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-06  0:11 UTC (permalink / raw)
  To: Nick Desaulniers, Greg Kroah-Hartman, Sasha Levin
  Cc: kernel test robot, clang-built-linux, kbuild-all, linux-kernel,
	Andrew Morton, Linux Memory Management List, stable

On Thu, Aug 05, 2021 at 04:23:40PM -0700, Nick Desaulniers wrote:
> On Thu, Aug 5, 2021 at 1:24 PM kernel test robot <lkp@intel.com> wrote:
> >
> > Hi Nick,
> >
> > First bad commit (maybe != root cause):
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
> > head:   7457eed4b647560ae1b1800c295efc5f1db22e4b
> > commit: 7c29fd831799d09474dfdae556207b7102647a45 [1181/1498] lib/string.c: implement stpcpy
> > config: x86_64-randconfig-r024-20210805 (attached as .config)
> > compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 31a71a393f65d9e07b5b0756fef9dd16690950ee)
> > reproduce (this is a W=1 build):
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=7c29fd831799d09474dfdae556207b7102647a45
> >         git remote add linux-stable-rc https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >         git fetch --no-tags linux-stable-rc linux-4.19.y
> >         git checkout 7c29fd831799d09474dfdae556207b7102647a45
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > >> ERROR: "__compiletime_assert_491" [drivers/gpu/drm/i915/i915.ko] undefined!
> 
> ^ I'm actively trying to improve these diagnostics in LLVM at the
> moment. Hopefully that will make this report clearer!
> https://reviews.llvm.org/D106030

It does help :)

drivers/gpu/drm/i915/intel_engine_cs.c:466:2: error: call to '__compiletime_assert_491' declared with attribute error: BUILD_BUG_ON failed: (execlists_num_ports(execlists)) == 0 || (((execlists_num_ports(execlists)) & ((execlists_num_ports(execlists)) - 1)) != 0)
        BUILD_BUG_ON_NOT_POWER_OF_2(execlists_num_ports(execlists));
        ^
include/linux/build_bug.h:21:2: note: expanded from macro 'BUILD_BUG_ON_NOT_POWER_OF_2'
        BUILD_BUG_ON((n) == 0 || (((n) & ((n) - 1)) != 0))
        ^
include/linux/build_bug.h:69:2: note: expanded from macro 'BUILD_BUG_ON'
        BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
        ^
include/linux/build_bug.h:45:37: note: expanded from macro 'BUILD_BUG_ON_MSG'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                    ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
include/linux/compiler.h:336:2: note: expanded from macro '_compiletime_assert'
        __compiletime_assert(condition, msg, prefix, suffix)
        ^
include/linux/compiler.h:329:4: note: expanded from macro '__compiletime_assert'
                        prefix ## suffix();                             \
                        ^
<scratch space>:83:1: note: expanded from here
__compiletime_assert_491
^
4 warnings and 1 error generated.

As it turns out, this has come up before and it was fixed by commit
410ed5731a65 ("drm/i915: Ensure intel_engine_init_execlist() builds with
Clang").

Greg and Sasha, could this be picked up for 4.19?

Cheers,
Nathan

^ permalink raw reply	[relevance 97%]

* Re: [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-release-arm-stable-allyesconfig - Build # 4 - Successful!
       [not found]     <1406720038.945.1627915387982@localhost>
@ 2021-08-02 17:28 99% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-08-02 17:28 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: linaro-toolchain, clang-built-linux, arnd, Linus Walleij,
	ci_notify, stable

On 8/2/2021 7:43 AM, ci_notify@linaro.org wrote:
> Successfully identified regression in *linux* in CI configuration tcwg_kernel/llvm-release-arm-stable-allyesconfig.  So far, this commit has regressed CI configurations:
>   - tcwg_kernel/llvm-release-arm-stable-allyesconfig
> 
> Culprit:
> <cut>
> commit 341db343768bc44f3512facc464021730d64071c
> Author: Linus Walleij <linus.walleij@linaro.org>
> Date:   Sun May 23 00:50:39 2021 +0200
> 
>      power: supply: ab8500: Move to componentized binding
>      
>      [ Upstream commit 1c1f13a006ed0d71bb5664c8b7e3e77a28da3beb ]
>      
>      The driver has problems with the different components of
>      the charging code racing with each other to probe().
>      
>      This results in all four subdrivers populating battery
>      information to ascertain that it is populated for their
>      own needs for example.
>      
>      Fix this by using component probing and thus expressing
>      to the kernel that these are dependent components.
>      The probes can happen in any order and will only acquire
>      resources such as state container, regulators and
>      interrupts and initialize the data structures, but no
>      execution happens until the .bind() callback is called.
>      
>      The charging driver is the main component and binds
>      first, then bind in order the three subcomponents:
>      ab8500-fg, ab8500-btemp and ab8500-chargalg.
>      
>      Do some housekeeping while we are moving the code around.
>      Like use devm_* for IRQs so as to cut down on some
>      boilerplate.
>      
>      Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>      Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>      Signed-off-by: Sasha Levin <sashal@kernel.org>
> </cut>
> 
> Results regressed to (for first_bad == 341db343768bc44f3512facc464021730d64071c)
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_llvm:
> -5
> # build_abe qemu:
> -2
> # linux_n_obj:
> 19634
> # First few build errors in logs:
> # 00:03:07 drivers/power/supply/ab8500_fg.c:3061:32: error: use of undeclared identifier 'np'
> # 00:03:08 make[3]: *** [drivers/power/supply/ab8500_fg.o] Error 1
> # 00:03:10 make[2]: *** [drivers/power/supply] Error 2
> # 00:03:10 make[1]: *** [drivers/power] Error 2
> # 00:04:05 make: *** [drivers] Error 2

Greg and Sasha,

Please cherry pick upstream commit 7e2bb83c617f ("power: supply: ab8500: 
Call battery population once") to resolve this build error on 5.13.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH v2] vmlinux.lds.h: Handle clang's module.{c,d}tor sections
  2021-07-30 22:38 96% [PATCH] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Nathan Chancellor
  @ 2021-07-31  2:31 93% ` Nathan Chancellor
  1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-07-31  2:31 UTC (permalink / raw)
  To: Kees Cook, Arnd Bergmann, Nick Desaulniers
  Cc: Fangrui Song, Marco Elver, linux-arch, linux-kernel, kasan-dev,
	clang-built-linux, Nathan Chancellor, stable

A recent change in LLVM causes module_{c,d}tor sections to appear when
CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Fangrui explains: "the function asan.module_ctor has the SHF_GNU_RETAIN
flag, so it is in a separate section even with -fno-function-sections
(default)".

Place them in the TEXT_TEXT section so that these technologies continue
to work with the newer compiler versions. All of the KASAN and KCSAN
KUnit tests continue to pass after this change.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1432
Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---

v1 -> v2:

* Fix inclusion of .text.tsan.* (Nick)

* Drop .text.asan as it does not exist plus it would be handled by a
  different line (Fangrui)

* Add Fangrui's explanation about why the LLVM commit caused these
  sections to appear.

 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 17325416e2de..62669b36a772 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -586,6 +586,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan.* .text.tsan.*)				\
 		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\

base-commit: 4669e13cd67f8532be12815ed3d37e775a9bdc16
-- 
2.32.0.264.g75ae10bc75


^ permalink raw reply related	[relevance 93%]

* Re: [PATCH] vmlinux.lds.h: Handle clang's module.{c,d}tor sections
  @ 2021-07-31  0:32 99%     ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-07-31  0:32 UTC (permalink / raw)
  To: Fangrui Song
  Cc: Nick Desaulniers, Kees Cook, Arnd Bergmann, Marco Elver,
	linux-arch, linux-kernel, kasan-dev, clang-built-linux, stable

On 7/30/2021 3:59 PM, Fangrui Song wrote:
> On 2021-07-30, Nick Desaulniers wrote:
>> On Fri, Jul 30, 2021 at 3:38 PM Nathan Chancellor <nathan@kernel.org> 
>> wrote:
>>>
>>> A recent change in LLVM causes module_{c,d}tor sections to appear when
>>> CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
>>> because these are not handled anywhere:
>>>
>>> ld.lld: warning: 
>>> arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being 
>>> placed in '.text.asan.module_ctor'
>>> ld.lld: warning: 
>>> arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being 
>>> placed in '.text.asan.module_dtor'
>>> ld.lld: warning: 
>>> arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being 
>>> placed in '.text.tsan.module_ctor'
>>
>> ^ .text.tsan.*
> 
> I was wondering why the orphan section warning only arose recently.
> Now I see: the function asan.module_ctor has the SHF_GNU_RETAIN flag, so
> it is in a separate section even with -fno-function-sections (default).

Thanks for the explanation, I will add this to the commit message.

> It seems that with -ffunction-sections the issue should have been caught
> much earlier.
> 
>>>
>>> Place them in the TEXT_TEXT section so that these technologies continue
>>> to work with the newer compiler versions. All of the KASAN and KCSAN
>>> KUnit tests continue to pass after this change.
>>>
>>> Cc: stable@vger.kernel.org
>>> Link: https://github.com/ClangBuiltLinux/linux/issues/1432
>>> Link: 
>>> https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865 
>>>
>>> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>>> ---
>>>  include/asm-generic/vmlinux.lds.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/asm-generic/vmlinux.lds.h 
>>> b/include/asm-generic/vmlinux.lds.h
>>> index 17325416e2de..3b79b1e76556 100644
>>> --- a/include/asm-generic/vmlinux.lds.h
>>> +++ b/include/asm-generic/vmlinux.lds.h
>>> @@ -586,6 +586,7 @@
>>>                 
>>> NOINSTR_TEXT                                            \
>>>                 
>>> *(.text..refcount)                                      \
>>>                 
>>> *(.ref.text)                                            \
>>> +               *(.text.asan 
>>> .text.asan.*)                              \
>>
>> Will this match .text.tsan.module_ctor?

No, I forgot to test CONFIG_KCSAN with this version, rather than the 
prior one I had on GitHub so I will send v2 shortly.

> asan.module_ctor is the only function AddressSanitizer synthesizes in 
> the instrumented translation unit.
> There is no function called "asan".
> 
> (Even if a function "asan" exists due to -ffunction-sections
> -funique-section-names, TEXT_MAIN will match .text.asan, so the
> .text.asan pattern will match nothing.)

Sounds good, I will update it to remove the .text.asan and replace it 
with .text.tsan.*

>> Do we want to add these conditionally on
>> CONFIG_KASAN_GENERIC/CONFIG_KCSAN like we do for SANITIZER_DISCARDS?

I do not think there is a point in doing so but I can if others feel 
strongly.

Thank you both for the comments for the comments!

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* [PATCH] vmlinux.lds.h: Handle clang's module.{c,d}tor sections
@ 2021-07-30 22:38 96% Nathan Chancellor
    2021-07-31  2:31 93% ` [PATCH v2] " Nathan Chancellor
  0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2021-07-30 22:38 UTC (permalink / raw)
  To: Kees Cook, Arnd Bergmann, Nick Desaulniers
  Cc: Fangrui Song, Marco Elver, linux-arch, linux-kernel, kasan-dev,
	clang-built-linux, Nathan Chancellor, stable

A recent change in LLVM causes module_{c,d}tor sections to appear when
CONFIG_K{A,C}SAN are enabled, which results in orphan section warnings
because these are not handled anywhere:

ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_ctor) is being placed in '.text.asan.module_ctor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.asan.module_dtor) is being placed in '.text.asan.module_dtor'
ld.lld: warning: arch/x86/pci/built-in.a(legacy.o):(.text.tsan.module_ctor) is being placed in '.text.tsan.module_ctor'

Place them in the TEXT_TEXT section so that these technologies continue
to work with the newer compiler versions. All of the KASAN and KCSAN
KUnit tests continue to pass after this change.

Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1432
Link: https://github.com/llvm/llvm-project/commit/7b789562244ee941b7bf2cefeb3fc08a59a01865
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 17325416e2de..3b79b1e76556 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -586,6 +586,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		*(.text.asan .text.asan.*)				\
 		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\

base-commit: 4669e13cd67f8532be12815ed3d37e775a9bdc16
-- 
2.32.0.264.g75ae10bc75


^ permalink raw reply related	[relevance 96%]

* [PATCH 4.9 2/2] tipc: Fix backport of b77413446408fdd256599daf00d5be72b5f3e7c6
  2021-07-27 22:56 96% [PATCH 4.9 1/2] iommu/amd: Fix backport of 140456f994195b568ecd7fc2287a34eadffef3ca Nathan Chancellor
@ 2021-07-27 22:56 94% ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-07-27 22:56 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, clang-built-linux, Nathan Chancellor, Hoang Le,
	Jon Maloy, Ying Xue, kernel test robot

Clang warns:

net/tipc/link.c:896:23: warning: variable 'hdr' is uninitialized when
used here [-Wuninitialized]
        imp = msg_importance(hdr);
                             ^~~
net/tipc/link.c:890:22: note: initialize the variable 'hdr' to silence
this warning
        struct tipc_msg *hdr;
                            ^
                             = NULL
1 warning generated.

The backport of commit b77413446408 ("tipc: fix NULL deref in
tipc_link_xmit()") to 4.9 as commit 310014f572a5 ("tipc: fix NULL deref
in tipc_link_xmit()") added the hdr initialization above the

    if (unlikely(msg_size(hdr) > mtu)) {

like in the upstream commit; however, in 4.9, that check is below imp's
first use because commit 365ad353c256 ("tipc: reduce risk of user
starvation during link congestion") is not present. This results in hdr
being used uninitialized.

Fix this by moving hdr's initialization before imp and after the if
check like the original backport did.

Cc: Hoang Le <hoang.h.le@dektech.com.au>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: Ying Xue <ying.xue@windriver.com>
Fixes: 310014f572a5 ("tipc: fix NULL deref in tipc_link_xmit()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 net/tipc/link.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/tipc/link.c b/net/tipc/link.c
index 06327f78f203..6fc2fa75503d 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -893,6 +893,7 @@ int tipc_link_xmit(struct tipc_link *l, struct sk_buff_head *list,
 	if (pkt_cnt <= 0)
 		return 0;
 
+	hdr = buf_msg(skb_peek(list));
 	imp = msg_importance(hdr);
 	/* Match msg importance against this and all higher backlog limits: */
 	if (!skb_queue_empty(backlogq)) {
@@ -902,7 +903,6 @@ int tipc_link_xmit(struct tipc_link *l, struct sk_buff_head *list,
 		}
 	}
 
-	hdr = buf_msg(skb_peek(list));
 	if (unlikely(msg_size(hdr) > mtu)) {
 		skb_queue_purge(list);
 		return -EMSGSIZE;
-- 
2.32.0.264.g75ae10bc75


^ permalink raw reply related	[relevance 94%]

* [PATCH 4.9 1/2] iommu/amd: Fix backport of 140456f994195b568ecd7fc2287a34eadffef3ca
@ 2021-07-27 22:56 96% Nathan Chancellor
  2021-07-27 22:56 94% ` [PATCH 4.9 2/2] tipc: Fix backport of b77413446408fdd256599daf00d5be72b5f3e7c6 Nathan Chancellor
  0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-07-27 22:56 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin
  Cc: stable, clang-built-linux, Nathan Chancellor, Andrey Ryabinin,
	Joerg Roedel, Will Deacon, kernel test robot

Clang warns:

drivers/iommu/amd_iommu.c:1335:6: warning: variable 'flags' is used
uninitialized whenever 'if' condition is true
[-Wsometimes-uninitialized]
        if (!pte)
            ^~~~
drivers/iommu/amd_iommu.c:1352:40: note: uninitialized use occurs here
        spin_unlock_irqrestore(&domain->lock, flags);
                                              ^~~~~
drivers/iommu/amd_iommu.c:1335:2: note: remove the 'if' if its condition
is always false
        if (!pte)
        ^~~~~~~~~
drivers/iommu/amd_iommu.c:1331:21: note: initialize the variable 'flags'
to silence this warning
        unsigned long flags;
                           ^
                            = 0
1 warning generated.

The backport of commit 140456f99419 ("iommu/amd: Fix sleeping in atomic
in increase_address_space()") to 4.9 as commit 1d648460d7c5 ("iommu/amd:
Fix sleeping in atomic in increase_address_space()") failed to keep the
"return false", which in 4.9 needs to be a regular "return" due to a
lack of commit f15d9a992f90 ("iommu/amd: Remove domain->updated").

This resolves the warning and matches the 4.14-4.19 backport.

Cc: Andrey Ryabinin <arbn@yandex-team.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>
Fixes: 1d648460d7c5 ("iommu/amd: Fix sleeping in atomic in increase_address_space()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/iommu/amd_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8377bd388d67..14e9b06829d5 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -1333,7 +1333,7 @@ static void increase_address_space(struct protection_domain *domain,
 
 	pte = (void *)get_zeroed_page(gfp);
 	if (!pte)
-		goto out;
+		return;
 
 	spin_lock_irqsave(&domain->lock, flags);
 

base-commit: 0db822f6dee813f746ed196fc561945eee4cd4b9
-- 
2.32.0.264.g75ae10bc75


^ permalink raw reply related	[relevance 96%]

* Re: [PATCH 4.4 to 4.19] Makefile: Move -Wno-unused-but-set-variable out of GCC only block
  @ 2021-06-24 16:36 99%   ` Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-06-24 16:36 UTC (permalink / raw)
  To: Sasha Levin
  Cc: Greg Kroah-Hartman, stable, Nick Desaulniers, clang-built-linux



On 6/24/2021 5:04 AM, Sasha Levin wrote:
> On Wed, Jun 23, 2021 at 10:26:12AM -0700, Nathan Chancellor wrote:
>> commit 885480b084696331bea61a4f7eba10652999a9c1 upstream.
>>
>> Currently, -Wunused-but-set-variable is only supported by GCC so it is
>> disabled unconditionally in a GCC only block (it is enabled with W=1).
>> clang currently has its implementation for this warning in review so
>> preemptively move this statement out of the GCC only block and wrap it
>> with cc-disable-warning so that both compilers function the same.
>>
>> Cc: stable@vger.kernel.org
>> Link: https://reviews.llvm.org/D100581
>> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>> [nc: Backport, workaround lack of e2079e93f562 in older branches]
> 
> Can we just take the above patch instead?

No because that patch has a prerequisite of commit a035d552a93b 
("Makefile: Globally enable fall-through warning"), which is not 
suitable for stable because there were hundreds of warnings fixed before 
that was enabled.

Cheers,
Nathan

^ permalink raw reply	[relevance 99%]

* Backport of e607ff630c60 for 4.14 to 5.10
@ 2021-06-23 20:13 48% Nathan Chancellor
  0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-06-23 20:13 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Sasha Levin; +Cc: stable

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

Hi Greg and Sasha,

Please find attached backports for commit e607ff630c60 ("MIPS: generic:
Update node names to avoid unit addresses"). It has already been applied
to 5.12 but it is missing from all other branches that need it. Let me
know if there are any issues with applying it.

Cheers,
Nathan

[-- Attachment #2: e607ff630c60-4.14.patch --]
[-- Type: text/plain, Size: 3950 bytes --]

From 81524b2326bd0dbcfb304ad0cc2cadd2be6b6865 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 9 Apr 2021 12:21:28 -0700
Subject: [PATCH 4.14] MIPS: generic: Update node names to avoid unit addresses

commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream.

With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
longer build, failing with:

/usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1

This is expected after the linked U-Boot commits because '@' is
forbidden in the node names due to the way that libfdt treats nodes with
the same prefix but different unit addresses.

Switch the '@' in the node name to '-'. Drop the unit addresses from the
hash and kernel child nodes because there is only one node so they do
not need to have a number to differentiate them.

Cc: stable@vger.kernel.org
Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
[nathan: Backport to 4.14, only apply to .its.S files that exist]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/generic/board-boston.its.S   | 10 +++++-----
 arch/mips/generic/board-ni169445.its.S | 10 +++++-----
 arch/mips/generic/vmlinux.its.S        | 10 +++++-----
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/mips/generic/board-boston.its.S b/arch/mips/generic/board-boston.its.S
index a7f51f97b910..c45ad2759421 100644
--- a/arch/mips/generic/board-boston.its.S
+++ b/arch/mips/generic/board-boston.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@boston {
+		fdt-boston {
 			description = "img,boston Device Tree";
 			data = /incbin/("boot/dts/img/boston.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@boston {
+		conf-boston {
 			description = "Boston Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@boston";
+			kernel = "kernel";
+			fdt = "fdt-boston";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ni169445.its.S b/arch/mips/generic/board-ni169445.its.S
index e4cb4f95a8cc..0a2e8f7a8526 100644
--- a/arch/mips/generic/board-ni169445.its.S
+++ b/arch/mips/generic/board-ni169445.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@ni169445 {
+		fdt-ni169445 {
 			description = "NI 169445 device tree";
 			data = /incbin/("boot/dts/ni/169445.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ni169445 {
+		conf-ni169445 {
 			description = "NI 169445 Linux Kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ni169445";
+			kernel = "kernel";
+			fdt = "fdt-ni169445";
 		};
 	};
 };
diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
index 1a08438fd893..3e254676540f 100644
--- a/arch/mips/generic/vmlinux.its.S
+++ b/arch/mips/generic/vmlinux.its.S
@@ -6,7 +6,7 @@
 	#address-cells = <ADDR_CELLS>;
 
 	images {
-		kernel@0 {
+		kernel {
 			description = KERNEL_NAME;
 			data = /incbin/(VMLINUX_BINARY);
 			type = "kernel";
@@ -15,18 +15,18 @@
 			compression = VMLINUX_COMPRESSION;
 			load = /bits/ ADDR_BITS <VMLINUX_LOAD_ADDRESS>;
 			entry = /bits/ ADDR_BITS <VMLINUX_ENTRY_ADDRESS>;
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		default = "conf@default";
+		default = "conf-default";
 
-		conf@default {
+		conf-default {
 			description = "Generic Linux kernel";
-			kernel = "kernel@0";
+			kernel = "kernel";
 		};
 	};
 };

base-commit: cfb41ef9deb1e6572ac218ddfcec9567e5d1c101
-- 
2.32.0.93.g670b81a890


[-- Attachment #3: e607ff630c60-4.19.patch --]
[-- Type: text/plain, Size: 4742 bytes --]

From 4c2081d41fa678c14927fa32379661b544712ff2 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 9 Apr 2021 12:21:28 -0700
Subject: [PATCH 4.19] MIPS: generic: Update node names to avoid unit addresses

commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream.

With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
longer build, failing with:

/usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1

This is expected after the linked U-Boot commits because '@' is
forbidden in the node names due to the way that libfdt treats nodes with
the same prefix but different unit addresses.

Switch the '@' in the node name to '-'. Drop the unit addresses from the
hash and kernel child nodes because there is only one node so they do
not need to have a number to differentiate them.

Cc: stable@vger.kernel.org
Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
[nathan: Backport to 4.19, only apply to .its.S files that exist]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/generic/board-boston.its.S   | 10 +++++-----
 arch/mips/generic/board-ni169445.its.S | 10 +++++-----
 arch/mips/generic/board-xilfpga.its.S  | 10 +++++-----
 arch/mips/generic/vmlinux.its.S        | 10 +++++-----
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/mips/generic/board-boston.its.S b/arch/mips/generic/board-boston.its.S
index a7f51f97b910..c45ad2759421 100644
--- a/arch/mips/generic/board-boston.its.S
+++ b/arch/mips/generic/board-boston.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@boston {
+		fdt-boston {
 			description = "img,boston Device Tree";
 			data = /incbin/("boot/dts/img/boston.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@boston {
+		conf-boston {
 			description = "Boston Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@boston";
+			kernel = "kernel";
+			fdt = "fdt-boston";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ni169445.its.S b/arch/mips/generic/board-ni169445.its.S
index e4cb4f95a8cc..0a2e8f7a8526 100644
--- a/arch/mips/generic/board-ni169445.its.S
+++ b/arch/mips/generic/board-ni169445.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@ni169445 {
+		fdt-ni169445 {
 			description = "NI 169445 device tree";
 			data = /incbin/("boot/dts/ni/169445.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ni169445 {
+		conf-ni169445 {
 			description = "NI 169445 Linux Kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ni169445";
+			kernel = "kernel";
+			fdt = "fdt-ni169445";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-xilfpga.its.S b/arch/mips/generic/board-xilfpga.its.S
index a2e773d3f14f..08c1e900eb4e 100644
--- a/arch/mips/generic/board-xilfpga.its.S
+++ b/arch/mips/generic/board-xilfpga.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@xilfpga {
+		fdt-xilfpga {
 			description = "MIPSfpga (xilfpga) Device Tree";
 			data = /incbin/("boot/dts/xilfpga/nexys4ddr.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@xilfpga {
+		conf-xilfpga {
 			description = "MIPSfpga Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@xilfpga";
+			kernel = "kernel";
+			fdt = "fdt-xilfpga";
 		};
 	};
 };
diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
index 1a08438fd893..3e254676540f 100644
--- a/arch/mips/generic/vmlinux.its.S
+++ b/arch/mips/generic/vmlinux.its.S
@@ -6,7 +6,7 @@
 	#address-cells = <ADDR_CELLS>;
 
 	images {
-		kernel@0 {
+		kernel {
 			description = KERNEL_NAME;
 			data = /incbin/(VMLINUX_BINARY);
 			type = "kernel";
@@ -15,18 +15,18 @@
 			compression = VMLINUX_COMPRESSION;
 			load = /bits/ ADDR_BITS <VMLINUX_LOAD_ADDRESS>;
 			entry = /bits/ ADDR_BITS <VMLINUX_ENTRY_ADDRESS>;
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		default = "conf@default";
+		default = "conf-default";
 
-		conf@default {
+		conf-default {
 			description = "Generic Linux kernel";
-			kernel = "kernel@0";
+			kernel = "kernel";
 		};
 	};
 };

base-commit: eb575cd5d7f60241d016fdd13a9e86d962093c9b
-- 
2.32.0.93.g670b81a890


[-- Attachment #4: e607ff630c60-5.4.patch --]
[-- Type: text/plain, Size: 6109 bytes --]

From d81f8031f27753526fee7e9b5fb405ebce0faa2d Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 9 Apr 2021 12:21:28 -0700
Subject: [PATCH 5.4] MIPS: generic: Update node names to avoid unit addresses

commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream.

With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
longer build, failing with:

/usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1

This is expected after the linked U-Boot commits because '@' is
forbidden in the node names due to the way that libfdt treats nodes with
the same prefix but different unit addresses.

Switch the '@' in the node name to '-'. Drop the unit addresses from the
hash and kernel child nodes because there is only one node so they do
not need to have a number to differentiate them.

Cc: stable@vger.kernel.org
Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
[nathan: Backport to 5.4, only apply to .its.S files that exist]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/generic/board-boston.its.S   | 10 +++++-----
 arch/mips/generic/board-ni169445.its.S | 10 +++++-----
 arch/mips/generic/board-ocelot.its.S   | 20 ++++++++++----------
 arch/mips/generic/board-xilfpga.its.S  | 10 +++++-----
 arch/mips/generic/vmlinux.its.S        | 10 +++++-----
 5 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/mips/generic/board-boston.its.S b/arch/mips/generic/board-boston.its.S
index a7f51f97b910..c45ad2759421 100644
--- a/arch/mips/generic/board-boston.its.S
+++ b/arch/mips/generic/board-boston.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@boston {
+		fdt-boston {
 			description = "img,boston Device Tree";
 			data = /incbin/("boot/dts/img/boston.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@boston {
+		conf-boston {
 			description = "Boston Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@boston";
+			kernel = "kernel";
+			fdt = "fdt-boston";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ni169445.its.S b/arch/mips/generic/board-ni169445.its.S
index e4cb4f95a8cc..0a2e8f7a8526 100644
--- a/arch/mips/generic/board-ni169445.its.S
+++ b/arch/mips/generic/board-ni169445.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@ni169445 {
+		fdt-ni169445 {
 			description = "NI 169445 device tree";
 			data = /incbin/("boot/dts/ni/169445.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ni169445 {
+		conf-ni169445 {
 			description = "NI 169445 Linux Kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ni169445";
+			kernel = "kernel";
+			fdt = "fdt-ni169445";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ocelot.its.S b/arch/mips/generic/board-ocelot.its.S
index 3da23988149a..8c7e3a1b68d3 100644
--- a/arch/mips/generic/board-ocelot.its.S
+++ b/arch/mips/generic/board-ocelot.its.S
@@ -1,40 +1,40 @@
 /* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
 / {
 	images {
-		fdt@ocelot_pcb123 {
+		fdt-ocelot_pcb123 {
 			description = "MSCC Ocelot PCB123 Device Tree";
 			data = /incbin/("boot/dts/mscc/ocelot_pcb123.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 
-		fdt@ocelot_pcb120 {
+		fdt-ocelot_pcb120 {
 			description = "MSCC Ocelot PCB120 Device Tree";
 			data = /incbin/("boot/dts/mscc/ocelot_pcb120.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ocelot_pcb123 {
+		conf-ocelot_pcb123 {
 			description = "Ocelot Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ocelot_pcb123";
+			kernel = "kernel";
+			fdt = "fdt-ocelot_pcb123";
 		};
 
-		conf@ocelot_pcb120 {
+		conf-ocelot_pcb120 {
 			description = "Ocelot Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ocelot_pcb120";
+			kernel = "kernel";
+			fdt = "fdt-ocelot_pcb120";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-xilfpga.its.S b/arch/mips/generic/board-xilfpga.its.S
index a2e773d3f14f..08c1e900eb4e 100644
--- a/arch/mips/generic/board-xilfpga.its.S
+++ b/arch/mips/generic/board-xilfpga.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@xilfpga {
+		fdt-xilfpga {
 			description = "MIPSfpga (xilfpga) Device Tree";
 			data = /incbin/("boot/dts/xilfpga/nexys4ddr.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@xilfpga {
+		conf-xilfpga {
 			description = "MIPSfpga Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@xilfpga";
+			kernel = "kernel";
+			fdt = "fdt-xilfpga";
 		};
 	};
 };
diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
index 1a08438fd893..3e254676540f 100644
--- a/arch/mips/generic/vmlinux.its.S
+++ b/arch/mips/generic/vmlinux.its.S
@@ -6,7 +6,7 @@
 	#address-cells = <ADDR_CELLS>;
 
 	images {
-		kernel@0 {
+		kernel {
 			description = KERNEL_NAME;
 			data = /incbin/(VMLINUX_BINARY);
 			type = "kernel";
@@ -15,18 +15,18 @@
 			compression = VMLINUX_COMPRESSION;
 			load = /bits/ ADDR_BITS <VMLINUX_LOAD_ADDRESS>;
 			entry = /bits/ ADDR_BITS <VMLINUX_ENTRY_ADDRESS>;
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		default = "conf@default";
+		default = "conf-default";
 
-		conf@default {
+		conf-default {
 			description = "Generic Linux kernel";
-			kernel = "kernel@0";
+			kernel = "kernel";
 		};
 	};
 };

base-commit: 4037804c55745738e0950658a5132790e6ac52e4
-- 
2.32.0.93.g670b81a890


[-- Attachment #5: e607ff630c60-5.10.patch --]
[-- Type: text/plain, Size: 6111 bytes --]

From d66eb94d8d0c8ab52ebc2999777705077b9befeb Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <nathan@kernel.org>
Date: Fri, 9 Apr 2021 12:21:28 -0700
Subject: [PATCH 5.10] MIPS: generic: Update node names to avoid unit addresses

commit e607ff630c6053ecc67502677c0e50053d7892d4 upstream.

With the latest mkimage from U-Boot 2021.04, the generic defconfigs no
longer build, failing with:

/usr/bin/mkimage: verify_header failed for FIT Image support with exit code 1

This is expected after the linked U-Boot commits because '@' is
forbidden in the node names due to the way that libfdt treats nodes with
the same prefix but different unit addresses.

Switch the '@' in the node name to '-'. Drop the unit addresses from the
hash and kernel child nodes because there is only one node so they do
not need to have a number to differentiate them.

Cc: stable@vger.kernel.org
Link: https://source.denx.de/u-boot/u-boot/-/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4
Link: https://source.denx.de/u-boot/u-boot/-/commit/3f04db891a353f4b127ed57279279f851c6b4917
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
[nathan: Backport to 5.10, only apply to .its.S files that exist]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/generic/board-boston.its.S   | 10 +++++-----
 arch/mips/generic/board-ni169445.its.S | 10 +++++-----
 arch/mips/generic/board-ocelot.its.S   | 20 ++++++++++----------
 arch/mips/generic/board-xilfpga.its.S  | 10 +++++-----
 arch/mips/generic/vmlinux.its.S        | 10 +++++-----
 5 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/mips/generic/board-boston.its.S b/arch/mips/generic/board-boston.its.S
index a7f51f97b910..c45ad2759421 100644
--- a/arch/mips/generic/board-boston.its.S
+++ b/arch/mips/generic/board-boston.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@boston {
+		fdt-boston {
 			description = "img,boston Device Tree";
 			data = /incbin/("boot/dts/img/boston.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@boston {
+		conf-boston {
 			description = "Boston Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@boston";
+			kernel = "kernel";
+			fdt = "fdt-boston";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ni169445.its.S b/arch/mips/generic/board-ni169445.its.S
index e4cb4f95a8cc..0a2e8f7a8526 100644
--- a/arch/mips/generic/board-ni169445.its.S
+++ b/arch/mips/generic/board-ni169445.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@ni169445 {
+		fdt-ni169445 {
 			description = "NI 169445 device tree";
 			data = /incbin/("boot/dts/ni/169445.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ni169445 {
+		conf-ni169445 {
 			description = "NI 169445 Linux Kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ni169445";
+			kernel = "kernel";
+			fdt = "fdt-ni169445";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-ocelot.its.S b/arch/mips/generic/board-ocelot.its.S
index 3da23988149a..8c7e3a1b68d3 100644
--- a/arch/mips/generic/board-ocelot.its.S
+++ b/arch/mips/generic/board-ocelot.its.S
@@ -1,40 +1,40 @@
 /* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
 / {
 	images {
-		fdt@ocelot_pcb123 {
+		fdt-ocelot_pcb123 {
 			description = "MSCC Ocelot PCB123 Device Tree";
 			data = /incbin/("boot/dts/mscc/ocelot_pcb123.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 
-		fdt@ocelot_pcb120 {
+		fdt-ocelot_pcb120 {
 			description = "MSCC Ocelot PCB120 Device Tree";
 			data = /incbin/("boot/dts/mscc/ocelot_pcb120.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@ocelot_pcb123 {
+		conf-ocelot_pcb123 {
 			description = "Ocelot Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ocelot_pcb123";
+			kernel = "kernel";
+			fdt = "fdt-ocelot_pcb123";
 		};
 
-		conf@ocelot_pcb120 {
+		conf-ocelot_pcb120 {
 			description = "Ocelot Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@ocelot_pcb120";
+			kernel = "kernel";
+			fdt = "fdt-ocelot_pcb120";
 		};
 	};
 };
diff --git a/arch/mips/generic/board-xilfpga.its.S b/arch/mips/generic/board-xilfpga.its.S
index a2e773d3f14f..08c1e900eb4e 100644
--- a/arch/mips/generic/board-xilfpga.its.S
+++ b/arch/mips/generic/board-xilfpga.its.S
@@ -1,22 +1,22 @@
 / {
 	images {
-		fdt@xilfpga {
+		fdt-xilfpga {
 			description = "MIPSfpga (xilfpga) Device Tree";
 			data = /incbin/("boot/dts/xilfpga/nexys4ddr.dtb");
 			type = "flat_dt";
 			arch = "mips";
 			compression = "none";
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		conf@xilfpga {
+		conf-xilfpga {
 			description = "MIPSfpga Linux kernel";
-			kernel = "kernel@0";
-			fdt = "fdt@xilfpga";
+			kernel = "kernel";
+			fdt = "fdt-xilfpga";
 		};
 	};
 };
diff --git a/arch/mips/generic/vmlinux.its.S b/arch/mips/generic/vmlinux.its.S
index 1a08438fd893..3e254676540f 100644
--- a/arch/mips/generic/vmlinux.its.S
+++ b/arch/mips/generic/vmlinux.its.S
@@ -6,7 +6,7 @@
 	#address-cells = <ADDR_CELLS>;
 
 	images {
-		kernel@0 {
+		kernel {
 			description = KERNEL_NAME;
 			data = /incbin/(VMLINUX_BINARY);
 			type = "kernel";
@@ -15,18 +15,18 @@
 			compression = VMLINUX_COMPRESSION;
 			load = /bits/ ADDR_BITS <VMLINUX_LOAD_ADDRESS>;
 			entry = /bits/ ADDR_BITS <VMLINUX_ENTRY_ADDRESS>;
-			hash@0 {
+			hash {
 				algo = "sha1";
 			};
 		};
 	};
 
 	configurations {
-		default = "conf@default";
+		default = "conf-default";
 
-		conf@default {
+		conf-default {
 			description = "Generic Linux kernel";
-			kernel = "kernel@0";
+			kernel = "kernel";
 		};
 	};
 };

base-commit: 3de043c6851d7c604e0cabdf8e2aca7797952aa9
-- 
2.32.0.93.g670b81a890


^ permalink raw reply related	[relevance 48%]

Results 1-200 of ~300   | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-06-23 17:26     [PATCH 4.4 to 4.19] Makefile: Move -Wno-unused-but-set-variable out of GCC only block Nathan Chancellor
2021-06-24 12:04     ` Sasha Levin
2021-06-24 16:36 99%   ` Nathan Chancellor
2021-06-23 20:13 48% Backport of e607ff630c60 for 4.14 to 5.10 Nathan Chancellor
2021-07-27 22:56 96% [PATCH 4.9 1/2] iommu/amd: Fix backport of 140456f994195b568ecd7fc2287a34eadffef3ca Nathan Chancellor
2021-07-27 22:56 94% ` [PATCH 4.9 2/2] tipc: Fix backport of b77413446408fdd256599daf00d5be72b5f3e7c6 Nathan Chancellor
2021-07-30 22:38 96% [PATCH] vmlinux.lds.h: Handle clang's module.{c,d}tor sections Nathan Chancellor
2021-07-30 22:42     ` Nick Desaulniers
2021-07-30 22:59       ` Fangrui Song
2021-07-31  0:32 99%     ` Nathan Chancellor
2021-07-31  2:31 93% ` [PATCH v2] " Nathan Chancellor
     [not found]     <1406720038.945.1627915387982@localhost>
2021-08-02 17:28 99% ` [CI-NOTIFY]: TCWG Bisect tcwg_kernel/llvm-release-arm-stable-allyesconfig - Build # 4 - Successful! Nathan Chancellor
     [not found]     <202108060412.oMqAe0rc-lkp@intel.com>
     [not found]     ` <CAKwvOdk6PNK1unJ2Yym4WHV=AXjdYwEyfWf_fPxO013ZtJa6Yw@mail.gmail.com>
2021-08-06  0:11 97%   ` [linux-stable-rc:linux-4.19.y 1181/1498] ERROR: "__compiletime_assert_491" [drivers/gpu/drm/i915/i915.ko] undefined! Nathan Chancellor
     [not found]     <16290320662366@kroah.com>
2021-08-15 22:54 77% ` Patch "vmlinux.lds.h: Handle clang's module.{c,d}tor sections" has been added to the 5.13-stable tree Nathan Chancellor
2021-09-14  9:41     [PATCH] x86/setup: call early_reserve_memory() earlier Juergen Gross
2021-09-16 10:50     ` [tip: x86/urgent] x86/setup: Call " tip-bot2 for Juergen Gross
2021-09-19 16:55       ` Mike Galbraith
2021-09-19 17:15         ` Borislav Petkov
2021-09-20 22:48 99%       ` Nathan Chancellor
2021-09-20 12:04     [PATCH v2] x86/setup: call " Juergen Gross
2021-09-21  3:59 99% ` Nathan Chancellor
2021-10-24  2:35     i386: tinyconfig: perf_event.h:838:21: error: invalid output size for constraint '=q' Naresh Kamboju
2021-10-25 14:41 99% ` Nathan Chancellor
2021-10-27 16:27 99% Apply 091bb549f7722723b284f63ac665e2aedcf9dec9 to 4.19 Nathan Chancellor
2021-11-04 18:17 92% Please apply 3d5e7a28b1ea2d603dea478e58e37ce75b9597ab to 5.15, 5.14, and 5.10 Nathan Chancellor
2021-11-15 16:43 86% [PATCH 5.10] scripts/lld-version.sh: Rewrite based on upstream ld-version.sh Nathan Chancellor
     [not found]     <20211115174250.1994179-1-nathan@kernel.org>
2021-11-15 17:42 96% ` [PATCH v2 1/3] hexagon: Export raw I/O routines for modules Nathan Chancellor
2021-11-15 17:42 86% ` [PATCH v2 2/3] hexagon: Clean up timer-regs.h Nathan Chancellor
2021-11-15 18:39 99% Apply a52f8a59aef46b59753e583bf4b28fccb069ce64 to 5.15 through 4.19 Nathan Chancellor
2021-12-23 22:21 96% [PATCH] ARM: davinci: da850-evm: Avoid NULL pointer dereference Nathan Chancellor
2022-02-03 17:09 99% ` Nathan Chancellor
2022-01-03 19:29 92% [PATCH 5.4] Input: touchscreen - Fix backport of a02dcde595f7cbd240ccd64de96034ad91cffc40 Nathan Chancellor
2022-01-07 19:43 85% [PATCH RFC 4.9 0/5] Fix booting arm64 big endian with QEMU 5.0.0+ Nathan Chancellor
2022-01-07 19:43 69% ` [PATCH RFC 4.9 1/5] bug: split BUILD_BUG stuff out into <linux/build_bug.h> Nathan Chancellor
2022-01-07 19:43 99% ` [PATCH RFC 4.9 2/5] arm64: Remove a redundancy in sysreg.h Nathan Chancellor
2022-01-07 19:43 93% ` [PATCH RFC 4.9 3/5] arm64: reduce el2_setup branching Nathan Chancellor
2022-01-07 19:43 89% ` [PATCH RFC 4.9 4/5] arm64: move !VHE work to end of el2_setup Nathan Chancellor
2022-01-07 19:43 75% ` [PATCH RFC 4.9 5/5] arm64: sysreg: Move to use definitions for all the SCTLR bits Nathan Chancellor
2022-01-09 12:51     FAILED: patch "[PATCH] power: reset: ltc2952: Fix use of floating point literals" failed to apply to 4.9-stable tree gregkh
2022-01-09 18:59 92% ` [PATCH 4.4,4.9] power: reset: ltc2952: Fix use of floating point literals Nathan Chancellor
2022-01-13 22:38 99% Patches for clang and CONFIG_WERROR (arm64/x86_64) Nathan Chancellor
2022-01-25 13:48     stable-rc 5.4 queue riscv tinyconfig build failed Naresh Kamboju
2022-01-25 17:27 99% ` Nathan Chancellor
2022-01-27 22:15     [PATCH] usb: dwc3: xilinx: fix uninitialized return value Robert Hancock
2022-01-29 20:55 99% ` Nathan Chancellor
2022-02-01 23:22 94% [PATCH] Makefile.extrawarn: Move -Wunaligned-access to W=2 Nathan Chancellor
2022-02-02  8:12     ` Arnd Bergmann
2022-02-02 16:26 91%   ` Nathan Chancellor
2022-02-02 23:05 95% [PATCH v2] Makefile.extrawarn: Move -Wunaligned-access to W=1 Nathan Chancellor
2022-02-02 23:12     ` Nick Desaulniers
2022-02-08  4:23       ` Masahiro Yamada
2022-02-08 16:04 99%     ` Nathan Chancellor
2022-02-14  9:24     [PATCH 5.16 000/203] 5.16.10-rc1 review Greg Kroah-Hartman
2022-02-14 10:59     ` Naresh Kamboju
2022-02-14 11:27       ` Greg Kroah-Hartman
2022-02-14 15:37 99%     ` Nathan Chancellor
2022-02-14 16:16 94% [PATCH 4.9 to 5.4] Makefile.extrawarn: Move -Wunaligned-access to W=1 Nathan Chancellor
2022-03-09 19:16 89% [PATCH] arm64: Do not include __READ_ONCE() block in assembly files Nathan Chancellor
2022-03-09 22:07 94% [PATCH] ARM: Do not use NOCROSSREFS directive with ld.lld Nathan Chancellor
2022-03-24 15:36 92% [PATCH] btrfs: Remove unused variable in btrfs_{start,write}_dirty_block_groups() Nathan Chancellor
2022-04-05 20:58 99% Backport of 4013e26670c5 and 60210a3d86dc for 4.9 to 5.10 Nathan Chancellor
2022-04-11 16:43 99% [PATCH 5.4 0/2] Fix two instances of -Wstrict-prototypes in drm/amd Nathan Chancellor
2022-04-11 16:43 99% ` [PATCH 5.4 1/2] drm/amdkfd: add missing void argument to function kgd2kfd_init Nathan Chancellor
2022-04-11 16:43 95% ` [PATCH 5.4 2/2] drm/amdkfd: Fix -Wstrict-prototypes from amdgpu_amdkfd_gfx_10_0_get_functions() Nathan Chancellor
2022-04-14 20:29 99% btrfs warning fixes for 5.15 and 5.17 Nathan Chancellor
2022-04-19 21:27 98% Apply d799769188529abc6cbf035a10087a51f7832b6b to 5.17 and 5.15? Nathan Chancellor
2022-04-21  7:46     ` Michael Ellerman
2022-04-21 15:13 99%   ` Nathan Chancellor
2022-05-03 21:34 99%     ` Nathan Chancellor
2022-05-10 17:49 99% Warning fixes for clang + x86_64 allmodconfig on 5.10 and 5.4 Nathan Chancellor
2022-05-14 15:34     [PATCH 4.19] MIPS: fix allmodconfig build with latest mkimage Sudip Mukherjee
2022-05-14 21:03 99% ` Nathan Chancellor
2022-06-02 16:14     boot loop since 5.17.6 Thomas Sattler
2022-06-02 16:42     ` Thomas Sattler
2022-06-02 19:24       ` Thomas Sattler
2022-06-02 21:32 99%     ` Nathan Chancellor
2022-06-17 18:08 87% [PATCH] x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang Nathan Chancellor
2022-07-01 22:17 99% ` Nathan Chancellor
2022-07-06 22:25     ` Dave Hansen
2022-07-07 17:17 99%   ` Nathan Chancellor
2022-06-27 17:57 99% Apply 1e70212e031528918066a631c9fdccda93a1ffaa to 5.18 Nathan Chancellor
2022-06-30 13:46     [PATCH 5.15 00/28] 5.15.52-rc1 review Greg Kroah-Hartman
2022-06-30 13:46     ` [PATCH 5.15 02/28] clocksource/drivers/ixp4xx: remove __init from ixp4xx_timer_setup() Greg Kroah-Hartman
2022-07-01 15:31 99%   ` Nathan Chancellor
2022-07-13 15:22 97% [PATCH] x86/speculation: Use DECLARE_PER_CPU for x86_spec_ctrl_current Nathan Chancellor
2022-07-13 15:24 99% ` Nathan Chancellor
2022-07-13 15:24 96% [PATCH v2] " Nathan Chancellor
2022-07-13 16:22     ` Peter Zijlstra
2022-07-13 16:27 99%   ` Nathan Chancellor
2022-07-25 23:36 98% [PATCH] drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid() Nathan Chancellor
2022-07-27 16:46 96% [PATCH 4.9] ion: Make user_ion_handle_put_nolock() a void function Nathan Chancellor
2022-08-12  0:24 97% Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10? Nathan Chancellor
2022-08-24  7:01     [PATCH 5.19 000/362] 5.19.4-rc2 review Greg Kroah-Hartman
2022-08-24 20:13     ` Naresh Kamboju
2022-08-24 20:19 99%   ` Nathan Chancellor
2022-09-04 13:18     [PATCH stable 5.15 0/2] kbuild: Fix compilation for latest pahole release Jiri Olsa
2022-09-04 14:10     ` Greg KH
2022-09-05  7:04       ` Jiri Olsa
2022-09-06 12:03         ` Greg KH
2022-09-18 22:14           ` Jiri Olsa
2022-10-17 18:02 99%         ` Nathan Chancellor
2022-09-10 14:34 99% Apply 5c5c2baad2b55cc0a4b190266889959642298f79 to 5.10+ Nathan Chancellor
2022-09-12 22:48     [PATCH v4] RISC-V: Clean up the Zicbom block size probing Conor Dooley
2022-09-13  9:40 99% ` Nathan Chancellor
2022-09-28 20:19 89% [PATCH] usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video() Nathan Chancellor
2022-09-29 15:20 93% [PATCH] x86/Kconfig: Drop check for '-mabi=ms' for CONFIG_EFI_STUB Nathan Chancellor
2022-10-17 15:03 99% ` Nathan Chancellor
2022-09-30  6:06     [PATCH] hardening: Remove Clang's enable flag for -ftrivial-auto-var-init=zero Kees Cook
2022-10-03 16:41 98% ` Nathan Chancellor
2022-10-13 18:51 99% Backport of 607e57c6c62c009 for 5.10 and 5.15 Nathan Chancellor
2022-10-16 16:12     FAILED: patch "[PATCH] drm/simpledrm: Fix return type of" failed to apply to 6.0-stable tree gregkh
2022-10-17 18:09 99% ` Nathan Chancellor
2022-10-17 17:52 99% Apply 0a6de78cff60 to 5.15+ Nathan Chancellor
2022-10-24 11:29     [PATCH 5.4 086/255] once: add DO_ONCE_SLOW() for sleepable contexts Greg Kroah-Hartman
2022-10-29  1:12     ` Oleksandr Tymoshenko
2022-10-31 18:27 99%   ` Nathan Chancellor
2022-10-24 21:06     backports of 32ef9e5054ec ("Makefile.debug: re-enable debug info for .S files") Nick Desaulniers
2022-10-25 16:53 99% ` Nathan Chancellor
2022-10-26 15:28     FAILED: patch "[PATCH] x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB" failed to apply to 5.15-stable tree gregkh
2022-10-26 16:34 92% ` Nathan Chancellor
2022-11-08 17:49 96% [PATCH] vmlinux.lds.h: Fix placement of '.data..decrypted' section Nathan Chancellor
2022-11-28 22:53 94% [PATCH 5.4 and earlier only] mm: Fix '.data.once' orphan section warning Nathan Chancellor
2022-11-30  6:28     ` Hugh Dickins
2022-11-30 16:20 99%   ` Nathan Chancellor
2022-11-30 18:19     [PATCH 6.0 000/289] 6.0.11-rc1 review Greg Kroah-Hartman
2022-12-01  6:14     ` Naresh Kamboju
2022-12-01  6:57 99%   ` Nathan Chancellor
2022-12-12 13:15     [PATCH 6.0 000/157] 6.0.13-rc1 review Greg Kroah-Hartman
2022-12-13  6:31     ` Naresh Kamboju
2022-12-13 16:51 99%   ` Nathan Chancellor
2022-12-14 23:26 99% [PATCH] security: Restrict CONFIG_ZERO_CALL_USED_REGS to gcc or clang > 15.0.6 Nathan Chancellor
2022-12-19 15:17     Linux-stable-rc/ queue_5.10 Naresh Kamboju
2022-12-19 15:26 99% ` Nathan Chancellor
2022-12-28 14:31     [PATCH 5.15 000/731] 5.15.86-rc1 review Greg Kroah-Hartman
2022-12-29 14:40     ` Pavel Machek
2022-12-29 16:56 99%   ` Nathan Chancellor
2023-01-09  9:59     [PATCH] efi: tpm: Avoid READ_ONCE() for accessing the event log Ard Biesheuvel
2023-01-09 17:48 99% ` Nathan Chancellor
2023-01-16  3:35 42% [PATCH 6.1] drm/i915: Fix CFI violations in gt_sysfs Nathan Chancellor
2023-01-16  4:46 97% offsetof() backports for clang-16+ Nathan Chancellor
2023-01-16 15:47     [PATCH 4.14 000/338] 4.14.303-rc1 review Greg Kroah-Hartman
2023-01-16 15:51     ` [PATCH 4.14 230/338] wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() Greg Kroah-Hartman
2023-01-18 16:21 99%   ` Nathan Chancellor
2023-01-16 15:50     [PATCH 5.15 00/86] 5.15.89-rc1 review Greg Kroah-Hartman
2023-01-17 11:27     ` Naresh Kamboju
2023-01-17 14:23 99%   ` Nathan Chancellor
2023-02-03 10:12     [PATCH 6.1 00/28] 6.1.10-rc1 review Greg Kroah-Hartman
2023-02-04  7:25     ` Naresh Kamboju
2023-02-05 19:51 93%   ` Nathan Chancellor
2023-02-08  6:51     [PATCH] randstruct: disable Clang 15 support Eric Biggers
2023-02-08 14:32 99% ` Nathan Chancellor
2023-02-21  9:00     stable-rc: 5.10: riscv: defconfig: clang-nightly: build failed - Invalid or unknown z ISA extension: 'zifencei' Naresh Kamboju
2023-02-21  9:15     ` Conor Dooley
2023-02-21 22:33 99%   ` Nathan Chancellor
2023-02-21 19:48 99% static call fixes for clang's conditional tail calls (6.2 and 6.1) Nathan Chancellor
2023-02-23 14:16     [PATCH 5.15 00/37] 5.15.96-rc2 review Greg Kroah-Hartman
2023-02-23 15:36     ` Guenter Roeck
2023-02-23 16:33       ` Greg Kroah-Hartman
2023-02-23 17:30         ` Guenter Roeck
2023-02-23 18:03           ` Linus Torvalds
2023-02-23 19:47 98%         ` Nathan Chancellor
     [not found]     <20230223220546.52879-1-conor@kernel.org>
2023-02-23 22:05     ` [PATCH v1 2/2] RISC-V: make TOOLCHAIN_NEEDS_SPEC_20191213 gas only Conor Dooley
2023-02-24 16:32 99%   ` Nathan Chancellor
2023-02-28 16:17 95% Please apply 4e4a08868f15897ca236528771c3733fded42c62 to linux-6.2.y Nathan Chancellor
2023-03-13 23:00 73% [PATCH] riscv: Handle zicsr/zifencei issues between clang and binutils Nathan Chancellor
2023-03-29  0:08 97% [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
2023-03-29  0:08 70% ` [PATCH 5.10 1/4] kbuild: check the minimum assembler version in Kconfig Nathan Chancellor
2023-03-29  0:08 92% ` [PATCH 5.10 2/4] kbuild: Switch to 'f' variants of integrated assembler flag Nathan Chancellor
2023-03-29  0:08 96% ` [PATCH 5.10 3/4] kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS Nathan Chancellor
2023-03-29  0:08 77% ` [PATCH 5.10 4/4] riscv: Handle zicsr/zifencei issues between clang and binutils Nathan Chancellor
2023-04-11 16:20 99% ` [PATCH 5.10 0/4] Backport of e89c2e815e76 to linux-5.10.y Nathan Chancellor
2023-04-12  6:17       ` Greg KH
2023-04-18  9:46         ` Greg KH
2023-04-18 16:19 99%       ` Nathan Chancellor
2023-03-30 18:22     [PATCH v3] purgatory: fix disabling debug info Alyssa Ross
2023-03-30 22:29 99% ` Nathan Chancellor
2023-04-27 19:34 90% [PATCH] powerpc/boot: Disable power10 features after BOOTAFLAGS assignment Nathan Chancellor
2023-06-05 21:15 94% [PATCH 6.3] riscv: vmlinux.lds.S: Explicitly handle '.got' section Nathan Chancellor
2023-06-12 18:40     clang: Powerpc: clang-nightly-maple_defconfig — FAIL Naresh Kamboju
2023-06-12 18:54 92% ` Nathan Chancellor
2023-06-13  4:27       ` Naresh Kamboju
2023-06-14 14:13         ` Naresh Kamboju
2023-06-14 18:07 99%       ` Nathan Chancellor
2023-06-14 18:04 92% [PATCH 6.1 0/4] Update as-{instr,option} to use KBUILD_AFLAGS Nathan Chancellor
2023-06-14 18:04 95% ` [PATCH 6.1 1/4] x86/boot/compressed: prefer cc-option for CFLAGS additions Nathan Chancellor
2023-06-14 18:04 95% ` [PATCH 6.1 2/4] MIPS: Move '-Wa,-msoft-float' check from as-option to cc-option Nathan Chancellor
2023-06-14 18:04 93% ` [PATCH 6.1 3/4] MIPS: Prefer cc-option for additions to cflags Nathan Chancellor
2023-06-14 18:04 83% ` [PATCH 6.1 4/4] kbuild: Update assembler calls to use proper flags and language target Nathan Chancellor
2023-06-20 17:44 95% [PATCH 6.3] riscv: Link with '-z norelro' Nathan Chancellor
2023-06-26  7:50     [PATCH] MIPS: Loongson: Fix build error when make modules_install Huacai Chen
2023-06-26 16:07 99% ` Nathan Chancellor
2023-06-27  3:11       ` Huacai Chen
2023-06-27 21:28 93%     ` Nathan Chancellor
2023-06-28 11:08     [PATCH V2] " Huacai Chen
2023-06-28 15:22 99% ` Nathan Chancellor
2023-07-03 15:03 99% Apply clang '--target=' KBUILD_CPPFLAGS shuffle to linux-6.4.y and linux-6.3.y Nathan Chancellor
2023-07-03 21:43 99% [PATCH] ASoC: cs35l45: Select REGMAP_IRQ Nathan Chancellor
     [not found]     <168899125356.80889.17967397360941194229.stgit@devnote2>
     [not found]     ` <20230710155703.GA4021842@dev-arch.thelio-3990X>
     [not found]       ` <20230711103303.287af608cc47dcf70d709070@kernel.org>
2023-07-11 18:37 96%     ` [RFC PATCH 0/2] x86: kprobes: Fix CFI_CLANG related issues Nathan Chancellor
2023-07-16 19:25     stable-rc 6.1: x86: clang build failed - block/blk-cgroup.c:1237:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true Naresh Kamboju
2023-07-17 13:24 99% ` Nathan Chancellor
2023-07-18  5:52     [PATCH] kbuild: rust: avoid creating temporary files Miguel Ojeda
2023-07-18 16:43 99% ` Nathan Chancellor
2023-08-07  6:37     [PATCH] cpufreq: amd-pstate: fix global sysfs attribute type Thomas Weißschuh
2023-08-07 16:06 99% ` Nathan Chancellor
2023-08-07 15:36 92% [PATCH v2] lib: test_scanf: Add explicit type cast to result initialization in test_number_prefix() Nathan Chancellor
2023-08-16 11:01     ` Petr Mladek
2023-08-16 14:01 99%   ` Nathan Chancellor
2023-08-08  6:22     stable-rc 5.15: clang-17: davinci_all_defconfig failed - arch/arm/include/asm/tlbflush.h:420:85: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] Naresh Kamboju
2023-08-08 15:13 98% ` Nathan Chancellor
2023-08-09  6:10     ld.lld: error: ./arch/x86/kernel/vmlinux.lds:191: at least one side of the expression must be absolute Naresh Kamboju
2023-08-09  6:24     ` Naresh Kamboju
2023-08-09 15:47       ` Nick Desaulniers
2023-08-09 15:53 99%     ` Nathan Chancellor
2023-08-09 10:39     [PATCH 6.1 000/127] 6.1.45-rc1 review Greg Kroah-Hartman
2023-08-11  3:22     ` Naresh Kamboju
2023-08-11  3:36 99%   ` Nathan Chancellor
2023-08-11  3:41       ` Guenter Roeck
2023-08-11  4:13 93%     ` Nathan Chancellor
2023-08-13 11:02           ` Borislav Petkov
2023-08-14 16:52 99%         ` Nathan Chancellor
2023-08-28 12:27     clang: net: qed_main.c:1227:3: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 18 [-Werror,-Wfortify-source] Naresh Kamboju
2023-08-28 14:48 91% ` Nathan Chancellor
2023-08-30 15:33 99% Apply 9451c79bc39e610882bdd12370f01af5004a3c4f to linux-5.4.y Nathan Chancellor
2023-09-05 20:36 89% [PATCH 5.15] of: kexec: Mark ima_{free,stable}_kexec_buffer() as __init Nathan Chancellor
2023-09-08 16:15 96% Apply 13e07691a16f and co. to linux-6.1.y Nathan Chancellor
2023-09-15 16:42     [PATCH v2] bpf: Fix BTF_ID symbol generation collision Nick Desaulniers
2023-09-15 17:18 99% ` Nathan Chancellor
2023-09-15 17:34     [PATCH bpf v3 0/2] link to v1: https://lore.kernel.org/bpf/20230915103228.1196234-1-jolsa@kernel.org/ Nick Desaulniers
2023-09-15 17:34     ` [PATCH bpf v3 1/2] bpf: Fix BTF_ID symbol generation collision Nick Desaulniers
2023-09-15 18:30 99%   ` Nathan Chancellor
2023-09-22 15:51 95% [PATCH 5.10] drm/mediatek: Fix backport issue in mtk_drm_gem_prime_vmap() Nathan Chancellor
2023-10-18 18:24     [PATCH] lib/Kconfig.debug: disable FRAME_WARN for kasan and kcsan Hamza Mahfooz
2023-10-18 18:29     ` Geert Uytterhoeven
2023-10-18 18:39       ` Hamza Mahfooz
2023-10-18 19:12         ` Geert Uytterhoeven
2023-10-19 10:04           ` Alexander Potapenko
2023-10-19 12:53             ` Arnd Bergmann
2023-10-19 15:56 89%           ` Nathan Chancellor
2023-10-19 20:17                 ` Hamza Mahfooz
2023-10-19 20:51 95%               ` Nathan Chancellor
2023-11-01 19:43 89% [PATCH] LoongArch: Mark __percpu functions as always inline Nathan Chancellor
2023-11-01 19:55 99% ` Nathan Chancellor
2023-11-02  2:18       ` Huacai Chen
2023-11-02  2:35 99%     ` Nathan Chancellor
2023-11-02 15:43 83% [PATCH v2] " Nathan Chancellor
2023-11-03 15:37     stable-rc: 4.14 and 4.19: arch/x86/kernel/head_32.S:126: Error: invalid character '(' in mnemonic Naresh Kamboju
2023-11-03 15:57     ` Greg Kroah-Hartman
2023-11-03 15:59       ` Greg Kroah-Hartman
2023-11-03 16:09 99%     ` Nathan Chancellor
2023-11-15  9:58     [PATCH v2 1/1] ARM: kprobes: Explicitly reserve r7 for local variables Maria Yu
2023-11-16 17:24 99% ` Nathan Chancellor
2023-11-20  3:29     [PATCH v3 " Maria Yu
2023-11-21 16:11     ` Ard Biesheuvel
2023-11-21 16:38 99%   ` Nathan Chancellor
2023-11-29  0:35 90% [PATCH 5.4] PCI: keystone: Drop __init from ks_pcie_add_pcie_{ep,port}() Nathan Chancellor
2023-11-29  0:37 90% [PATCH 5.10] " Nathan Chancellor
2023-12-05  3:16     [PATCH 5.4 00/94] 5.4.263-rc1 review Greg Kroah-Hartman
2023-12-05  3:17     ` [PATCH 5.4 63/94] btrfs: add dmesg output for first mount and last unmount of a filesystem Greg Kroah-Hartman
2023-12-09 17:28 99%   ` Nathan Chancellor
     [not found]     <20231108000749.GA3723879@dev-arch.thelio-3990X>
2023-12-12 17:10     ` [PATCH v2] rpm-pkg: simplify installkernel %post Jose Ignacio Tornos Martinez
2023-12-12 19:19 99%   ` Nathan Chancellor
2023-12-13  0:03 99% Apply b8ec60e1186cdcfce41e7db4c827cb107e459002 to linux-6.6.y Nathan Chancellor
2023-12-19 16:49     [PATCH v3] rpm-pkg: simplify installkernel %post Masahiro Yamada
2023-12-19 20:17     ` [PATCH v4] " Jose Ignacio Tornos Martinez
2023-12-20 17:18 99%   ` Nathan Chancellor
2024-01-09  9:36     riscv: clang-nightly-allmodconfig: failed on stable-rc 6.6 and 6.1 Naresh Kamboju
2024-01-09 15:26 99% ` Nathan Chancellor
2024-01-12  0:40 85% [PATCH] media: mxl5xx: Move xpt structures off stack Nathan Chancellor
2024-02-10 16:26     ` Miguel Ojeda
2024-02-12 23:27 99%   ` Nathan Chancellor
2024-01-22 23:55     [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
2024-01-26 16:46     ` Guenter Roeck
2024-01-26 17:51       ` Greg Kroah-Hartman
2024-01-26 18:17         ` Guenter Roeck
2024-01-26 20:34 96%       ` Nathan Chancellor
2024-01-26 21:01             ` Guenter Roeck
2024-01-26 22:35 92%           ` Nathan Chancellor
2024-01-26 23:55                 ` Guenter Roeck
2024-01-27  0:03 99%               ` Nathan Chancellor
2024-01-23 22:59 97% [PATCH 0/2] Fix UML build with clang-18 and newer Nathan Chancellor
2024-01-23 22:59 89% ` [PATCH 1/2] um: Fix adding '-no-pie' for clang Nathan Chancellor
2024-01-23 22:59 94% ` [PATCH 2/2] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS Nathan Chancellor
2024-01-25 17:32 95% [PATCH 0/2] RISC-V: Fix CONFIG_AS_HAS_OPTION_ARCH with tip of tree LLVM Nathan Chancellor
2024-01-25 17:32 91% ` [PATCH 1/2] kbuild: Add -Wa,--fatal-warnings to as-instr invocation Nathan Chancellor
2024-01-25 17:32 90% ` [PATCH 2/2] RISC-V: Drop invalid test from CONFIG_AS_HAS_OPTION_ARCH Nathan Chancellor
2024-01-26 17:36 94% [PATCH 4.19] powerpc: Use always instead of always-y in for crtsavres.o Nathan Chancellor
2024-01-26 17:37 94% [PATCH 5.4] " Nathan Chancellor
2024-01-27 18:07 96% [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS Nathan Chancellor
2024-03-05 22:43 99% ` Nathan Chancellor
2024-03-06  1:01       ` Michael Ellerman
2024-03-06 16:48 99%     ` Nathan Chancellor
2024-01-27 22:04     FAILED: patch "[PATCH] platform/x86: intel-uncore-freq: Fix types in sysfs callbacks" failed to apply to 6.1-stable tree gregkh
2024-01-27 22:57 72% ` [PATCH 6.1] platform/x86: intel-uncore-freq: Fix types in sysfs callbacks Nathan Chancellor
2024-02-05 21:54 87% [PATCH] drm/amd/display: Increase frame-larger-than for all display_mode_vba files Nathan Chancellor
2024-02-06 11:05     [PATCH 0/6] tools: Fix rtla and rv problems (found) with clang Daniel Bristot de Oliveira
2024-02-06 11:05     ` [PATCH 1/6] tools/rtla: Fix Makefile compiler options for clang Daniel Bristot de Oliveira
2024-02-06 15:48 99%   ` Nathan Chancellor
2024-02-08 20:21 88% [PATCH] kbuild: Fix changing ELF file type for output of gen_btf for big endian Nathan Chancellor
2024-02-13  0:55     ` Masahiro Yamada
2024-02-13  1:43 96%   ` Nathan Chancellor
2024-02-13  2:05 85% [PATCH v2] " Nathan Chancellor
2024-02-21 13:00     [PATCH 5.15 000/476] 5.15.149-rc1 review Greg Kroah-Hartman
2024-02-21 13:07     ` [PATCH 5.15 380/476] kbuild: Fix changing ELF file type for output of gen_btf for big endian Greg Kroah-Hartman
2024-02-21 16:54 98%   ` Nathan Chancellor
2024-02-21 21:46 92% [PATCH net] xfrm: Avoid clang fortify warning in copy_to_user_tmpl() Nathan Chancellor
2024-02-25 19:47 99% Please apply 56778b49c9a2cbc32c6b0fbd3ba1a9d64192d3af to linux-6.7.y Nathan Chancellor
2024-02-28  1:45 99% Please apply commit 5b750b22530fe53bf7fd6a30baacd53ada26911b to linux-6.1.y Nathan Chancellor
2024-03-01 14:42     6.6.19 won't compile with " [*] Compile the kernel with warnings as errors" Rainer Fiebig
2024-03-01 17:56 99% ` Nathan Chancellor
2024-03-05 17:42 87% [PATCH] kbuild: Disable two Clang specific enumeration warnings Nathan Chancellor
2024-03-05 18:49     ` Arnd Bergmann
2024-03-05 18:52       ` Nick Desaulniers
2024-03-05 19:30 95%     ` Nathan Chancellor
2024-03-05 21:52           ` Arnd Bergmann
2024-03-05 22:14 99%         ` Nathan Chancellor
2024-03-05 22:12 88% [PATCH v2] kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1 Nathan Chancellor
2024-03-05 22:49 83% [PATCH v2] media: mxl5xx: Move xpt structures off stack Nathan Chancellor
2024-03-12  8:04     [PATCH] memtest: use {READ,WRITE}_ONCE in memory scanning Qiang Zhang
2024-03-13 17:21 99% ` Nathan Chancellor
2024-03-13 16:41     [PATCH 5.15 00/76] 5.15.152-rc1 review Sasha Levin
2024-03-13 16:41     ` [PATCH 5.15 45/76] modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS Sasha Levin
2024-03-13 17:12 99%   ` Nathan Chancellor
2024-03-20  0:37 99% [PATCH] hexagon: vmlinux.lds.S: Handle attributes section Nathan Chancellor
2024-03-27 12:20     FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 5.10-stable tree Sasha Levin
2024-03-27 15:16 91% ` Nathan Chancellor
2024-04-01 18:24 78% [PATCH bluetooth] Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old() Nathan Chancellor
2024-04-04 14:17     [PATCH v3] rust: make mutually exclusive with CFI_CLANG Conor Dooley
2024-04-04 15:32 99% ` Nathan Chancellor
2024-04-18 20:17     [PATCH] x86/purgatory: Switch to the position-independent small code model Ard Biesheuvel
2024-04-18 20:37 99% ` Nathan Chancellor
     [not found]     <20240421171119.1444407-1-sashal@kernel.org>
2024-04-22 18:54 91% ` Patch "configs/hardening: Fix disabling UBSAN configurations" has been added to the 6.8-stable tree Nathan Chancellor
2024-04-22 23:12       ` Sasha Levin
2024-04-23  0:00 99%     ` Nathan Chancellor
2024-04-25 16:55 96% [PATCH 0/2] clk: bcm: Move a couple of __counted_by initializations Nathan Chancellor
2024-04-25 16:55 93% ` [PATCH 1/2] clk: bcm: dvp: Assign ->num before accessing ->hws Nathan Chancellor
2024-04-25 16:55 93% ` [PATCH 2/2] clk: bcm: rpi: " Nathan Chancellor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).