* Re: [PATCH v3] docs: rust: Add rusttest info
@ 2023-12-12 18:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-12 18:11 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: John Hubbard, Dirk Behme, rust-for-linux, llvm
On Tue, Dec 12, 2023 at 01:43:16PM +0100, Miguel Ojeda wrote:
> On Tue, Dec 12, 2023 at 4:14 AM John Hubbard <jhubbard@nvidia.com> wrote:
> >
> > "make LLVM=1 <anything>" doesn't work for me, and therefore I suspect it
> > doesn't work for at least a few other people, as well.
> >
> > Instead, I have to run "make CC=clang <anything>", which works just
> > fine.
> >
> > The docs should consistently reflect this, yes?
>
> No, they should not. `LLVM=1` is the "right" one for all architectures
> (except s390) -- see Documentation/kbuild/llvm.rst.
>
> If `LLVM=1` does not work for you, then that should be fixed. Could
> you please give some details? For instance, is it related to Rust
> (does it work with a `defconfig` build without enabling Rust)? Do you
> have all the LLVM software installed with the right names (see what
> `LLVM=1` expands to)? etc.
Right, there are definitely edges cases with LLVM=1, namely for s390 as
mentioned as well as powerpc but for at least arm{,64} and x86{,_64},
things should work well and they should be fixed if not. Additional
information and bug reports are always welcomed at either
llvm@lists.linux.dev or https://github.com/ClangBuiltLinux/linux/issues.
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] power: reset: at91: mark at91_wakeup_status non-__init
@ 2023-12-12 21:50 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-12 21:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sebastian Reichel, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Uwe Kleine-König, Arnd Bergmann,
Nick Desaulniers, Bill Wendling, Justin Stitt, Yangtao Li,
linux-pm, linux-arm-kernel, linux-kernel, llvm
On Tue, Dec 12, 2023 at 10:46:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Two copies of the at91_wakeup_status() function are called by the
> respective probe() callbacks and are marked __init, but the probe
> functions are no longer annotated that way. This works with gcc because
> the functions always get inlined, but clang keeps them separate, which
> can lead to executing freed memory:
>
> WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
>
> Drop the incorrect annotation on these.
>
> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, I sent the same change three weeks ago at this point:
https://lore.kernel.org/20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org/
Your commit message is a little better than mine and I don't really care
which one goes in but it would be good if this could get cleared up
soon...
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/power/reset/at91-poweroff.c | 2 +-
> drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index 126e774e210c..93eece027865 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -57,7 +57,7 @@ static struct shdwc {
> void __iomem *mpddrc_base;
> } at91_shdwc;
>
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
> {
> const char *reason;
> u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
> diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
> index af95c7b39cb3..959ce0dbe91d 100644
> --- a/drivers/power/reset/at91-sama5d2_shdwc.c
> +++ b/drivers/power/reset/at91-sama5d2_shdwc.c
> @@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
> 0, 3, 32, 512, 4096, 32768,
> };
>
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
> {
> struct shdwc *shdw = platform_get_drvdata(pdev);
> const struct reg_config *rcfg = shdw->rcfg;
> --
> 2.39.2
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] power: reset: at91: mark at91_wakeup_status non-__init
@ 2023-12-12 21:50 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-12 21:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexandre Belloni, Justin Stitt, Arnd Bergmann, Yangtao Li,
linux-kernel, linux-pm, Nick Desaulniers, Claudiu Beznea,
Sebastian Reichel, Bill Wendling, llvm, Uwe Kleine-König,
linux-arm-kernel
On Tue, Dec 12, 2023 at 10:46:49PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Two copies of the at91_wakeup_status() function are called by the
> respective probe() callbacks and are marked __init, but the probe
> functions are no longer annotated that way. This works with gcc because
> the functions always get inlined, but clang keeps them separate, which
> can lead to executing freed memory:
>
> WARNING: modpost: vmlinux: section mismatch in reference: at91_poweroff_probe+0x80 (section: .text) -> at91_wakeup_status (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: at91_shdwc_probe+0xcc (section: .text) -> at91_wakeup_status (section: .init.text)
>
> Drop the incorrect annotation on these.
>
> Fixes: 099806de68b7 ("power: reset: at91-poweroff: Stop using module_platform_driver_probe()")
> Fixes: dde74a5de817 ("power: reset: at91-sama5d2_shdwc: Stop using module_platform_driver_probe()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks, I sent the same change three weeks ago at this point:
https://lore.kernel.org/20231120-fix-at91-modpost-warnings-v1-1-813671933863@kernel.org/
Your commit message is a little better than mine and I don't really care
which one goes in but it would be good if this could get cleared up
soon...
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/power/reset/at91-poweroff.c | 2 +-
> drivers/power/reset/at91-sama5d2_shdwc.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/reset/at91-poweroff.c b/drivers/power/reset/at91-poweroff.c
> index 126e774e210c..93eece027865 100644
> --- a/drivers/power/reset/at91-poweroff.c
> +++ b/drivers/power/reset/at91-poweroff.c
> @@ -57,7 +57,7 @@ static struct shdwc {
> void __iomem *mpddrc_base;
> } at91_shdwc;
>
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
> {
> const char *reason;
> u32 reg = readl(at91_shdwc.shdwc_base + AT91_SHDW_SR);
> diff --git a/drivers/power/reset/at91-sama5d2_shdwc.c b/drivers/power/reset/at91-sama5d2_shdwc.c
> index af95c7b39cb3..959ce0dbe91d 100644
> --- a/drivers/power/reset/at91-sama5d2_shdwc.c
> +++ b/drivers/power/reset/at91-sama5d2_shdwc.c
> @@ -107,7 +107,7 @@ static const unsigned long long sdwc_dbc_period[] = {
> 0, 3, 32, 512, 4096, 32768,
> };
>
> -static void __init at91_wakeup_status(struct platform_device *pdev)
> +static void at91_wakeup_status(struct platform_device *pdev)
> {
> struct shdwc *shdw = platform_get_drvdata(pdev);
> const struct reg_config *rcfg = shdw->rcfg;
> --
> 2.39.2
>
>
_______________________________________________
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%]
* 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] docs: rust: remove `CC=clang` mentions
@ 2023-12-18 16:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-18 16:55 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Wedson Almeida Filho, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
rust-for-linux, linux-kernel, patches, Jonathan Corbet,
Nick Desaulniers, Bill Wendling, Justin Stitt, linux-doc, llvm
On Fri, Dec 15, 2023 at 01:47:51PM +0100, Miguel Ojeda wrote:
> Nowadays all architectures except s390 recommend using `LLVM=1` instead of
> `CC=clang`, and since commit a3c6bfba4429 ("Documentation/llvm: refresh
> docs") the Kbuild LLVM documentation makes `LLVM=1` the way to go:
>
> We want to encourage the use of ``LLVM=1`` rather than just
> ``CC=clang``. Make that suggestion "above the fold" and "front and
> center" in our docs.
>
> In particular, that commit removes the examples with `CC=clang`.
>
> Thus do the same in the Rust Quick Start guide, i.e. remove the `CC=clang`
> mentions, especially since the architectures that have had their Rust
> support upstreamed (or soon to be upstreamed) are all `LLVM=1` ones
> anyway. And perhaps by the time Rust is supported for s390 (or new
> architectures), it may have moved to `LLVM=1` anyway. Otherwise,
> this can be added back if needed (or perhaps an extra link to
> Documentation/kbuild/llvm.rst).
>
> This should also help avoiding potential confusion around `CC=clang` [1].
>
> Link: https://lore.kernel.org/rust-for-linux/6df6e8e5-8d5b-4d3d-91b5-bc0e90c424ea@nvidia.com/ [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Yes, the fact that no architecture that CONFIG_RUST supports requires
CC=clang seems reason enough for this to be eliminated from the Rust
documentation.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Documentation/rust/quick-start.rst | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
> index f382914f4191..75faa987079a 100644
> --- a/Documentation/rust/quick-start.rst
> +++ b/Documentation/rust/quick-start.rst
> @@ -76,7 +76,7 @@ libclang
>
> ``libclang`` (part of LLVM) is used by ``bindgen`` to understand the C code
> in the kernel, which means LLVM needs to be installed; like when the kernel
> -is compiled with ``CC=clang`` or ``LLVM=1``.
> +is compiled with ``LLVM=1``.
>
> Linux distributions are likely to have a suitable one available, so it is
> best to check that first.
> @@ -229,10 +229,6 @@ at the moment. That is::
>
> make LLVM=1
>
> -For architectures that do not support a full LLVM toolchain, use::
> -
> - make CC=clang
> -
> Using GCC also works for some configurations, but it is very experimental at
> the moment.
>
>
> base-commit: a39b6ac3781d46ba18193c9dbb2110f31e9bffe9
> --
> 2.43.0
>
^ permalink raw reply [relevance 99%]
* Re: [drm-xe:drm-xe-next 989/1016] drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken
@ 2023-12-18 18:57 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-18 18:57 UTC (permalink / raw)
To: kernel test robot
Cc: Rodrigo Vivi, llvm, Lucas De Marchi, intel-xe, oe-kbuild-all
On Sun, Dec 17, 2023 at 03:28:47AM +0800, kernel test robot wrote:
> tree: https://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next
> head: c54005fdd0347a17088e7ff78070a55bf9103bc4
> commit: ad7d86415578e1a5deedb0ceed5c281f7367d66d [989/1016] drm/xe: Enable W=1 warnings by default
> config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20231217/202312170357.KPSinwPs-lkp@intel.com/config)
> compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231217/202312170357.KPSinwPs-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202312170357.KPSinwPs-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> warning: unknown warning option '-Wrestrict' [-Wunknown-warning-option]
> warning: unknown warning option '-Wpacked-not-aligned'; did you mean '-Wpacked-non-pod'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wformat-overflow'; did you mean '-Wshift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wformat-truncation' [-Wunknown-warning-option]
> warning: unknown warning option '-Wstringop-overflow'; did you mean '-Wshift-overflow'? [-Wunknown-warning-option]
> warning: unknown warning option '-Wstringop-truncation'; did you mean '-Wstring-concatenation'? [-Wunknown-warning-option]
I am not sure why these warnings are even showing up in the first place,
they are wrapped with cc-option, which should be catching that they are
not supported... Is 0day doing something funky with KCFLAGS?
Regardless...
> >> drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
> default:
> ^~~~~~~
> drivers/gpu/drm/xe/xe_wait_user_fence.c:50:9: note: uninitialized use occurs here
> return passed ? 0 : 1;
> ^~~~~~
> drivers/gpu/drm/xe/xe_wait_user_fence.c:21:13: note: initialize the variable 'passed' to silence this warning
> bool passed;
> ^
> = 0
> 7 warnings generated.
I was surprised that this was not caught sooner as
-Wsometimes-uninitialized is a part of -Wall but it looks like
drivers/gpu/drm/xe/Makefile was forked from the i915 Makefile before
commit 43192617f781 ("drm/i915: Enable -Wsometimes-uninitialized") was
added. It is good to see that the warnings are aligned now so that
trivial uninitialized warnings can be caught by clang because they are
disabled for GCC since commit 78a5255ffb6a ("Stop the ad-hoc games with
-Wno-maybe-initialized") in 5.7. Will this be fixed as a separate patch?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH iwl-next] i40e: Avoid unnecessary use of comma operator
@ 2023-12-18 19:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-18 19:00 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Simon Horman, Jesse Brandeburg, Tony Nguyen, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Bill Wendling,
Justin Stitt, intel-wired-lan, netdev, llvm
On Mon, Dec 18, 2023 at 08:32:28AM -0800, Nick Desaulniers wrote:
> On Sun, Dec 17, 2023 at 1:45 AM Simon Horman <horms@kernel.org> wrote:
> >
> > Although it does not seem to have any untoward side-effects,
> > the use of ';' to separate to assignments seems more appropriate than ','.
> >
> > Flagged by clang-17 -Wcomma
>
> Yikes! This kind of example is why I hate the comma operator!
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> (Is -Wcomma enabled by -Wall?)
No and last time that I looked into enabling it, there were a lot of
instances in the kernel:
https://lore.kernel.org/20230630192825.GA2745548@dev-arch.thelio-3990X/
It is still probably worth pursuing at some point but that is a lot of
instances to clean up (along with potentially having a decent amount of
pushback depending on the changes necessary to eliminate all instances).
> Is there a fixes tag we can add?
>
> >
> > No functional change intended.
> > Compile tested only.
> >
> > Signed-off-by: Simon Horman <horms@kernel.org>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > index 812d04747bd0..f542f2671957 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > @@ -1917,7 +1917,7 @@ int i40e_get_eeprom(struct net_device *netdev,
> > len = eeprom->len - (I40E_NVM_SECTOR_SIZE * i);
> > last = true;
> > }
> > - offset = eeprom->offset + (I40E_NVM_SECTOR_SIZE * i),
> > + offset = eeprom->offset + (I40E_NVM_SECTOR_SIZE * i);
> > ret_val = i40e_aq_read_nvm(hw, 0x0, offset, len,
> > (u8 *)eeprom_buff + (I40E_NVM_SECTOR_SIZE * i),
> > last, NULL);
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
^ permalink raw reply [relevance 99%]
* Re: [Intel-wired-lan] [PATCH iwl-next] i40e: Avoid unnecessary use of comma operator
@ 2023-12-18 19:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-18 19:00 UTC (permalink / raw)
To: Nick Desaulniers
Cc: intel-wired-lan, llvm, Jesse Brandeburg, Eric Dumazet, netdev,
Tony Nguyen, Bill Wendling, Simon Horman, Justin Stitt,
Jakub Kicinski, Paolo Abeni, David S. Miller
On Mon, Dec 18, 2023 at 08:32:28AM -0800, Nick Desaulniers wrote:
> On Sun, Dec 17, 2023 at 1:45 AM Simon Horman <horms@kernel.org> wrote:
> >
> > Although it does not seem to have any untoward side-effects,
> > the use of ';' to separate to assignments seems more appropriate than ','.
> >
> > Flagged by clang-17 -Wcomma
>
> Yikes! This kind of example is why I hate the comma operator!
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> (Is -Wcomma enabled by -Wall?)
No and last time that I looked into enabling it, there were a lot of
instances in the kernel:
https://lore.kernel.org/20230630192825.GA2745548@dev-arch.thelio-3990X/
It is still probably worth pursuing at some point but that is a lot of
instances to clean up (along with potentially having a decent amount of
pushback depending on the changes necessary to eliminate all instances).
> Is there a fixes tag we can add?
>
> >
> > No functional change intended.
> > Compile tested only.
> >
> > Signed-off-by: Simon Horman <horms@kernel.org>
> > ---
> > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > index 812d04747bd0..f542f2671957 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> > @@ -1917,7 +1917,7 @@ int i40e_get_eeprom(struct net_device *netdev,
> > len = eeprom->len - (I40E_NVM_SECTOR_SIZE * i);
> > last = true;
> > }
> > - offset = eeprom->offset + (I40E_NVM_SECTOR_SIZE * i),
> > + offset = eeprom->offset + (I40E_NVM_SECTOR_SIZE * i);
> > ret_val = i40e_aq_read_nvm(hw, 0x0, offset, len,
> > (u8 *)eeprom_buff + (I40E_NVM_SECTOR_SIZE * i),
> > last, NULL);
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 15/50] kernel/numa.c: Move logging out of numa.h
@ 2023-12-19 16:36 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-19 16:36 UTC (permalink / raw)
To: Kent Overstreet
Cc: linux-kernel, linux-mm, linux-fsdevel, tglx, x86, tj, peterz,
mathieu.desnoyers, paulmck, keescook, dave.hansen, mingo, will,
longman, boqun.feng, brauner
On Fri, Dec 15, 2023 at 10:26:14PM -0500, Kent Overstreet wrote:
> Moving these stub functions to a .c file means we can kill a sched.h
> dependency on printk.h.
>
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
> ---
> include/linux/numa.h | 18 +++++-------------
> kernel/Makefile | 1 +
> kernel/numa.c | 24 ++++++++++++++++++++++++
> 3 files changed, 30 insertions(+), 13 deletions(-)
> create mode 100644 kernel/numa.c
>
> diff --git a/include/linux/numa.h b/include/linux/numa.h
> index a904861de800..aeab3d9f57ae 100644
> --- a/include/linux/numa.h
> +++ b/include/linux/numa.h
> @@ -22,34 +22,26 @@
> #endif
>
> #ifdef CONFIG_NUMA
> -#include <linux/printk.h>
> #include <asm/sparsemem.h>
>
> /* Generic implementation available */
> int numa_nearest_node(int node, unsigned int state);
>
> #ifndef memory_add_physaddr_to_nid
> -static inline int memory_add_physaddr_to_nid(u64 start)
> -{
> - pr_info_once("Unknown online node for memory at 0x%llx, assuming node 0\n",
> - start);
> - return 0;
> -}
> +int memory_add_physaddr_to_nid(u64 start);
> #endif
> +
> #ifndef phys_to_target_node
> -static inline int phys_to_target_node(u64 start)
> -{
> - pr_info_once("Unknown target node for memory at 0x%llx, assuming node 0\n",
> - start);
> - return 0;
> -}
> +int phys_to_target_node(u64 start);
> #endif
> +
> #ifndef numa_fill_memblks
> static inline int __init numa_fill_memblks(u64 start, u64 end)
> {
> return NUMA_NO_MEMBLK;
> }
> #endif
> +
> #else /* !CONFIG_NUMA */
> static inline int numa_nearest_node(int node, unsigned int state)
> {
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 3947122d618b..ce105a5558fc 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -114,6 +114,7 @@ obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o
> obj-$(CONFIG_HAVE_STATIC_CALL) += static_call.o
> obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call_inline.o
> obj-$(CONFIG_CFI_CLANG) += cfi.o
> +obj-$(CONFIG_NUMA) += numa.o
>
> obj-$(CONFIG_PERF_EVENTS) += events/
>
> diff --git a/kernel/numa.c b/kernel/numa.c
> new file mode 100644
> index 000000000000..c24c72f45989
> --- /dev/null
> +++ b/kernel/numa.c
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/printk.h>
> +#include <linux/numa.h>
> +
> +/* Stub functions: */
> +
> +#ifndef memory_add_physaddr_to_nid
> +int memory_add_physaddr_to_nid(u64 start)
> +{
> + pr_info_once("Unknown online node for memory at 0x%llx, assuming node 0\n",
> + start);
> + return 0;
> +}
> +#endif
> +
> +#ifndef phys_to_target_node
> +int phys_to_target_node(u64 start)
> +{
> + pr_info_once("Unknown target node for memory at 0x%llx, assuming node 0\n",
> + start);
> + return 0;
> +}
> +#endif
> --
> 2.43.0
>
These need EXPORT_SYMBOL_GPL() now like the architecture specific
implementations because they are no longer inlined. My arm64 builds fail
with:
ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/acpi/nfit/nfit.ko] undefined!
ERROR: modpost: "phys_to_target_node" [drivers/acpi/nfit/nfit.ko] undefined!
ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/virtio/virtio_mem.ko] undefined!
ERROR: modpost: "phys_to_target_node" [drivers/dax/dax_cxl.ko] undefined!
ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/dax/dax_cxl.ko] undefined!
ERROR: modpost: "phys_to_target_node" [drivers/cxl/cxl_acpi.ko] undefined!
ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/cxl/cxl_pmem.ko] undefined!
ERROR: modpost: "phys_to_target_node" [drivers/cxl/cxl_pmem.ko] undefined!
ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/hv/hv_balloon.ko] undefined!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko
@ 2023-12-19 21:04 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2023-12-19 21:04 UTC (permalink / raw)
To: Nick Desaulniers, Kent Overstreet, kernel test robot
Cc: llvm, oe-kbuild-all, Brian Cain, linux-hexagon
On Tue, Dec 19, 2023 at 12:58:28PM -0800, Nick Desaulniers wrote:
> On Tue, Dec 19, 2023 at 12:54 PM Kent Overstreet
> <kent.overstreet@linux.dev> wrote:
> >
> > On Tue, Dec 19, 2023 at 09:40:09PM +0800, kernel test robot wrote:
> > > tree: https://evilpiepirate.org/git/bcachefs.git header_cleanup
> > > head: 89188fceb7a49e3c4b0578d86f6f6e647f202821
> > > commit: 1db61740aeb7d6b1c7bfb2a98708a65a6679d068 [21/51] locking/seqlock: Split out seqlock_types.h
> > > config: hexagon-randconfig-r005-20220913 (https://download.01.org/0day-ci/archive/20231219/202312192107.wMIKiZWw-lkp@intel.com/config)
> > > compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231219/202312192107.wMIKiZWw-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202312192107.wMIKiZWw-lkp@intel.com/
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > die__process_unit: DW_TAG_member (0xd) @ <0xc689> not handled!
> > > die__process_unit: tag not supported 0xd (member)!
> > > die__process_function: DW_TAG_compile_unit (0x11) @ <0xc697> not handled!
> > > die__process_function: tag not supported 0x11 (compile_unit)!
> > > die__process_function: DW_TAG_member (0xd) @ <0xc6db> not handled!
> > > die__process_function: DW_TAG_compile_unit (0x11) @ <0xc6e5> not handled!
> > > die__process_class: DW_TAG_compile_unit (0x11) @ <0xc778> not handled!
> > > namespace__recode_dwarf_types: couldn't find 0xc689 type for 0xc66b (member)!
> > > namespace__recode_dwarf_types: couldn't find 0xc638 type for 0xc674 (member)!
> > > namespace__recode_dwarf_types: couldn't find 0xc638 type for 0xc67e (member)!
> > > >> /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko
> >
> > Not sure how likely a header cleanup is to cause a segfault in
> > llvm-objcopy and I don't have the toolchain to repro this - could
> > hexagon people take a look?
For what it's worth in case you were not aware, I provide copies of LLVM
on kernel.org that can be installed in some prefix and invoked with
LLVM=<prefix>/bin/, which can make reproducing reports such as these
relatively easy.
https://mirrors.edge.kernel.org/pub/tools/llvm/
> Is it a segfault in llvm-objcopy, or pahole?
Should be pahole. I have not been able to reproduce these crashes in
pahole v1.25 in the past when they come up every so often. 0day folks,
what version of pahole are you testing with?
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%]
* [PATCH 0/2] dmaengine: xilinx: xdma: Fix two clang warnings
@ 2023-12-22 18:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-22 18:06 UTC (permalink / raw)
To: lizhi.hou, brian.xu, raj.kumar.rampelli, vkoul, jankul
Cc: dmaengine, linux-arm-kernel, llvm, patches, Nathan Chancellor
Hi all,
This series fixes two clang warnings that I see after
commit 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA
transfers"). They have just been build tested but I think the logic is
sound, please double check though.
---
Nathan Chancellor (2):
dmaengine: xilinx: xdma: Fix operator precedence in xdma_prep_interleaved_dma()
dmaengine: xilinx: xdma: Fix initialization location of desc in xdma_channel_isr()
drivers/dma/xilinx/xdma.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 3d0b2176e04261ab4ac095ff2a17db077fc1e46d
change-id: 20231222-dma-xilinx-xdma-clang-fixes-b9c2c3f5d0f3
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply [relevance 99%]
* [PATCH 0/2] platform/x86/intel/pmc: Fix recent instances of -Wmissing-prototypes
@ 2023-12-22 18:27 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-22 18:27 UTC (permalink / raw)
To: irenic.rajneesh, david.e.box, hdegoede, ilpo.jarvinen, rajvi.jingar
Cc: platform-driver-x86, patches, Stephen Rothwell, Nathan Chancellor
As reported by Stephen at [1], there are a few instances of
-Wmissing-prototypes, which break the build with CONFIG_WERROR=y. This
series marks these functions as static because they are not used outside
of these translation units.
Feel free to squash these into the original changes if the branch is not
set in stone.
[1]: https://lore.kernel.org/all/20231222135412.6bd796cc@canb.auug.org.au/
---
Nathan Chancellor (2):
platform/x86/intel/pmc: Mark arl_d3_fixup() and arl_resume() as static
platform/x86/intel/pmc: Mark lnl_d3_fixup() and lnl_resume() as static
drivers/platform/x86/intel/pmc/arl.c | 4 ++--
drivers/platform/x86/intel/pmc/lnl.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
---
base-commit: 119652b855e6c96676406ee9a7f535f4db4e8eff
change-id: 20231222-intel-pmc-missing-prototypes-8fb5014b16b8
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply [relevance 99%]
* [PATCH 0/2] dmaengine: xilinx: xdma: Fix two clang warnings
@ 2023-12-22 18:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-22 18:06 UTC (permalink / raw)
To: lizhi.hou, brian.xu, raj.kumar.rampelli, vkoul, jankul
Cc: dmaengine, linux-arm-kernel, llvm, patches, Nathan Chancellor
Hi all,
This series fixes two clang warnings that I see after
commit 2f8f90cd2f8d ("dmaengine: xilinx: xdma: Implement interleaved DMA
transfers"). They have just been build tested but I think the logic is
sound, please double check though.
---
Nathan Chancellor (2):
dmaengine: xilinx: xdma: Fix operator precedence in xdma_prep_interleaved_dma()
dmaengine: xilinx: xdma: Fix initialization location of desc in xdma_channel_isr()
drivers/dma/xilinx/xdma.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
---
base-commit: 3d0b2176e04261ab4ac095ff2a17db077fc1e46d
change-id: 20231222-dma-xilinx-xdma-clang-fixes-b9c2c3f5d0f3
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
_______________________________________________
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: [PATCH] scripts/decode_stacktrace.sh: Support LLVM addr2line
@ 2023-12-26 16:38 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-26 16:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Nick Desaulniers, Bill Wendling, Justin Stitt, Andrew Morton,
linux-arm-msm, linux-kernel, llvm
On Mon, Dec 25, 2023 at 10:52:57AM -0800, Bjorn Andersson wrote:
> The kernel build system adhere to the LLVM environment variable, to
> select building the kernel using clang/llvm. In combination with the
> ARCH environment variable the kernel can be cross-compiled without the
> user specifying the CROSS_COMPILE variable.
>
> The LLVM environment variable is used to specify the suffix of the llvm
> executables (such as LLVM=-12 for llvm-addr2line-12), or to omit the
> suffix when set to "1" (e.g. llvm-addr2line).
>
> decode_stacktrace.sh allows invoking a specific addr2line executable by
> prefixing the command with CROSS_COMPILE. At best allows the user to
> trick decode_stacktrace.sh into invoking llvm-addr2line, and it does not
> support specifying an alternative version based on the suffix.
>
> Teach decode_stacktrace.sh about the two cases of the LLVM environment
> variable, and use this to determine which addr2line to use. The current
> behavior is maintained when the LLVM variable is not set.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Hmmm, this is the second patch to decode_stacktrace.sh in the same
number of weeks...
https://lore.kernel.org/20231215-llvm-decode-stacktrace-v1-1-201cb86f4879@quicinc.com/
Nick pointed out on that one that Carlos's patch from some time ago was
even better at using all LLVM tools and requested testing/review on that
one.
https://lore.kernel.org/20230929034836.403735-1-cmllamas@google.com/
Furthermore, this patch does not handle the LLVM=<prefix>/bin/ syntax
that we support, which I personally use all the time.
Cheers,
Nathan
> ---
> scripts/decode_stacktrace.sh | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/decode_stacktrace.sh b/scripts/decode_stacktrace.sh
> index 564c5632e1a2..adf1d64477a1 100755
> --- a/scripts/decode_stacktrace.sh
> +++ b/scripts/decode_stacktrace.sh
> @@ -16,6 +16,13 @@ elif type c++filt >/dev/null 2>&1 ; then
> cppfilt_opts=-i
> fi
>
> +# Determine which addr2line to use
> +case "$LLVM" in
> + "" ) addr2line="${CROSS_COMPILE}addr2line";;
> + "1" ) addr2line="llvm-addr2line";;
> + * ) addr2line="llvm-addr2line${LLVM}";;
> +esac
> +
> if [[ $1 == "-r" ]] ; then
> vmlinux=""
> basepath="auto"
> @@ -169,7 +176,7 @@ parse_symbol() {
> if [[ $aarray_support == true && "${cache[$module,$address]+isset}" == "isset" ]]; then
> local code=${cache[$module,$address]}
> else
> - local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile" "$address" 2>/dev/null)
> + local code=$(${addr2line} -i -e "$objfile" "$address" 2>/dev/null)
> if [[ $aarray_support == true ]]; then
> cache[$module,$address]=$code
> fi
>
> ---
> base-commit: 39676dfe52331dba909c617f213fdb21015c8d10
> change-id: 20231225-decode-stacktrace-llvm-f260a1614361
>
> Best regards,
> --
> Bjorn Andersson <quic_bjorande@quicinc.com>
>
>
^ permalink raw reply [relevance 99%]
* Re: [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko
@ 2023-12-28 17:34 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2023-12-28 17:34 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Yujie Liu, Nick Desaulniers, Kent Overstreet, kernel test robot,
llvm, oe-kbuild-all, Brian Cain, linux-hexagon, dwarves
On Thu, Dec 28, 2023 at 11:21:06AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 27, 2023 at 03:43:38PM -0700, Nathan Chancellor escreveu:
> > + Arnaldo and dwarves list
> >
> > On Wed, Dec 20, 2023 at 03:24:54PM +0800, Yujie Liu wrote:
> > > On Tue, Dec 19, 2023 at 02:04:54PM -0700, Nathan Chancellor wrote:
> > > > On Tue, Dec 19, 2023 at 12:58:28PM -0800, Nick Desaulniers wrote:
> > > > > On Tue, Dec 19, 2023 at 12:54 PM Kent Overstreet
> > > > > <kent.overstreet@linux.dev> wrote:
> > > > > >
> > > > > > On Tue, Dec 19, 2023 at 09:40:09PM +0800, kernel test robot wrote:
> > > > > > > tree: https://evilpiepirate.org/git/bcachefs.git header_cleanup
> > > > > > > head: 89188fceb7a49e3c4b0578d86f6f6e647f202821
> > > > > > > commit: 1db61740aeb7d6b1c7bfb2a98708a65a6679d068 [21/51] locking/seqlock: Split out seqlock_types.h
> > > > > > > config: hexagon-randconfig-r005-20220913 (https://download.01.org/0day-ci/archive/20231219/202312192107.wMIKiZWw-lkp@intel.com/config)
> > > > > > > compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git ae42196bc493ffe877a7e3dff8be32035dea4d07)
> > > > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231219/202312192107.wMIKiZWw-lkp@intel.com/reproduce)
> > > > > > >
> > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > > > the same patch/commit), kindly add following tags
> > > > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202312192107.wMIKiZWw-lkp@intel.com/
> > > > > > >
> > > > > > > All errors (new ones prefixed by >>):
> > > > > > >
> > > > > > > die__process_unit: DW_TAG_member (0xd) @ <0xc689> not handled!
> > > > > > > die__process_unit: tag not supported 0xd (member)!
> > > > > > > die__process_function: DW_TAG_compile_unit (0x11) @ <0xc697> not handled!
> > > > > > > die__process_function: tag not supported 0x11 (compile_unit)!
> > > > > > > die__process_function: DW_TAG_member (0xd) @ <0xc6db> not handled!
> > > > > > > die__process_function: DW_TAG_compile_unit (0x11) @ <0xc6e5> not handled!
> > > > > > > die__process_class: DW_TAG_compile_unit (0x11) @ <0xc778> not handled!
> > > > > > > namespace__recode_dwarf_types: couldn't find 0xc689 type for 0xc66b (member)!
> > > > > > > namespace__recode_dwarf_types: couldn't find 0xc638 type for 0xc674 (member)!
> > > > > > > namespace__recode_dwarf_types: couldn't find 0xc638 type for 0xc67e (member)!
> > > > > > > >> /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko
> > > > > >
> > > > > > Not sure how likely a header cleanup is to cause a segfault in
> > > > > > llvm-objcopy and I don't have the toolchain to repro this - could
> > > > > > hexagon people take a look?
> > > >
> > > > For what it's worth in case you were not aware, I provide copies of LLVM
> > > > on kernel.org that can be installed in some prefix and invoked with
> > > > LLVM=<prefix>/bin/, which can make reproducing reports such as these
> > > > relatively easy.
> > > >
> > > > https://mirrors.edge.kernel.org/pub/tools/llvm/
> > > >
> > > > > Is it a segfault in llvm-objcopy, or pahole?
> > > >
> > > > Should be pahole. I have not been able to reproduce these crashes in
> > > > pahole v1.25 in the past when they come up every so often. 0day folks,
> > > > what version of pahole are you testing with?
> > >
> > > We clone pahole source code from [1] and build it on the master branch.
> > > The current head is commit c129fa757948 which is newer than v1.25.
> > >
> > > c129fa757948 ("pahole: Add --btf_features_strict to reject unknown BTF features")
> > >
> > > [1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> >
> > Thanks for that additional information but I can reproduce this at v1.25
> > as well, I just tried:
> >
> > $ git fetch https://evilpiepirate.org/git/bcachefs.git 1db61740aeb7d6b1c7bfb2a98708a65a6679d068
> > $ git reset --hard FETCH_HEAD
> > $ curl -LSso .config https://download.01.org/0day-ci/archive/20231219/202312192107.wMIKiZWw-lkp@intel.com/config
> > $ curl -LSs https://mirrors.edge.kernel.org/pub/tools/llvm/files/llvm-16.0.6-x86_64.tar.xz | tar -xJf -
> > $ make -skj"$(nproc)" ARCH=hexagon LLVM=$PWD/llvm-16.0.6-x86_64/bin/ olddefconfig all
> > ...
> > die__process: got compile_unit unexpected tag after DW_TAG_compile_unit!
> > die__create_new_enumeration: DW_TAG_array_type (0x1) @ <0x120b1> not handled!
> > die__create_new_enumeration: DW_TAG_pointer_type (0xf) @ <0x120b7> not handled!
> > die__process_unit: DW_TAG_member (0xd) @ <0x3669> not handled!
> > die__process_unit: tag not supported 0xd (member)!
> > die__process: got compile_unit unexpected tag after DW_TAG_compile_unit!
> > die__process_unit: DW_TAG_member (0xd) @ <0x3650> not handled!
> > die__process_unit: tag not supported 0xd (member)!
> > die__process: got compile_unit unexpected tag after DW_TAG_compile_unit!
> > die__create_new_enumeration: DW_TAG_array_type (0x1) @ <0x9cb5> not handled!
> > die__create_new_enumeration: DW_TAG_pointer_type (0xf) @ <0x9cbb> not handled!
> > die__process_unit: DW_TAG_enumerator (0x28) @ <0x705a> not handled!
> > die__process_unit: tag not supported 0x28 (enumerator)!
> > ...
> >
> > I do not get a segfault personally but there are definitely a lot of
> > errors from pahole at the end. Arnaldo, is pahole not handling something
> > that it should with regards to clang's debug info?
>
> Possibly, would it be possible to provide the vmlinux file where pahole
> is segfaulting when trying to encode BTF from DWARF?
>
> These two files:
>
> vmlinux drivers/misc/eeprom/at24.ko
>
> So that I can run:
>
> LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko
>
> Here.
Sure, here you go:
https://1drv.ms/u/s!AsQNYeB-IEbqqAilUuGHOU8BMLbf
If you need more objects, just let me know. That series of commands in
the previous email should also get them for you locally if you need all
of them or want to investigate more.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] drm/xe: Fix warning on impossible condition
@ 2024-01-03 16:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-03 16:07 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: intel-xe, Rodrigo Vivi, llvm
On Mon, Dec 18, 2023 at 08:33:01AM -0800, Lucas De Marchi wrote:
> Having a different value for op is not possible: this is already kept
> out of user-visible warning by the check in xe_wait_user_fence_ioctl()
> if op > MAX_OP. The warning is useful as if this switch() is not update
> when a new op is added, it should be triggered.
>
> Fix warning as reported by 0-DAY CI Kernel:
>
> drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312170357.KPSinwPs-lkp@intel.com/
> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I am now seeing this warning in -next, can this be applied as a fix so
that our builds are not broken?
> ---
> drivers/gpu/drm/xe/xe_wait_user_fence.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_wait_user_fence.c b/drivers/gpu/drm/xe/xe_wait_user_fence.c
> index b0a7896f7fcb..a75eeba7bfe5 100644
> --- a/drivers/gpu/drm/xe/xe_wait_user_fence.c
> +++ b/drivers/gpu/drm/xe/xe_wait_user_fence.c
> @@ -46,6 +46,7 @@ static int do_compare(u64 addr, u64 value, u64 mask, u16 op)
> break;
> default:
> XE_WARN_ON("Not possible");
> + return -EINVAL;
> }
>
> return passed ? 0 : 1;
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] drm/xe: Fix warning on impossible condition
@ 2024-01-03 16:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-03 16:07 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: llvm, intel-xe, Rodrigo Vivi
On Mon, Dec 18, 2023 at 08:33:01AM -0800, Lucas De Marchi wrote:
> Having a different value for op is not possible: this is already kept
> out of user-visible warning by the check in xe_wait_user_fence_ioctl()
> if op > MAX_OP. The warning is useful as if this switch() is not update
> when a new op is added, it should be triggered.
>
> Fix warning as reported by 0-DAY CI Kernel:
>
> drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
>
> Closes: https://lore.kernel.org/oe-kbuild-all/202312170357.KPSinwPs-lkp@intel.com/
> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I am now seeing this warning in -next, can this be applied as a fix so
that our builds are not broken?
> ---
> drivers/gpu/drm/xe/xe_wait_user_fence.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_wait_user_fence.c b/drivers/gpu/drm/xe/xe_wait_user_fence.c
> index b0a7896f7fcb..a75eeba7bfe5 100644
> --- a/drivers/gpu/drm/xe/xe_wait_user_fence.c
> +++ b/drivers/gpu/drm/xe/xe_wait_user_fence.c
> @@ -46,6 +46,7 @@ static int do_compare(u64 addr, u64 value, u64 mask, u16 op)
> break;
> default:
> XE_WARN_ON("Not possible");
> + return -EINVAL;
> }
>
> return passed ? 0 : 1;
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump
@ 2024-01-03 18:15 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-03 18:15 UTC (permalink / raw)
To: tglx, mingo, bp, dave.hansen, x86; +Cc: mhiramat, linux-kernel, llvm, patches
Ping? I am still seeing this issue.
On Tue, Dec 05, 2023 at 12:53:08PM -0700, Nathan Chancellor wrote:
> When running the instruction decoder selftest with LLVM=1 +
> CONFIG_PVH=y, there is a series of warnings:
>
> arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this.
> arch/x86/tools/insn_decoder_test: warning: ffffffff81000050 ea <unknown>
> arch/x86/tools/insn_decoder_test: warning: objdump says 1 bytes, but insn_get_length() says 7
> arch/x86/tools/insn_decoder_test: warning: Decoded and checked 7214721 instructions with 1 failures
>
> GNU objdump outputs "(bad)" instead of "<unknown>", which is already
> handled in the bad_expr regex, so there is no warning.
>
> $ objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea'
> 50: ea (bad)
>
> $ llvm-objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea'
> 50: ea <unknown>
>
> Add "<unknown>" to the bad_expr regex to clear up the warning, allowing
> the instruction decoder selftest to fully pass with llvm-objdump.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/x86/tools/objdump_reformat.awk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/tools/objdump_reformat.awk b/arch/x86/tools/objdump_reformat.awk
> index a4120d907277..20b08a6c4d33 100644
> --- a/arch/x86/tools/objdump_reformat.awk
> +++ b/arch/x86/tools/objdump_reformat.awk
> @@ -11,7 +11,7 @@ BEGIN {
> prev_addr = ""
> prev_hex = ""
> prev_mnemonic = ""
> - bad_expr = "(\\(bad\\)|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))"
> + bad_expr = "(\\(bad\\)|<unknown>|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))"
> fwait_expr = "^9b[ \t]*fwait"
> fwait_str="9b\tfwait"
> }
>
> ---
> base-commit: 5225952d74d43e4c054731c74b8afd700b23a94a
> change-id: 20231205-objdump_reformat-awk-handle-llvm-objdump-bad_expr-9e74cd2a08b5
>
> Best regards,
> --
> Nathan Chancellor <nathan@kernel.org>
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump
@ 2024-01-03 20:55 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-03 20:55 UTC (permalink / raw)
To: Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, mhiramat, linux-kernel, llvm, patches
On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote:
> On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote:
> > Ping? I am still seeing this issue.
>
> Does this need a Fixes tag and needs to go to Linus now or are you fine
> with 6.8-rc0?
This is only needed due to the recent changes from Sam and myself in
x86/build, so no need to rush it to Linus. I just wanted to make sure it
was not lost before the chaos of the merge window.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump
@ 2024-01-03 21:48 99% ` Nathan Chancellor
2024-01-03 21:51 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-03 21:48 UTC (permalink / raw)
To: Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, mhiramat, linux-kernel, llvm, patches
On Wed, Jan 03, 2024 at 10:26:16PM +0100, Borislav Petkov wrote:
> On Wed, Jan 03, 2024 at 01:55:06PM -0700, Nathan Chancellor wrote:
> > On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote:
> > > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote:
> > > > Ping? I am still seeing this issue.
> > >
> > > Does this need a Fixes tag and needs to go to Linus now or are you fine
> > > with 6.8-rc0?
> >
> > This is only needed due to the recent changes from Sam and myself in
> > x86/build
>
> I don't understand: those three commits seem unrelated to LLVM objdump
> outputting "<unknown>".
>
> Or are you saying that you've *started* running the insn decoder selftest
> with llvm's objdump and those three commits are addressing differences
> in the output and this outstanding commit is needed too for the bad
> opcode case?
Prior to commit 5225952d74d4 ("x86/tools: Remove chkobjdump.awk"), the
insn decoder selftest would not actually run with llvm-objdump
altogether because chkobjdump.awk would fail (because it was only
written for GNU objdump). The two commits prior to 5225952d74d4 were
cleaning up differences between the output of each objdump
implementations and this change should have been a part of that work as
well, I just did not build enough configurations to see it. Hopefully
that clears things up.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump
2024-01-03 21:48 99% ` Nathan Chancellor
@ 2024-01-03 21:51 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-03 21:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: tglx, mingo, dave.hansen, x86, mhiramat, linux-kernel, llvm, patches
On Wed, Jan 03, 2024 at 02:48:09PM -0700, Nathan Chancellor wrote:
> On Wed, Jan 03, 2024 at 10:26:16PM +0100, Borislav Petkov wrote:
> > On Wed, Jan 03, 2024 at 01:55:06PM -0700, Nathan Chancellor wrote:
> > > On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote:
> > > > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote:
> > > > > Ping? I am still seeing this issue.
> > > >
> > > > Does this need a Fixes tag and needs to go to Linus now or are you fine
> > > > with 6.8-rc0?
> > >
> > > This is only needed due to the recent changes from Sam and myself in
> > > x86/build
> >
> > I don't understand: those three commits seem unrelated to LLVM objdump
> > outputting "<unknown>".
> >
> > Or are you saying that you've *started* running the insn decoder selftest
> > with llvm's objdump and those three commits are addressing differences
> > in the output and this outstanding commit is needed too for the bad
> > opcode case?
>
> Prior to commit 5225952d74d4 ("x86/tools: Remove chkobjdump.awk"), the
> insn decoder selftest would not actually run with llvm-objdump
> altogether because chkobjdump.awk would fail (because it was only
> written for GNU objdump). The two commits prior to 5225952d74d4 were
> cleaning up differences between the output of each objdump
> implementations and this change should have been a part of that work as
> well, I just did not build enough configurations to see it. Hopefully
> that clears things up.
For the record, this explanation really should have been in the commit
message of 5225952d74d4 but I guess I was not thinking at the time.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] scripts/min-tool-version.sh: Raise min clang version to 18.0.0 for loongarch
@ 2024-01-08 16:37 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-08 16:37 UTC (permalink / raw)
To: WANG Rui
Cc: Huacai Chen, WANG Xuerui, llvm, linux-kernel, loongarch,
loongson-kernel, Tiezhu Yang
On Mon, Jan 08, 2024 at 11:31:38AM +0800, WANG Rui wrote:
> The existing mainline clang development version encounters diffculties
> compiling the LoongArch kernel module. It is anticipated that this issue
> will be resolved in the upcoming 18.0.0 release. To prevent user
> confusion arising from broken builds, it is advisable to raise the
> minimum required clang version for LoongArch to 18.0.0.
>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> Signed-off-by: WANG Rui <wangrui@loongson.cn>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Thanks a lot for all the work driving getting everything to work
properly with LLVM!
> ---
> scripts/min-tool-version.sh | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
> index c62066825f53..9faa4d3d91e3 100755
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -26,6 +26,8 @@ gcc)
> llvm)
> if [ "$SRCARCH" = s390 ]; then
> echo 15.0.0
> + elif [ "$SRCARCH" = loongarch ]; then
> + echo 18.0.0
> else
> echo 11.0.0
> fi
> --
> 2.43.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] platform/x86: intel-uncore-freq: Fix types in sysfs callbacks
@ 2024-01-08 16:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-08 16:47 UTC (permalink / raw)
To: srinivas pandruvada
Cc: hdegoede, ilpo.jarvinen, keescook, samitolvanen,
platform-driver-x86, llvm, patches
On Sun, Jan 07, 2024 at 11:25:53PM -0800, srinivas pandruvada wrote:
> On Thu, 2024-01-04 at 15:59 -0700, Nathan Chancellor wrote:
> > 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")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Do you need Cc: stable@vger.kernel.org
Yes, I think we do, and I see Hans graciously added that for me during
application. Thanks for taking a look!
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> > ---
> > I think I got the fixes tag right. I only started seeing this because
> > of
> > commit 27f2b08735c9 ("platform/x86: intel-uncore-freq: Add additional
> > client processors"), which allows this driver to load on my i7-11700
> > test system but I think the commit in the Fixes tag incorrectly
> > changes
> > the types of the callbacks.
> > ---
> > .../uncore-frequency/uncore-frequency-common.c | 82 +++++++++++-
> > ----------
> > .../uncore-frequency/uncore-frequency-common.h | 32 ++++-----
> > 2 files changed, 57 insertions(+), 57 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 33ab207493e3..33bb58dc3f78 100644
> > --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-
> > common.c
> > +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-
> > common.c
> > @@ -23,23 +23,23 @@ static int (*uncore_read)(struct uncore_data
> > *data, unsigned int *min, unsigned
> > static int (*uncore_write)(struct uncore_data *data, unsigned int
> > input, unsigned int min_max);
> > static int (*uncore_read_freq)(struct uncore_data *data, unsigned
> > int *freq);
> >
> > -static ssize_t show_domain_id(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > +static ssize_t show_domain_id(struct kobject *kobj, struct
> > kobj_attribute *attr, char *buf)
> > {
> > - struct uncore_data *data = container_of(attr, struct
> > uncore_data, domain_id_dev_attr);
> > + struct uncore_data *data = container_of(attr, struct
> > uncore_data, domain_id_kobj_attr);
> >
> > return sprintf(buf, "%u\n", data->domain_id);
> > }
> >
> > -static ssize_t show_fabric_cluster_id(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > +static ssize_t show_fabric_cluster_id(struct kobject *kobj, struct
> > kobj_attribute *attr, char *buf)
> > {
> > - struct uncore_data *data = container_of(attr, struct
> > uncore_data, fabric_cluster_id_dev_attr);
> > + struct uncore_data *data = container_of(attr, struct
> > uncore_data, fabric_cluster_id_kobj_attr);
> >
> > return sprintf(buf, "%u\n", data->cluster_id);
> > }
> >
> > -static ssize_t show_package_id(struct device *dev, struct
> > device_attribute *attr, char *buf)
> > +static ssize_t show_package_id(struct kobject *kobj, struct
> > kobj_attribute *attr, char *buf)
> > {
> > - struct uncore_data *data = container_of(attr, struct
> > uncore_data, package_id_dev_attr);
> > + struct uncore_data *data = container_of(attr, struct
> > uncore_data, package_id_kobj_attr);
> >
> > return sprintf(buf, "%u\n", data->package_id);
> > }
> > @@ -97,30 +97,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); \
> > }
> > @@ -134,11 +134,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); \
> > @@ -149,29 +149,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)
> > @@ -186,21 +186,21 @@ static int create_attr_group(struct uncore_data
> > *data, char *name)
> >
> > if (data->domain_id != UNCORE_DOMAIN_ID_INVALID) {
> > init_attribute_root_ro(domain_id);
> > - data->uncore_attrs[index++] = &data-
> > >domain_id_dev_attr.attr;
> > + data->uncore_attrs[index++] = &data-
> > >domain_id_kobj_attr.attr;
> > init_attribute_root_ro(fabric_cluster_id);
> > - data->uncore_attrs[index++] = &data-
> > >fabric_cluster_id_dev_attr.attr;
> > + data->uncore_attrs[index++] = &data-
> > >fabric_cluster_id_kobj_attr.attr;
> > init_attribute_root_ro(package_id);
> > - data->uncore_attrs[index++] = &data-
> > >package_id_dev_attr.attr;
> > + data->uncore_attrs[index++] = &data-
> > >package_id_kobj_attr.attr;
> > }
> >
> > - 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 7afb69977c7e..0e5bf507e555 100644
> > --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-
> > common.h
> > +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-
> > common.h
> > @@ -26,14 +26,14 @@
> > * @instance_id: Unique instance id to append to directory
> > name
> > * @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
> > - * @domain_id_dev_attr: Storage for device attribute domain_id
> > - * @fabric_cluster_id_dev_attr: Storage for device attribute
> > fabric_cluster_id
> > - * @package_id_dev_attr: Storage for device attribute package_id
> > + * @max_freq_khz_kobj_attr: Storage for kobject attribute
> > max_freq_khz
> > + * @mix_freq_khz_kobj_attr: Storage for kobject attribute
> > min_freq_khz
> > + * @initial_max_freq_khz_kobj_attr: Storage for kobject attribute
> > initial_max_freq_khz
> > + * @initial_min_freq_khz_kobj_attr: Storage for kobject attribute
> > initial_min_freq_khz
> > + * @current_freq_khz_kobj_attr: Storage for kobject attribute
> > current_freq_khz
> > + * @domain_id_kobj_attr: Storage for kobject attribute domain_id
> > + * @fabric_cluster_id_kobj_attr: Storage for kobject attribute
> > fabric_cluster_id
> > + * @package_id_kobj_attr: Storage for kobject attribute package_id
> > * @uncore_attrs: Attribute storage for group creation
> > *
> > * This structure is used to encapsulate all data related to uncore
> > sysfs
> > @@ -53,14 +53,14 @@ 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 device_attribute domain_id_dev_attr;
> > - struct device_attribute fabric_cluster_id_dev_attr;
> > - struct device_attribute package_id_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 kobj_attribute domain_id_kobj_attr;
> > + struct kobj_attribute fabric_cluster_id_kobj_attr;
> > + struct kobj_attribute package_id_kobj_attr;
> > struct attribute *uncore_attrs[9];
> > };
> >
> >
> > ---
> > base-commit: 236f7d8034ff401d02fa6d74bae494a2b54e1834
> > change-id: 20240104-intel-uncore-freq-kcfi-fix-6ef07053db58
> >
> > Best regards,
>
^ permalink raw reply [relevance 99%]
* 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] Compiler Attributes: counted_by: bump compiler versions
@ 2024-01-09 15:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-09 15:32 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Miguel Ojeda, Kees Cook, Gustavo A . R . Silva, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Tue, Jan 09, 2024 at 10:36:24PM +0900, Sergey Senozhatsky wrote:
> Bump compiler versions, as GCC is expected to implement it
> in version 15 and current clang-18 still has no support for
> counted_by(). Also fix clang URL - the project has moved
> to github.
>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> include/linux/compiler_attributes.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index 28566624f008..1829c24c3357 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -95,11 +95,11 @@
> #endif
>
> /*
> - * Optional: only supported since gcc >= 14
> - * Optional: only supported since clang >= 18
> + * Optional: only supported since gcc >= 15
> + * Optional: only supported since clang >= 19
It is still possible in theory for this feature to make clang-18, as the
release/18.x branch is not scheduled to be cut until the fourth Tuesday
in January, which is two weeks from now. I don't have a good feeling for
how close that pull request is to being mergeable though, so this is
fine for now. I assume this won't go to Linus immediately so we would
have time to change it if necessary.
The link change is obviously good.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I should probably go through and try to update all the other
review.llvm.org links to GitHub as well...
> *
> * gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> - * clang: https://reviews.llvm.org/D148381
> + * clang: https://github.com/llvm/llvm-project/pull/76348
> */
> #if __has_attribute(__counted_by__)
> # define __counted_by(member) __attribute__((__counted_by__(member)))
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCHv2 1/2] Compiler Attributes: counted_by: bump min gcc version
@ 2024-01-10 3:01 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-10 3:01 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Miguel Ojeda, Kees Cook, Gustavo A . R . Silva, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Wed, Jan 10, 2024 at 11:58:17AM +0900, Sergey Senozhatsky wrote:
> GCC is expected to implement this feature in version 15,
> so bump the version.
>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> include/linux/compiler_attributes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index 28566624f008..215882a1341a 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -95,7 +95,7 @@
> #endif
>
> /*
> - * Optional: only supported since gcc >= 14
> + * Optional: only supported since gcc >= 15
> * Optional: only supported since clang >= 18
> *
> * gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCHv2 2/2] Compiler Attributes: counted_by: fixup clang URL
@ 2024-01-10 3:02 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-10 3:02 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Miguel Ojeda, Kees Cook, Gustavo A . R . Silva, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kernel, llvm
On Wed, Jan 10, 2024 at 11:58:18AM +0900, Sergey Senozhatsky wrote:
> The URL in question 404 now, fix it up (and switch to github).
>
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I sent a patch series today for the rest of the tree, which includes a
link to what happened here:
https://lore.kernel.org/20240109-update-llvm-links-v1-1-eb09b59db071@kernel.org/
https://lore.kernel.org/20240109-update-llvm-links-v1-2-eb09b59db071@kernel.org/
> ---
> include/linux/compiler_attributes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index 215882a1341a..289810685fc5 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -99,7 +99,7 @@
> * Optional: only supported since clang >= 18
> *
> * gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> - * clang: https://reviews.llvm.org/D148381
> + * clang: https://github.com/llvm/llvm-project/pull/76348
> */
> #if __has_attribute(__counted_by__)
> # define __counted_by(member) __attribute__((__counted_by__(member)))
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/1] Fix a wrong value passed to __find_vmap_area()
@ 2024-01-11 15:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-11 15:55 UTC (permalink / raw)
To: Uladzislau Rezki (Sony)
Cc: linux-mm, Andrew Morton, LKML, Baoquan He, Lorenzo Stoakes,
Christoph Hellwig, Matthew Wilcox, Liam R . Howlett,
Dave Chinner, Oleksiy Avramchenko, kernel test robot
On Thu, Jan 11, 2024 at 01:11:04PM +0100, Uladzislau Rezki (Sony) wrote:
> There was a type in the vmalloc_dump_obj() function. Instead
> of passing a real address which is "objp" an "addr" was used
> what is wrong and not initialized.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Fixes: e88b85b81d5 ("mm: vmalloc: offload free_vmap_area_lock lock")
I am not sure that e88b85b81d5 introduced this. Based on the diff, I
think it was actually commit 86817057732a ("mm: vmalloc: remove global
vmap_area_root rb-tree"). Does not really matter for the patch text but
I think it does matter for what change this gets squashed into.
> Closes: https://lore.kernel.org/oe-kbuild-all/202401111810.TKPIXLCs-lkp@intel.com/
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
> mm/vmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index e30dabf68263..43a6608e1397 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4688,7 +4688,7 @@ bool vmalloc_dump_obj(void *object)
> vn = addr_to_node((unsigned long)objp);
>
> if (spin_trylock(&vn->busy.lock)) {
> - va = __find_vmap_area(addr, &vn->busy.root);
> + va = __find_vmap_area((unsigned long)objp, &vn->busy.root);
>
> if (va && va->vm) {
> addr = (unsigned long)va->vm->addr;
> --
> 2.39.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 2/4] arch/x86: Move internal setup_data structures into setup_data.h
@ 2024-01-11 22:41 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-11 22:41 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: kernel test robot, ardb, tglx, mingo, bp, dave.hansen, x86, hpa,
bhelgaas, arnd, zohar, dmitry.kasatkin, paul, jmorris, serge,
javierm, llvm, oe-kbuild-all, linux-arch, linux-efi,
linux-kernel, linux-pci, linux-integrity, linux-security-module
On Thu, Jan 11, 2024 at 10:50:43AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 09.01.24 um 18:58 schrieb Nathan Chancellor:
> > On Tue, Jan 09, 2024 at 08:28:59AM +0800, kernel test robot wrote:
> > > Hi Thomas,
> > >
> > > kernel test robot noticed the following build warnings:
> > >
> > > [auto build test WARNING on tip/x86/core]
> > > [also build test WARNING on efi/next tip/master tip/auto-latest linus/master v6.7 next-20240108]
> > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > And when submitting patch, we suggest to use '--base' as documented in
> > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > >
> > > url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/arch-x86-Move-UAPI-setup-structures-into-setup_data-h/20240108-180158
> > > base: tip/x86/core
> > > patch link: https://lore.kernel.org/r/20240108095903.8427-3-tzimmermann%40suse.de
> > > patch subject: [PATCH v4 2/4] arch/x86: Move internal setup_data structures into setup_data.h
> > > config: x86_64-rhel-8.3-bpf (https://download.01.org/0day-ci/archive/20240109/202401090800.UOBEKB3W-lkp@intel.com/config)
> > > compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240109/202401090800.UOBEKB3W-lkp@intel.com/reproduce)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202401090800.UOBEKB3W-lkp@intel.com/
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > In file included from arch/x86/realmode/rm/wakemain.c:3:
> > > In file included from arch/x86/boot/boot.h:24:
> > > In file included from arch/x86/include/asm/setup.h:10:
> > > In file included from arch/x86/include/asm/page_types.h:7:
> > > In file included from include/linux/mem_encrypt.h:17:
> > > In file included from arch/x86/include/asm/mem_encrypt.h:18:
> > > In file included from arch/x86/include/uapi/asm/bootparam.h:5:
> > > > > arch/x86/include/asm/setup_data.h:10:20: warning: field 'data' with variable sized type 'struct setup_data' not at the end of a struct or class is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> > > 10 | struct setup_data data;
> > > | ^
> > > 1 warning generated.
> >
> > I think this warning is expected. This structure is now included in the
> > realmode part of arch/x86, which has its own set of build flags,
> > including -Wall, which includes -Wgnu on clang. The kernel obviously
> > uses GNU extensions and states this clearly with '-std=gnu11', so
> > -Wno-gnu is unconditionally added to KBUILD_CFLAGS for clang. It seems
> > that same treatment is needed for REALMODE_CFLAGS, which also matches
> > arch/x86/boot/compressed/Makefile, see commit 6c3b56b19730 ("x86/boot:
> > Disable Clang warnings about GNU extensions"):
> >
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 1a068de12a56..24076db59783 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -53,6 +53,9 @@ REALMODE_CFLAGS += -fno-stack-protector
> > REALMODE_CFLAGS += -Wno-address-of-packed-member
> > REALMODE_CFLAGS += $(cc_stack_align4)
> > REALMODE_CFLAGS += $(CLANG_FLAGS)
> > +ifdef CONFIG_CC_IS_CLANG
> > +REALMODE_CFLAGS += -Wno-gnu
> > +endif
>
> Thanks. Shall I include this change in the patchset?
Yes, I think so to keep the build clean.
> Best regards
> Thomas
>
> > export REALMODE_CFLAGS
> > # BITS is used as extension for files which are available in a 32 bit
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
^ permalink raw reply [relevance 99%]
* Re: [PATCH] docs: kbuild/kconfig: reformat/cleanup
@ 2024-01-12 19:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-12 19:43 UTC (permalink / raw)
To: Vegard Nossum
Cc: Masahiro Yamada, Nick Desaulniers, Nicolas Schier,
Jonathan Corbet, Mauro Carvalho Chehab, linux-kbuild, linux-doc
On Fri, Jan 12, 2024 at 01:58:30PM +0100, Vegard Nossum wrote:
> This document was using headings in an odd way, causing the sidebar to be
> quite messy. I've adding new headings and turned some of the old headings
> into description lists.
>
> The indentation was a mix of spaces and tabs; I've turned them all into
> 4 spaces so it always reads correctly regardless of tab settings.
>
> Also use ``...`` instead of `...`; the difference is that `` is meant
> for "inline literals" (and renders in a monospace font) while ` is for
> "interpreted text" (and renders with italics).
>
> Also changed the title of the document to be more descriptive.
>
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
The output seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Documentation/kbuild/kconfig.rst | 363 ++++++++++++++-----------------
> 1 file changed, 166 insertions(+), 197 deletions(-)
>
> diff --git a/Documentation/kbuild/kconfig.rst b/Documentation/kbuild/kconfig.rst
> index c946eb44bd13..fc4e845bc249 100644
> --- a/Documentation/kbuild/kconfig.rst
> +++ b/Documentation/kbuild/kconfig.rst
> @@ -1,10 +1,10 @@
> -===================
> -Kconfig make config
> -===================
> +=================================
> +Configuration targets and editors
> +=================================
>
> -This file contains some assistance for using `make *config`.
> +This file contains some assistance for using ``make *config``.
>
> -Use "make help" to list all of the possible configuration targets.
> +Use ``make help`` to list all of the possible configuration targets.
>
> The xconfig ('qconf'), menuconfig ('mconf'), and nconfig ('nconf')
> programs also have embedded help text. Be sure to check that for
> @@ -12,8 +12,9 @@ navigation, search, and other general help text.
>
> The gconfig ('gconf') program has limited help text.
>
> +
> General
> --------
> +=======
>
> New kernel releases often introduce new config symbols. Often more
> important, new kernel releases may rename config symbols. When
> @@ -24,118 +25,102 @@ symbols have been introduced.
>
> To see a list of new config symbols, use::
>
> - cp user/some/old.config .config
> - make listnewconfig
> + cp user/some/old.config .config
> + make listnewconfig
>
> and the config program will list any new symbols, one per line.
>
> Alternatively, you can use the brute force method::
>
> - make oldconfig
> - scripts/diffconfig .config.old .config | less
> -
> -----------------------------------------------------------------------
> -
> -Environment variables for `*config`
> + make oldconfig
> + scripts/diffconfig .config.old .config | less
>
> -KCONFIG_CONFIG
> ---------------
> -This environment variable can be used to specify a default kernel config
> -file name to override the default name of ".config".
>
> -KCONFIG_DEFCONFIG_LIST
> -----------------------
> +Environment variables
> +=====================
>
> -This environment variable specifies a list of config files which can be used
> -as a base configuration in case the .config does not exist yet. Entries in
> -the list are separated with whitespaces to each other, and the first one
> -that exists is used.
> +Environment variables for ``*config``:
>
> -KCONFIG_OVERWRITECONFIG
> ------------------------
> -If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
> -break symlinks when .config is a symlink to somewhere else.
> +``KCONFIG_CONFIG``
> + This environment variable can be used to specify a default kernel config
> + file name to override the default name of ".config".
>
> -KCONFIG_WARN_UNKNOWN_SYMBOLS
> -----------------------------
> -This environment variable makes Kconfig warn about all unrecognized
> -symbols in the config input.
> +``KCONFIG_DEFCONFIG_LIST``
> + This environment variable specifies a list of config files which can be
> + used as a base configuration in case the .config does not exist yet.
> + Entries in the list are separated with whitespaces to each other, and
> + the first one that exists is used.
>
> -KCONFIG_WERROR
> ---------------
> -If set, Kconfig treats warnings as errors.
> +``KCONFIG_OVERWRITECONFIG``
> + If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
> + break symlinks when .config is a symlink to somewhere else.
>
> -`CONFIG_`
> ----------
> -If you set `CONFIG_` in the environment, Kconfig will prefix all symbols
> -with its value when saving the configuration, instead of using the default,
> -`CONFIG_`.
> +``KCONFIG_WARN_UNKNOWN_SYMBOLS``
> + This environment variable makes Kconfig warn about all unrecognized
> + symbols in the config input.
>
> -----------------------------------------------------------------------
> +``KCONFIG_WERROR``
> + If set, Kconfig treats warnings as errors.
>
> -Environment variables for '{allyes/allmod/allno/rand}config'
> +``CONFIG_``
> + If you set ``CONFIG_`` in the environment, Kconfig will prefix all symbols
> + with its value when saving the configuration, instead of using the
> + default, ``CONFIG_``.
>
> -KCONFIG_ALLCONFIG
> ------------------
> -(partially based on lkml email from/by Rob Landley, re: miniconfig)
> +Environment variables for ``{allyes/allmod/allno/rand}config``:
>
> ---------------------------------------------------
> +``KCONFIG_ALLCONFIG``
> + The allyesconfig/allmodconfig/allnoconfig/randconfig variants can also
> + use the environment variable KCONFIG_ALLCONFIG as a flag or a filename
> + that contains config symbols that the user requires to be set to a
> + specific value. If KCONFIG_ALLCONFIG is used without a filename where
> + KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", ``make *config``
> + checks for a file named "all{yes/mod/no/def/random}.config"
> + (corresponding to the ``*config`` command that was used) for symbol values
> + that are to be forced. If this file is not found, it checks for a
> + file named "all.config" to contain forced values.
>
> -The allyesconfig/allmodconfig/allnoconfig/randconfig variants can also
> -use the environment variable KCONFIG_ALLCONFIG as a flag or a filename
> -that contains config symbols that the user requires to be set to a
> -specific value. If KCONFIG_ALLCONFIG is used without a filename where
> -KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", `make *config`
> -checks for a file named "all{yes/mod/no/def/random}.config"
> -(corresponding to the `*config` command that was used) for symbol values
> -that are to be forced. If this file is not found, it checks for a
> -file named "all.config" to contain forced values.
> + This enables you to create "miniature" config (miniconfig) or custom
> + config files containing just the config symbols that you are interested
> + in. Then the kernel config system generates the full .config file,
> + including symbols of your miniconfig file.
>
> -This enables you to create "miniature" config (miniconfig) or custom
> -config files containing just the config symbols that you are interested
> -in. Then the kernel config system generates the full .config file,
> -including symbols of your miniconfig file.
> -
> -This 'KCONFIG_ALLCONFIG' file is a config file which contains
> -(usually a subset of all) preset config symbols. These variable
> -settings are still subject to normal dependency checks.
> -
> -Examples::
> + This ``KCONFIG_ALLCONFIG`` file is a config file which contains
> + (usually a subset of all) preset config symbols. These variable
> + settings are still subject to normal dependency checks.
>
> - KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
> + Examples::
>
> -or::
> + KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
>
> - KCONFIG_ALLCONFIG=mini.config make allnoconfig
> + or::
>
> -or::
> + KCONFIG_ALLCONFIG=mini.config make allnoconfig
>
> - make KCONFIG_ALLCONFIG=mini.config allnoconfig
> + or::
>
> -These examples will disable most options (allnoconfig) but enable or
> -disable the options that are explicitly listed in the specified
> -mini-config files.
> + make KCONFIG_ALLCONFIG=mini.config allnoconfig
>
> -----------------------------------------------------------------------
> + These examples will disable most options (allnoconfig) but enable or
> + disable the options that are explicitly listed in the specified
> + mini-config files.
>
> -Environment variables for 'randconfig'
> +Environment variables for ``randconfig``:
>
> -KCONFIG_SEED
> -------------
> -You can set this to the integer value used to seed the RNG, if you want
> -to somehow debug the behaviour of the kconfig parser/frontends.
> -If not set, the current time will be used.
> +``KCONFIG_SEED``
> + You can set this to the integer value used to seed the RNG, if you want
> + to somehow debug the behaviour of the kconfig parser/frontends.
> + If not set, the current time will be used.
>
> -KCONFIG_PROBABILITY
> --------------------
> -This variable can be used to skew the probabilities. This variable can
> -be unset or empty, or set to three different formats:
> +``KCONFIG_PROBABILITY``
> + This variable can be used to skew the probabilities. This variable can
> + be unset or empty, or set to three different formats:
>
> ======================= ================== =====================
> - KCONFIG_PROBABILITY y:n split y:m:n split
> + KCONFIG_PROBABILITY y:n split y:m:n split
> ======================= ================== =====================
> - unset or empty 50 : 50 33 : 33 : 34
> - N N : 100-N N/2 : N/2 : 100-N
> + unset or empty 50 : 50 33 : 33 : 34
> + N N : 100-N N/2 : N/2 : 100-N
> [1] N:M N+M : 100-(N+M) N : M : 100-(N+M)
> [2] N:M:L N : 100-N M : L : 100-(M+L)
> ======================= ================== =====================
> @@ -149,112 +134,98 @@ that:
>
> Examples::
>
> - KCONFIG_PROBABILITY=10
> - 10% of booleans will be set to 'y', 90% to 'n'
> - 5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
> - KCONFIG_PROBABILITY=15:25
> - 40% of booleans will be set to 'y', 60% to 'n'
> - 15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
> - KCONFIG_PROBABILITY=10:15:15
> - 10% of booleans will be set to 'y', 90% to 'n'
> - 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
> + KCONFIG_PROBABILITY=10
> + 10% of booleans will be set to 'y', 90% to 'n'
> + 5% of tristates will be set to 'y', 5% to 'm', 90% to 'n'
> + KCONFIG_PROBABILITY=15:25
> + 40% of booleans will be set to 'y', 60% to 'n'
> + 15% of tristates will be set to 'y', 25% to 'm', 60% to 'n'
> + KCONFIG_PROBABILITY=10:15:15
> + 10% of booleans will be set to 'y', 90% to 'n'
> + 15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
>
> -----------------------------------------------------------------------
> +Environment variables for ``syncconfig``:
>
> -Environment variables for 'syncconfig'
> +``KCONFIG_NOSILENTUPDATE``
> + If this variable has a non-blank value, it prevents silent kernel
> + config updates (requires explicit updates).
>
> -KCONFIG_NOSILENTUPDATE
> -----------------------
> -If this variable has a non-blank value, it prevents silent kernel
> -config updates (requires explicit updates).
> +``KCONFIG_AUTOCONFIG``
> + This environment variable can be set to specify the path & name of the
> + "auto.conf" file. Its default value is "include/config/auto.conf".
>
> -KCONFIG_AUTOCONFIG
> -------------------
> -This environment variable can be set to specify the path & name of the
> -"auto.conf" file. Its default value is "include/config/auto.conf".
> +``KCONFIG_AUTOHEADER``
> + This environment variable can be set to specify the path & name of the
> + "autoconf.h" (header) file.
> + Its default value is "include/generated/autoconf.h".
>
> -KCONFIG_AUTOHEADER
> -------------------
> -This environment variable can be set to specify the path & name of the
> -"autoconf.h" (header) file.
> -Its default value is "include/generated/autoconf.h".
> -
> -
> -----------------------------------------------------------------------
>
> menuconfig
> -----------
> -
> -SEARCHING for CONFIG symbols
> +==========
>
> Searching in menuconfig:
>
> - The Search function searches for kernel configuration symbol
> - names, so you have to know something close to what you are
> - looking for.
> + The Search function searches for kernel configuration symbol
> + names, so you have to know something close to what you are
> + looking for.
>
> - Example::
> + Example::
>
> - /hotplug
> - This lists all config symbols that contain "hotplug",
> - e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
> + /hotplug
> + This lists all config symbols that contain "hotplug",
> + e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
>
> - For search help, enter / followed by TAB-TAB (to highlight
> - <Help>) and Enter. This will tell you that you can also use
> - regular expressions (regexes) in the search string, so if you
> - are not interested in MEMORY_HOTPLUG, you could try::
> + For search help, enter / followed by TAB-TAB (to highlight
> + <Help>) and Enter. This will tell you that you can also use
> + regular expressions (regexes) in the search string, so if you
> + are not interested in MEMORY_HOTPLUG, you could try::
>
> - /^hotplug
> + /^hotplug
>
> - When searching, symbols are sorted thus:
> + When searching, symbols are sorted thus:
>
> - - first, exact matches, sorted alphabetically (an exact match
> - is when the search matches the complete symbol name);
> - - then, other matches, sorted alphabetically.
> + - first, exact matches, sorted alphabetically (an exact match
> + is when the search matches the complete symbol name);
> + - then, other matches, sorted alphabetically.
>
> - For example: ^ATH.K matches:
> + For example, ^ATH.K matches:
>
> - ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
> - [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
> + ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
> + [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
>
> - of which only ATH5K and ATH9K match exactly and so are sorted
> - first (and in alphabetical order), then come all other symbols,
> - sorted in alphabetical order.
> + of which only ATH5K and ATH9K match exactly and so are sorted
> + first (and in alphabetical order), then come all other symbols,
> + sorted in alphabetical order.
>
> - In this menu, pressing the key in the (#) prefix will jump
> - directly to that location. You will be returned to the current
> - search results after exiting this new menu.
> + In this menu, pressing the key in the (#) prefix will jump
> + directly to that location. You will be returned to the current
> + search results after exiting this new menu.
>
> -----------------------------------------------------------------------
> +User interface options for 'menuconfig':
>
> -User interface options for 'menuconfig'
> +``MENUCONFIG_COLOR``
> + It is possible to select different color themes using the variable
> + MENUCONFIG_COLOR. To select a theme use::
>
> -MENUCONFIG_COLOR
> -----------------
> -It is possible to select different color themes using the variable
> -MENUCONFIG_COLOR. To select a theme use::
> + make MENUCONFIG_COLOR=<theme> menuconfig
>
> - make MENUCONFIG_COLOR=<theme> menuconfig
> + Available themes are::
>
> -Available themes are::
> + - mono => selects colors suitable for monochrome displays
> + - blackbg => selects a color scheme with black background
> + - classic => theme with blue background. The classic look
> + - bluetitle => a LCD friendly version of classic. (default)
>
> - - mono => selects colors suitable for monochrome displays
> - - blackbg => selects a color scheme with black background
> - - classic => theme with blue background. The classic look
> - - bluetitle => a LCD friendly version of classic. (default)
> +``MENUCONFIG_MODE``
> + This mode shows all sub-menus in one large tree.
>
> -MENUCONFIG_MODE
> ----------------
> -This mode shows all sub-menus in one large tree.
> + Example::
>
> -Example::
> + make MENUCONFIG_MODE=single_menu menuconfig
>
> - make MENUCONFIG_MODE=single_menu menuconfig
> -
> -----------------------------------------------------------------------
>
> nconfig
> --------
> +=======
>
> nconfig is an alternate text-based configurator. It lists function
> keys across the bottom of the terminal (window) that execute commands.
> @@ -266,61 +237,59 @@ Use F1 for Global help or F3 for the Short help menu.
>
> Searching in nconfig:
>
> - You can search either in the menu entry "prompt" strings
> - or in the configuration symbols.
> + You can search either in the menu entry "prompt" strings
> + or in the configuration symbols.
> +
> + Use / to begin a search through the menu entries. This does
> + not support regular expressions. Use <Down> or <Up> for
> + Next hit and Previous hit, respectively. Use <Esc> to
> + terminate the search mode.
>
> - Use / to begin a search through the menu entries. This does
> - not support regular expressions. Use <Down> or <Up> for
> - Next hit and Previous hit, respectively. Use <Esc> to
> - terminate the search mode.
> + F8 (SymSearch) searches the configuration symbols for the
> + given string or regular expression (regex).
>
> - F8 (SymSearch) searches the configuration symbols for the
> - given string or regular expression (regex).
> + In the SymSearch, pressing the key in the (#) prefix will
> + jump directly to that location. You will be returned to the
> + current search results after exiting this new menu.
>
> - In the SymSearch, pressing the key in the (#) prefix will
> - jump directly to that location. You will be returned to the
> - current search results after exiting this new menu.
> +Environment variables:
>
> -NCONFIG_MODE
> -------------
> -This mode shows all sub-menus in one large tree.
> +``NCONFIG_MODE``
> + This mode shows all sub-menus in one large tree.
>
> -Example::
> + Example::
>
> - make NCONFIG_MODE=single_menu nconfig
> + make NCONFIG_MODE=single_menu nconfig
>
> -----------------------------------------------------------------------
>
> xconfig
> --------
> +=======
>
> Searching in xconfig:
>
> - The Search function searches for kernel configuration symbol
> - names, so you have to know something close to what you are
> - looking for.
> -
> - Example::
> + The Search function searches for kernel configuration symbol
> + names, so you have to know something close to what you are
> + looking for.
>
> - Ctrl-F hotplug
> + Example::
>
> - or::
> + Ctrl-F hotplug
>
> - Menu: File, Search, hotplug
> + or::
>
> - lists all config symbol entries that contain "hotplug" in
> - the symbol name. In this Search dialog, you may change the
> - config setting for any of the entries that are not grayed out.
> - You can also enter a different search string without having
> - to return to the main menu.
> + Menu: File, Search, hotplug
>
> + lists all config symbol entries that contain "hotplug" in
> + the symbol name. In this Search dialog, you may change the
> + config setting for any of the entries that are not grayed out.
> + You can also enter a different search string without having
> + to return to the main menu.
>
> -----------------------------------------------------------------------
>
> gconfig
> --------
> +=======
>
> Searching in gconfig:
>
> - There is no search command in gconfig. However, gconfig does
> - have several different viewing choices, modes, and options.
> + There is no search command in gconfig. However, gconfig does
> + have several different viewing choices, modes, and options.
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1833:4: warning: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94
@ 2024-01-12 19:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-12 19:47 UTC (permalink / raw)
To: kernel test robot
Cc: Vlad Buslov, llvm, oe-kbuild-all, linux-kernel, Saeed Mahameed,
Maor Dickman, Roi Dayan, masahiroy
On Wed, Jan 10, 2024 at 10:55:22PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: ab27740f76654ed58dd32ac0ba0031c18a6dea3b
> commit: 70f0302b3f2053b64a6a653a76a20cb95438dc85 net/mlx5: Bridge, implement mdb offload
> date: 9 months ago
> config: arm64-allyesconfig (https://download.01.org/0day-ci/archive/20240110/202401102205.XmxWrS5y-lkp@intel.com/config)
> compiler: clang version 18.0.0git (https://github.com/llvm/llvm-project 7e186d366d6c7def0543acc255931f617e76dff0)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240110/202401102205.XmxWrS5y-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202401102205.XmxWrS5y-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1833:4: warning: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94 [-Wformat-truncation-non-kprintf]
> 1833 | NL_SET_ERR_MSG_FMT_MOD(extack,
> | ^
> include/linux/netlink.h:130:2: note: expanded from macro 'NL_SET_ERR_MSG_FMT_MOD'
> 130 | NL_SET_ERR_MSG_FMT((extack), KBUILD_MODNAME ": " fmt, ##args)
> | ^
> include/linux/netlink.h:115:6: note: expanded from macro 'NL_SET_ERR_MSG_FMT'
> 115 | if (snprintf(__extack->_msg_buf, NETLINK_MAX_FMTMSG_LEN, \
> | ^
> 1 warning generated.
I have not looked to see if this is a legitimate issue or not, as clang
does not understand the kernel's special %p modifiers, so it is a little
hard to tell at first glance. For this reason, I sent a patch turning
off the -non-kprintf warnings but it has not been picked up yet:
https://lore.kernel.org/20231002-disable-wformat-truncation-overflow-non-kprintf-v1-1-35179205c8d9@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [akpm-mm:mm-nonmm-unstable 22/23] lib/group_cpus.c:352:16: error: array initializer must be an initializer list
@ 2024-01-16 22:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-16 22:55 UTC (permalink / raw)
To: Yury Norov, Andrew Morton
Cc: llvm, oe-kbuild-all, Linux Memory Management List, kernel test robot
On Sun, Jan 14, 2024 at 01:40:11AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> head: 3d69c575710800c9a4a58e94c157697310e32027
> commit: a868f9c8816cb72f983d1ff940b0938737fe8ee7 [22/23] lib/group_cpus: fix initialization section in group_cpus_evenly()
> config: i386-randconfig-011-20240113 (https://download.01.org/0day-ci/archive/20240114/202401140117.pwAcsXAT-lkp@intel.com/config)
> compiler: ClangBuiltLinux clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240114/202401140117.pwAcsXAT-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202401140117.pwAcsXAT-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> lib/group_cpus.c:352:16: error: array initializer must be an initializer list
> 352 | cpumask_var_t npresmsk __free(free_cpumask_var) = NULL;
> | ^
> 1 error generated.
Not a compiler specific error, as evidenced by the GCC report:
https://lore.kernel.org/202401160231.mSAgDn9b-lkp@intel.com/
Neither configuration has CONFIG_CPUMASK_OFFSTACK, which is not going to
be enabled for most configurations, as it is not user selectable without
CONFIG_DEBUG_PER_CPU_MAPS and there are only a few conditions where it
is force selected. In other words, I suspect this error is going to be
quite widespread if it hits -next. I can still reproduce it at the
current mm-nonmm-unstable, commit 08be2d243fb7 ("lib/sort: Optimize
heapsort with double-pop variation").
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] power-supply changes for 6.8
@ 2024-01-17 18:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-17 18:00 UTC (permalink / raw)
To: Sebastian Reichel; +Cc: Linus Torvalds, linux-kernel, linux-pm
Hi Sebastian,
On Mon, Jan 15, 2024 at 09:43:11PM +0100, Sebastian Reichel wrote:
> Hi Linus,
>
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
>
> Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git tags/for-v6.8
>
> for you to fetch changes up to 05599b5f56b750b5a92ff7f2c081945210816f83:
>
> Merge power-supply fixes for 6.7 cycle (2024-01-14 21:38:31 +0100)
>
> ----------------------------------------------------------------
> power supply and reset changes for the 6.8 series
>
> * new drivers / features
> - bq24190: Add support for BQ24296 charger
> * cleanups
> - all reset drivers: Stop using module_platform_driver_probe()
> - gpio-restart: use devm_register_sys_off_handler
> - pwr-mlxbf: support graceful reboot
> - cw2015: correct time_to_empty units
> - qcom-battmgr: Fix driver initialization sequence
> - bq27xxx: Start/Stop delayed work in suspend/resume
> - minor cleanups and fixes
<snip>
> Hermes Zhang (2):
> dt-bindings: power: supply: bq24190: Add BQ24296 compatible
> power: supply: bq24190_charger: Add support for BQ24296
This is missing a fix for building with older compilers:
https://lore.kernel.org/20240103-fix-bq24190_charger-vbus_desc-non-const-v1-1-115ddf798c70@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL]: dmaengine updates for v6.8
@ 2024-01-18 19:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-18 19:11 UTC (permalink / raw)
To: Vinod Koul; +Cc: Linus Torvalds, LKML, llvm
Hi Vinod,
On Thu, Jan 18, 2024 at 10:54:28PM +0530, Vinod Koul wrote:
> Heya Linus,
>
> Last pull request for the night to receive the dmaengine subsystem
> updates containing one new driver, couple of device support (qualcomm,
> sf-pdma) and driver updates.
>
> The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
>
> Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git tags/dmaengine-6.8-rc1
>
> for you to fetch changes up to 3d0b2176e04261ab4ac095ff2a17db077fc1e46d:
>
> dmaengine: xilinx: xdma: statify xdma_prep_interleaved_dma (2023-12-22 21:17:52 +0530)
>
> ----------------------------------------------------------------
> dmaengine updates for v6.8
>
> New support:
> - Loongson LS2X APB DMA controller
> - sf-pdma: mpfs-pdma support
> - Qualcomm X1E80100 GPI dma controller support
>
> Updates:
> - Xilinx XDMA updates to support interleaved DMA transfers
> - TI PSIL threads for AM62P and J722S and cfg register regions description
> - axi-dmac Improving the cyclic DMA transfers
> - Tegra Support dma-channel-mask property
> - Remaining platform remove callback returning void conversions
<snip>
> Jan Kuliga (8):
> dmaengine: xilinx: xdma: Get rid of unused code
> dmaengine: xilinx: xdma: Add necessary macro definitions
> dmaengine: xilinx: xdma: Ease dma_pool alignment requirements
> dmaengine: xilinx: xdma: Rework xdma_terminate_all()
> dmaengine: xilinx: xdma: Add error checking in xdma_channel_isr()
> dmaengine: xilinx: xdma: Add transfer error reporting
> dmaengine: xilinx: xdma: Prepare the introduction of interleaved DMA transfers
> dmaengine: xilinx: xdma: Implement interleaved DMA transfers
This pull request appears to be missing some fixes for the clang
warnings introduced by this series, which will break the build with
CONFIG_WERROR=y:
https://lore.kernel.org/20231222-dma-xilinx-xdma-clang-fixes-v1-0-84a18ff184d2@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 2/4] modpost: inform compilers that fatal() never returns
@ 2024-01-22 23:02 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-22 23:02 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Aiden Leong, linux-kbuild, linux-kernel, ndesaulniers, nicolas,
clang-built-linux,
F���ng-ru���
S���ng
On Mon, Jan 22, 2024 at 10:29:32PM +0900, Masahiro Yamada wrote:
> +CC: clang-built-linux list, Fangrui
>
> On Mon, Jan 22, 2024 at 1:04 PM Aiden Leong <aiden.leong@aibsd.com> wrote:
> >
> >
> > > The function fatal() never returns because modpost_log() calls exit(1)
> >
> > > when LOG_FATAL is passed.
> > >
> > > Inform compilers of this fact so that unreachable code flow can be
> > > identified at compile time.
> > >
> > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > > ---
> > >
> > > Changes in v2:
> > > - Use noreturn attribute together with alias
> > >
> > > scripts/mod/modpost.c | 3 +++
> > > scripts/mod/modpost.h | 5 ++++-
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> > > index ca0a90158f85..c13bc9095df3 100644
> > > --- a/scripts/mod/modpost.c
> > > +++ b/scripts/mod/modpost.c
> > > @@ -90,6 +90,9 @@ void modpost_log(enum loglevel loglevel, const char
> > *fmt, ...)
> > > error_occurred = true;
> > > }
> > >
> > > +void __attribute__((alias("modpost_log")))
> >
> > Hi Masahiro,
> > I cross-compile kernel on Apple Silicon MacBook Pro
> > and every thing works well until this patch.
> >
> > My build command:
> > make ARCH=arm CROSS_COMPILE=arm-none-eabi- \
> > HOSTCFLAGS="-I/opt/homebrew/opt/openssl/include" \
> > HOSTLDFLAGS="-L/opt/homebrew/opt/openssl/lib"
> >
> > Error message:
> > scripts/mod/modpost.c:93:21: error: aliases are not supported on darwin
>
>
> It is unfortunate. Indeed, I see this message in:
>
> clang/include/clang/Basic/DiagnosticSemaKinds.td
>
>
> Is this limitation due to macOS executable (PEF),
> or is it Clang-specific?
Based on my admittedly brief research, this seems related to the Mach-O
format. That message was added by [1] in response to [2] but the message
mentioned weak aliases being supported. A further clarification was made
in [3] to state that all aliases are unsupported as a result of some
internal Apple bug it seems but I do see a couple of bug reports stating
that may not be true [4][5] (although that does not seem relevant for
this report).
[1]: https://github.com/llvm/llvm-project/commit/0017c5fa92ad3b10e15fd34f3865e8e5b850a5ed
[2]: https://llvm.org/bz8720
[3]: https://github.com/llvm/llvm-project/commit/4e30b96834cea5682a8e9e024dda06319825000a
[4]: https://github.com/llvm/llvm-project/issues/11488
[5]: https://github.com/llvm/llvm-project/issues/71001
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH 09/11] fortify: Drop Clang version check for 12.0.1 or newer
` (2 preceding siblings ...)
2024-01-25 22:55 99% ` [PATCH 10/11] lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV Nathan Chancellor
@ 2024-01-25 22:55 99% ` Nathan Chancellor
4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 22:55 UTC (permalink / raw)
To: akpm, masahiroy
Cc: nicolas, linux-kbuild, llvm, patches, linux-kernel,
Nathan Chancellor, keescook, linux-hardening
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 13.0.1, this condition is always true, as the build
will fail during the configuration stage for older LLVM versions. Remove
it.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Cc: keescook@chromium.org
Cc: linux-hardening@vger.kernel.org
---
security/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/security/Kconfig b/security/Kconfig
index 606a87c29a01..412e76f1575d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -142,8 +142,6 @@ config HARDENED_USERCOPY
config FORTIFY_SOURCE
bool "Harden common str/mem functions against buffer overflows"
depends on ARCH_HAS_FORTIFY_SOURCE
- # https://llvm.org/pr41459
- depends on !CC_IS_CLANG || CLANG_VERSION >= 120001
# https://github.com/llvm/llvm-project/issues/53645
depends on !CC_IS_CLANG || !X86_32
help
--
2.43.0
^ permalink raw reply related [relevance 99%]
* [PATCH 11/11] compiler-clang.h: Update __diag_clang() macros for minimum version bump
2024-01-25 22:55 99% ` [PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT Nathan Chancellor
@ 2024-01-25 22:55 99% ` Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 10/11] lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV Nathan Chancellor
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 22:55 UTC (permalink / raw)
To: akpm, masahiroy
Cc: nicolas, linux-kbuild, llvm, patches, linux-kernel, Nathan Chancellor
The minimum supported version of LLVM for building the kernel
has been bumped to 13.0.1. Update the __diag_clang() macros for this
bump.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
include/linux/compiler-clang.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index f0a47afef125..49feac0162a5 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -114,11 +114,7 @@
#define __diag_str(s) __diag_str1(s)
#define __diag(s) _Pragma(__diag_str(clang diagnostic s))
-#if CONFIG_CLANG_VERSION >= 110000
-#define __diag_clang_11(s) __diag(s)
-#else
-#define __diag_clang_11(s)
-#endif
+#define __diag_clang_13(s) __diag(s)
#define __diag_ignore_all(option, comment) \
- __diag_clang(11, ignore, option)
+ __diag_clang(13, ignore, option)
--
2.43.0
^ permalink raw reply related [relevance 99%]
* [PATCH 10/11] lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
2024-01-25 22:55 99% ` [PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 11/11] compiler-clang.h: Update __diag_clang() macros for minimum version bump Nathan Chancellor
@ 2024-01-25 22:55 99% ` Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 09/11] fortify: Drop Clang version check for 12.0.1 or newer Nathan Chancellor
4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 22:55 UTC (permalink / raw)
To: akpm, masahiroy
Cc: nicolas, linux-kbuild, llvm, patches, linux-kernel, Nathan Chancellor
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 13.0.1, this condition can be changed to just
CONFIG_CC_IS_CLANG, as the build will fail during the configuration
stage for older LLVM versions.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
lib/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 8f502f15dc7f..1339fb893d71 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2085,7 +2085,7 @@ config KCOV
depends on ARCH_HAS_KCOV
depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \
- GCC_VERSION >= 120000 || CLANG_VERSION >= 130000
+ GCC_VERSION >= 120000 || CC_IS_CLANG
select DEBUG_FS
select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
select OBJTOOL if HAVE_NOINSTR_HACK
--
2.43.0
^ permalink raw reply related [relevance 99%]
* [PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
@ 2024-01-25 22:55 99% ` Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 11/11] compiler-clang.h: Update __diag_clang() macros for minimum version bump Nathan Chancellor
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 22:55 UTC (permalink / raw)
To: akpm, masahiroy
Cc: aneesh.kumar, nicolas, linux-kbuild, llvm, patches, npiggin,
linux-kernel, Nathan Chancellor, naveen.n.rao, linuxppc-dev
This reverts commit 6fcb574125e6 ("powerpc: Kconfig: disable
CONFIG_COMPAT for clang < 12").
Now that the minimum supported version of LLVM for building the kernel
has been bumped to 13.0.1, this condition is always true, as the build
will fail during the configuration stage for older LLVM versions. Remove
it.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
Cc: mpe@ellerman.id.au
Cc: npiggin@gmail.com
Cc: aneesh.kumar@kernel.org
Cc: naveen.n.rao@linux.ibm.com
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b9fc064d38d2..86da0d01365a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -333,7 +333,6 @@ config PANIC_TIMEOUT
config COMPAT
bool "Enable support for 32bit binaries"
depends on PPC64
- depends on !CC_IS_CLANG || CLANG_VERSION >= 120000
default y if !CPU_LITTLE_ENDIAN
select ARCH_WANT_OLD_COMPAT_IPC
select COMPAT_OLD_SIGACTION
--
2.43.0
^ permalink raw reply related [relevance 99%]
* Re: [Linaro-TCWG-CI] llvmorg-19-init-59-g90ba33099cbb: Failure on aarch64
@ 2024-01-25 23:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-25 23:00 UTC (permalink / raw)
To: linaro-toolchain; +Cc: llvm
On Thu, Jan 25, 2024 at 08:20:54PM +0000, ci_notify@linaro.org wrote:
> Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate that it might be difficult to find the necessary logs or reproduce the issue locally. If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
>
> We track this report status in https://linaro.atlassian.net/browse/LLVM-1105 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In CI config tcwg_kernel/llvm-master-aarch64-stable-allyesconfig after:
>
> | commit llvmorg-19-init-59-g90ba33099cbb
> | Author: Nikita Popov <npopov@redhat.com>
> | Date: Wed Jan 24 15:25:29 2024 +0100
> |
> | [InstCombine] Canonicalize constant GEPs to i8 source element type (#68882)
> |
> | This patch canonicalizes getelementptr instructions with constant
> | indices to use the `i8` source element type. This makes it easier for
> | optimizations to recognize that two GEPs are identical, because they
> | don't need to see past many different ways to express the same offset.
> |
> | ... 14 lines of the commit log omitted.
>
> Results changed to
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_kernel_llvm:
> -5
> # build_abe qemu:
> -2
> # linux_n_obj:
> 22291
> # First few build errors in logs:
>
> # 00:05:24 ./include/linux/fortify-string.h:493: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]
> # 00:05:25 make[4]: *** [scripts/Makefile.build:243: net/xfrm/xfrm_user.o] Error 1
> # 00:05:32 make[3]: *** [scripts/Makefile.build:480: net/xfrm] Error 2
This one is the new warning tied to the above LLVM change, I filed
https://github.com/ClangBuiltLinux/linux/issues/1985 for that a little
bit ago.
> # 00:15:32 ./include/linux/fortify-string.h:493: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]
> # 00:15:32 make[5]: *** [scripts/Makefile.build:243: fs/smb/client/cifsencrypt.o] Error 1
This one is https://github.com/ClangBuiltLinux/linux/issues/1966.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 05/11] arm64: Kconfig: Clean up tautological LLVM version checks
@ 2024-01-26 16:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-26 16:10 UTC (permalink / raw)
To: Mark Rutland
Cc: akpm, masahiroy, nicolas, linux-kbuild, llvm, patches,
linux-kernel, catalin.marinas, will, linux-arm-kernel
On Fri, Jan 26, 2024 at 12:59:55PM +0000, Mark Rutland wrote:
> On Thu, Jan 25, 2024 at 03:55:11PM -0700, Nathan Chancellor wrote:
> > Now that the minimum supported version of LLVM for building the kernel
> > has been bumped to 13.0.1, several conditions become tautologies, as
> > they will always be true because the build will fail during the
> > configuration stage for older LLVM versions. Drop them, as they are
> > unnecessary.
> >
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > Cc: catalin.marinas@arm.com
> > Cc: will@kernel.org
> > Cc: mark.rutland@arm.com
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > arch/arm64/Kconfig | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 5a8acca4dbf4..cb34e7d780c0 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -383,7 +383,7 @@ config BUILTIN_RETURN_ADDRESS_STRIPS_PAC
> > bool
> > # Clang's __builtin_return_adddress() strips the PAC since 12.0.0
> > # https://github.com/llvm/llvm-project/commit/2a96f47c5ffca84cd774ad402cacd137f4bf45e2
> > - default y if CC_IS_CLANG && (CLANG_VERSION >= 120000)
> > + default y if CC_IS_CLANG
> > # GCC's __builtin_return_address() strips the PAC since 11.1.0,
> > # and this was backported to 10.2.0, 9.4.0, 8.5.0, but not earlier
> > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
> > @@ -1387,7 +1387,6 @@ choice
> >
> > config CPU_BIG_ENDIAN
> > bool "Build big-endian kernel"
> > - depends on !LD_IS_LLD || LLD_VERSION >= 130000
> > # https://github.com/llvm/llvm-project/commit/1379b150991f70a5782e9a143c2ba5308da1161c
>
> We can delete the URL here, since that was just to describe why this depended
> upon LLVM 13+; it's weird for it to sit here on its own.
I think this is the URL for the fix for the problem brought up by
commit 146a15b87335 ("arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM
IAS 15.x or newer"), so I think it should stay? It does not look like I
ever added a link or context for the LLD line, I definitely should have.
> The URL above for __builtin_return_address() can stay or go; it may as well
> stay since we have the comment aboout LLvm 12+ above it.
That's the conclusion I came to as well.
Thanks a lot for taking a look!
Cheers,
Nathan
> With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Mark.
>
> > depends on AS_IS_GNU || AS_VERSION >= 150000
> > help
> > @@ -2018,8 +2017,6 @@ config ARM64_BTI_KERNEL
> > depends on !CC_IS_GCC || GCC_VERSION >= 100100
> > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
> > depends on !CC_IS_GCC
> > - # https://github.com/llvm/llvm-project/commit/a88c722e687e6780dcd6a58718350dc76fcc4cc9
> > - depends on !CC_IS_CLANG || CLANG_VERSION >= 120000
> > depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS)
> > help
> > Build the kernel with Branch Target Identification annotations
> >
> > --
> > 2.43.0
> >
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 05/11] arm64: Kconfig: Clean up tautological LLVM version checks
@ 2024-01-26 16:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-26 16:10 UTC (permalink / raw)
To: Mark Rutland
Cc: akpm, masahiroy, nicolas, linux-kbuild, llvm, patches,
linux-kernel, catalin.marinas, will, linux-arm-kernel
On Fri, Jan 26, 2024 at 12:59:55PM +0000, Mark Rutland wrote:
> On Thu, Jan 25, 2024 at 03:55:11PM -0700, Nathan Chancellor wrote:
> > Now that the minimum supported version of LLVM for building the kernel
> > has been bumped to 13.0.1, several conditions become tautologies, as
> > they will always be true because the build will fail during the
> > configuration stage for older LLVM versions. Drop them, as they are
> > unnecessary.
> >
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > Cc: catalin.marinas@arm.com
> > Cc: will@kernel.org
> > Cc: mark.rutland@arm.com
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > arch/arm64/Kconfig | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 5a8acca4dbf4..cb34e7d780c0 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -383,7 +383,7 @@ config BUILTIN_RETURN_ADDRESS_STRIPS_PAC
> > bool
> > # Clang's __builtin_return_adddress() strips the PAC since 12.0.0
> > # https://github.com/llvm/llvm-project/commit/2a96f47c5ffca84cd774ad402cacd137f4bf45e2
> > - default y if CC_IS_CLANG && (CLANG_VERSION >= 120000)
> > + default y if CC_IS_CLANG
> > # GCC's __builtin_return_address() strips the PAC since 11.1.0,
> > # and this was backported to 10.2.0, 9.4.0, 8.5.0, but not earlier
> > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891
> > @@ -1387,7 +1387,6 @@ choice
> >
> > config CPU_BIG_ENDIAN
> > bool "Build big-endian kernel"
> > - depends on !LD_IS_LLD || LLD_VERSION >= 130000
> > # https://github.com/llvm/llvm-project/commit/1379b150991f70a5782e9a143c2ba5308da1161c
>
> We can delete the URL here, since that was just to describe why this depended
> upon LLVM 13+; it's weird for it to sit here on its own.
I think this is the URL for the fix for the problem brought up by
commit 146a15b87335 ("arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM
IAS 15.x or newer"), so I think it should stay? It does not look like I
ever added a link or context for the LLD line, I definitely should have.
> The URL above for __builtin_return_address() can stay or go; it may as well
> stay since we have the comment aboout LLvm 12+ above it.
That's the conclusion I came to as well.
Thanks a lot for taking a look!
Cheers,
Nathan
> With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Mark.
>
> > depends on AS_IS_GNU || AS_VERSION >= 150000
> > help
> > @@ -2018,8 +2017,6 @@ config ARM64_BTI_KERNEL
> > depends on !CC_IS_GCC || GCC_VERSION >= 100100
> > # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
> > depends on !CC_IS_GCC
> > - # https://github.com/llvm/llvm-project/commit/a88c722e687e6780dcd6a58718350dc76fcc4cc9
> > - depends on !CC_IS_CLANG || CLANG_VERSION >= 120000
> > depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_ARGS)
> > help
> > Build the kernel with Branch Target Identification annotations
> >
> > --
> > 2.43.0
> >
>
_______________________________________________
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: [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] RISC-V: fix check for zvkb with tip-of-tree clang
@ 2024-01-27 19:52 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-27 19:52 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-riscv, linux-crypto, llvm, Brandon Wu
On Sat, Jan 27, 2024 at 01:00:54AM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> LLVM commit 8e01042da9d3 ("[RISCV] Add missing dependency check for Zvkb
> (#79467)") broke the check used by the TOOLCHAIN_HAS_VECTOR_CRYPTO
> kconfig symbol because it made zvkb start depending on v or zve*. Fix
> this by specifying both v and zvkb when checking for support for zvkb.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I also verified this does not regress GCC.
> ---
> arch/riscv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index b49016bb5077b..912fff31492b9 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -581,21 +581,21 @@ config TOOLCHAIN_HAS_ZBB
> default y
> depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb)
> depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb)
> depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
> depends on AS_HAS_OPTION_ARCH
>
> # This symbol indicates that the toolchain supports all v1.0 vector crypto
> # extensions, including Zvk*, Zvbb, and Zvbc. LLVM added all of these at once.
> # binutils added all except Zvkb, then added Zvkb. So we just check for Zvkb.
> config TOOLCHAIN_HAS_VECTOR_CRYPTO
> - def_bool $(as-instr, .option arch$(comma) +zvkb)
> + def_bool $(as-instr, .option arch$(comma) +v$(comma) +zvkb)
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_ZBB
> bool "Zbb extension support for bit manipulation instructions"
> depends on TOOLCHAIN_HAS_ZBB
> depends on MMU
> depends on RISCV_ALTERNATIVE
> default y
> help
> Adds support to dynamically detect the presence of the ZBB
>
> base-commit: cb4ede926134a65bc3bf90ed58dace8451d7e759
> --
> 2.43.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] RISC-V: fix check for zvkb with tip-of-tree clang
@ 2024-01-27 19:52 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-27 19:52 UTC (permalink / raw)
To: Eric Biggers; +Cc: linux-riscv, linux-crypto, llvm, Brandon Wu
On Sat, Jan 27, 2024 at 01:00:54AM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> LLVM commit 8e01042da9d3 ("[RISCV] Add missing dependency check for Zvkb
> (#79467)") broke the check used by the TOOLCHAIN_HAS_VECTOR_CRYPTO
> kconfig symbol because it made zvkb start depending on v or zve*. Fix
> this by specifying both v and zvkb when checking for support for zvkb.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I also verified this does not regress GCC.
> ---
> arch/riscv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index b49016bb5077b..912fff31492b9 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -581,21 +581,21 @@ config TOOLCHAIN_HAS_ZBB
> default y
> depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb)
> depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb)
> depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
> depends on AS_HAS_OPTION_ARCH
>
> # This symbol indicates that the toolchain supports all v1.0 vector crypto
> # extensions, including Zvk*, Zvbb, and Zvbc. LLVM added all of these at once.
> # binutils added all except Zvkb, then added Zvkb. So we just check for Zvkb.
> config TOOLCHAIN_HAS_VECTOR_CRYPTO
> - def_bool $(as-instr, .option arch$(comma) +zvkb)
> + def_bool $(as-instr, .option arch$(comma) +v$(comma) +zvkb)
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_ZBB
> bool "Zbb extension support for bit manipulation instructions"
> depends on TOOLCHAIN_HAS_ZBB
> depends on MMU
> depends on RISCV_ALTERNATIVE
> default y
> help
> Adds support to dynamically detect the presence of the ZBB
>
> base-commit: cb4ede926134a65bc3bf90ed58dace8451d7e759
> --
> 2.43.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [relevance 99%]
* Re: CBL issue 1984 - AMD64 segfault during LTO building linux-6.7.0 with clang-17.0.6
@ 2024-01-29 20:35 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-29 20:35 UTC (permalink / raw)
To: Sedat Dilek; +Cc: Nick Desaulniers, llvm
Hi Sedat,
Good to hear from you as always!
On Mon, Jan 29, 2024 at 12:43:36PM +0100, Sedat Dilek wrote:
> With upcoming Linux v6.7.3 I wanted to jump into building
> clang-thinlto / clang-kcfi kernels again.
>
> How severe is the bug in #1984?
> Only hitable with special kbuild settings?
I believe that issue is only hittable with CONFIG_ZERO_CALL_USED_REGS=y,
so without that selected, you should be fine.
> Nathan, can you provide a 17.0.x LLVM toolchain with [3] applied?
> Maybe in [4] - in an unofficial sub-folder?
> AFAICS, there will be no v17.0.7.
My build framework for the kernel.org toolchains does not currently have
support for applying patches, it only has support for checking out
specific upstream revisions of LLVM (for both simplicity and ideological
reasons). I have considered supporting patching bugs in unsupported LLVM
versions but I don't really think that is a direction that I want to go,
at least at the present time. LLVM 18.0.0-rc1 should be coming out very
soon, at which point I will build and upload that for testing. If you
want to stick with LLVM 17.x, the workaround for avoiding that issue is
pretty simple.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.0-rc1 uploaded
@ 2024-01-30 14:57 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-30 14:57 UTC (permalink / raw)
To: llvm, linux-kernel
Hi all,
I have built and uploaded a prebuilt version of LLVM 18.1.0-rc1 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
As with Linux -rc releases, this is not the final version that will
ship. If you run across any issues, especially ones that were not
present in earlier LLVM releases, please consider reporting them to us
so that we have a chance to investigate and fix them before the final
release.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 09/10] workqueue: Implement system-wide nr_active enforcement for unbound workqueues
@ 2024-01-31 4:12 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-01-31 4:12 UTC (permalink / raw)
To: Tejun Heo
Cc: Marek Szyprowski, Lai Jiangshan, linux-kernel, Naohiro.Aota, kernel-team
Hi Tejun,
On Tue, Jan 30, 2024 at 06:02:52PM -1000, Tejun Heo wrote:
> Hello,
>
> Thanks for the report. Can you please test whether the following patch fixes
> the problem?
I just tested this change on top of 5797b1c18919 but it does not appear
to resolve the issue for any of the three configurations that I tested.
Cheers,
Nathan
> ----- 8< -----
> From: Tejun Heo <tj@kernel.org>
> Subject: workqueue: Fix crash due to premature NUMA topology access on some archs
>
> System workqueues are allocated early during boot from
> workqueue_init_early(). While allocating unbound workqueues,
> wq_update_node_max_active() is invoked from apply_workqueue_attrs() and
> accesses NUMA topology information - cpumask_of_node() and cpu_to_node().
>
> At this point, topology information is not initialized yet and on arm and
> some other archs, it leads to an oops like the following:
>
> Unable to handle kernel paging request at virtual address ffff0002100296e0
> Mem abort info:
> ESR = 0x0000000096000005
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x05: level 1 translation fault
> Data abort info:
> ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000255a000
> [ffff0002100296e0] pgd=18000001ffff7003, p4d=18000001ffff7003,
> pud=0000000000000000
> Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.8.0-rc2-next-20240130+ #14392
> Hardware name: Hardkernel ODROID-M1 (DT)
> pstate: 600000c9 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : wq_update_node_max_active+0x50/0x1fc
> lr : wq_update_node_max_active+0x1f0/0x1fc
> ...
> Call trace:
> wq_update_node_max_active+0x50/0x1fc
> apply_wqattrs_commit+0xf0/0x114
> apply_workqueue_attrs_locked+0x58/0xa0
> alloc_workqueue+0x5ac/0x774
> workqueue_init_early+0x460/0x540
> start_kernel+0x258/0x684
> __primary_switched+0xb8/0xc0
> Code: 9100a273 35000d01 53067f00 d0016dc1 (f8607a60)
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
>
> Fix it by initializing wq->node_nr_active[].max to WQ_DFL_MIN_ACTIVE on
> allocation and making wq_update_node_max_active() noop until
> workqueue_init_topology(). Note that workqueue_init_topology() invokes
> wq_update_node_max_active() on all unbound workqueues, so the end result is
> still the same.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Link: http://lkml.kernel.org/r/91eacde0-df99-4d5c-a980-91046f66e612@samsung.com
> Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
> ---
> kernel/workqueue.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 9221a4c57ae1..a65081ec6780 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -386,6 +386,8 @@ static const char *wq_affn_names[WQ_AFFN_NR_TYPES] = {
> [WQ_AFFN_SYSTEM] = "system",
> };
>
> +static bool wq_topo_initialized = false;
> +
> /*
> * Per-cpu work items which run for longer than the following threshold are
> * automatically considered CPU intensive and excluded from concurrency
> @@ -1510,6 +1512,9 @@ static void wq_update_node_max_active(struct workqueue_struct *wq, int off_cpu)
>
> lockdep_assert_held(&wq->mutex);
>
> + if (!wq_topo_initialized)
> + return;
> +
> if (!cpumask_test_cpu(off_cpu, effective))
> off_cpu = -1;
>
> @@ -4356,6 +4361,7 @@ static void free_node_nr_active(struct wq_node_nr_active **nna_ar)
>
> static void init_node_nr_active(struct wq_node_nr_active *nna)
> {
> + nna->max = WQ_DFL_MIN_ACTIVE;
> atomic_set(&nna->nr, 0);
> raw_spin_lock_init(&nna->lock);
> INIT_LIST_HEAD(&nna->pending_pwqs);
> @@ -7400,6 +7406,8 @@ void __init workqueue_init_topology(void)
> init_pod_type(&wq_pod_types[WQ_AFFN_CACHE], cpus_share_cache);
> init_pod_type(&wq_pod_types[WQ_AFFN_NUMA], cpus_share_numa);
>
> + wq_topo_initialized = true;
> +
> mutex_lock(&wq_pool_mutex);
>
> /*
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 09/10] workqueue: Implement system-wide nr_active enforcement for unbound workqueues
@ 2024-01-31 4:42 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-31 4:42 UTC (permalink / raw)
To: Tejun Heo
Cc: Marek Szyprowski, Lai Jiangshan, linux-kernel, Naohiro.Aota, kernel-team
On Tue, Jan 30, 2024 at 06:24:51PM -1000, Tejun Heo wrote:
> On Tue, Jan 30, 2024 at 09:20:31PM -0700, Nathan Chancellor wrote:
> > On Tue, Jan 30, 2024 at 06:13:02PM -1000, Tejun Heo wrote:
> > > On Tue, Jan 30, 2024 at 09:12:05PM -0700, Nathan Chancellor wrote:
> > > > Hi Tejun,
> > > >
> > > > On Tue, Jan 30, 2024 at 06:02:52PM -1000, Tejun Heo wrote:
> > > > > Hello,
> > > > >
> > > > > Thanks for the report. Can you please test whether the following patch fixes
> > > > > the problem?
> > > >
> > > > I just tested this change on top of 5797b1c18919 but it does not appear
> > > > to resolve the issue for any of the three configurations that I tested.
> > >
> > > Bummer. Can you map the faulting address to the source line?
> >
> > Sure, here is the arm64 stacktrace run through
> > scripts/decode_stacktrace.sh, the line numbers correspond to your tree
> > at 5797b1c18919.
>
> Ah, I see. How about the following?
>
> Thanks.
That works for three easy to test configurations that were broken,
thanks!
Tested-by: Nathan Chancellor <nathan@kernel.org>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 9221a4c57ae1..31c1373505d8 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1510,7 +1510,7 @@ static void wq_update_node_max_active(struct workqueue_struct *wq, int off_cpu)
>
> lockdep_assert_held(&wq->mutex);
>
> - if (!cpumask_test_cpu(off_cpu, effective))
> + if (off_cpu >= 0 && !cpumask_test_cpu(off_cpu, effective))
> off_cpu = -1;
>
> total_cpus = cpumask_weight_and(effective, cpu_online_mask);
>
> --
> tejun
^ permalink raw reply [relevance 99%]
* LLVM 18 -> 19 transition missing from apt.llvm.org unstable
@ 2024-01-31 17:44 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-31 17:44 UTC (permalink / raw)
To: sylvestre; +Cc: llvm
Hi Sylvestre,
I noticed that the main branch's transition from LLVM 18 to 19 has not
showed up in apt.llvm.org's unstable distribution. It seems like the
last build happened a week ago. Apologies if this has already been
reported or is already known.
This caused issues for the TuxMake folks because they use unstable as a
base for their RISC-V container due to the acceptance of RISC-V as an
officially supported architecture there but Bullseye for all other
architectures, so the -19 packages were installable in Bullseye but not
unstable.
https://gitlab.com/Linaro/tuxmake/-/commit/03a8658a53f899f0d92307a47fd33c7b070dcfa6
https://gitlab.com/Linaro/tuxmake/-/commit/f684ca4ddc9b655e705f5ca7a3fa01efa55b60f4
Their workaround will break our CI because we test RISC-V there, so it
would be nice to get this addressed so that our testing does not suffer
for long.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] crypto: virtio/akcipher - Fix stack overflow on memcpy
@ 2024-01-31 19:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-01-31 19:10 UTC (permalink / raw)
To: zhenwei pi
Cc: arei.gonglei, mst, jasowang, herbert, xuanzhuo, virtualization,
linux-crypto, linux-kernel, davem
On Tue, Jan 30, 2024 at 07:27:40PM +0800, zhenwei pi wrote:
> sizeof(struct virtio_crypto_akcipher_session_para) is less than
> sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from
> stack variable leads stack overflow. Clang reports this issue by
> commands:
> make -j CC=clang-14 mrproper >/dev/null 2>&1
> make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1
> make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/
> virtio_crypto_akcipher_algs.o
>
> Fixes: 59ca6c93387d ("virtio-crypto: implement RSA algorithm")
> Link: https://lore.kernel.org/all/0a194a79-e3a3-45e7-be98-83abd3e1cb7e@roeck-us.net/
> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
I can confirm this resolves the warning for me as well.
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
I suspect Guenter should have a formal Reported-by tag. Should this be
CC'd for stable@ as well?
Cheers,
Nathan
> ---
> drivers/crypto/virtio/virtio_crypto_akcipher_algs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c b/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> index 2621ff8a9376..de53eddf6796 100644
> --- a/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> +++ b/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> @@ -104,7 +104,8 @@ static void virtio_crypto_dataq_akcipher_callback(struct virtio_crypto_request *
> }
>
> static int virtio_crypto_alg_akcipher_init_session(struct virtio_crypto_akcipher_ctx *ctx,
> - struct virtio_crypto_ctrl_header *header, void *para,
> + struct virtio_crypto_ctrl_header *header,
> + struct virtio_crypto_akcipher_session_para *para,
> const uint8_t *key, unsigned int keylen)
> {
> struct scatterlist outhdr_sg, key_sg, inhdr_sg, *sgs[3];
> @@ -128,7 +129,7 @@ static int virtio_crypto_alg_akcipher_init_session(struct virtio_crypto_akcipher
>
> ctrl = &vc_ctrl_req->ctrl;
> memcpy(&ctrl->header, header, sizeof(ctrl->header));
> - memcpy(&ctrl->u, para, sizeof(ctrl->u));
> + memcpy(&ctrl->u.akcipher_create_session.para, para, sizeof(*para));
> input = &vc_ctrl_req->input;
> input->status = cpu_to_le32(VIRTIO_CRYPTO_ERR);
>
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/3] media: pci: sta2x11: Fix Wcast-function-type-strict warnings
@ 2024-02-01 22:08 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-01 22:08 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Nick Desaulniers, Bill Wendling,
Justin Stitt, Mike Isely, Tiffany Lin, Andrew-CT Chen,
Yunfei Dong, Matthias Brugger, AngeloGioacchino Del Regno,
linux-media, linux-kernel, llvm, linux-arm-kernel,
linux-mediatek
On Sun, Jan 28, 2024 at 02:12:20AM +0000, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: warning: cast from 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Wcast-function-type-strict]
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I wonder if the media tree cares about reverse Christmas tree order for
variables?
> ---
> drivers/media/pci/sta2x11/sta2x11_vip.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c b/drivers/media/pci/sta2x11/sta2x11_vip.c
> index e4cf9d63e926..0a3827575753 100644
> --- a/drivers/media/pci/sta2x11/sta2x11_vip.c
> +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
> @@ -757,7 +757,7 @@ static const struct video_device video_dev_template = {
> /**
> * vip_irq - interrupt routine
> * @irq: Number of interrupt ( not used, correct number is assumed )
> - * @vip: local data structure containing all information
> + * @data: local data structure containing all information
> *
> * check for both frame interrupts set ( top and bottom ).
> * check FIFO overflow, but limit number of log messages after open.
> @@ -767,9 +767,10 @@ static const struct video_device video_dev_template = {
> *
> * IRQ_HANDLED, interrupt done.
> */
> -static irqreturn_t vip_irq(int irq, struct sta2x11_vip *vip)
> +static irqreturn_t vip_irq(int irq, void *data)
> {
> unsigned int status;
> + struct sta2x11_vip *vip = data;
>
> status = reg_read(vip, DVP_ITS);
>
>
> --
> 2.43.0.429.g432eaa2c6b-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/3] media: pci: sta2x11: Fix Wcast-function-type-strict warnings
@ 2024-02-01 22:08 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-01 22:08 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Nick Desaulniers, Bill Wendling,
Justin Stitt, Mike Isely, Tiffany Lin, Andrew-CT Chen,
Yunfei Dong, Matthias Brugger, AngeloGioacchino Del Regno,
linux-media, linux-kernel, llvm, linux-arm-kernel,
linux-mediatek
On Sun, Jan 28, 2024 at 02:12:20AM +0000, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: warning: cast from 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Wcast-function-type-strict]
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I wonder if the media tree cares about reverse Christmas tree order for
variables?
> ---
> drivers/media/pci/sta2x11/sta2x11_vip.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c b/drivers/media/pci/sta2x11/sta2x11_vip.c
> index e4cf9d63e926..0a3827575753 100644
> --- a/drivers/media/pci/sta2x11/sta2x11_vip.c
> +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
> @@ -757,7 +757,7 @@ static const struct video_device video_dev_template = {
> /**
> * vip_irq - interrupt routine
> * @irq: Number of interrupt ( not used, correct number is assumed )
> - * @vip: local data structure containing all information
> + * @data: local data structure containing all information
> *
> * check for both frame interrupts set ( top and bottom ).
> * check FIFO overflow, but limit number of log messages after open.
> @@ -767,9 +767,10 @@ static const struct video_device video_dev_template = {
> *
> * IRQ_HANDLED, interrupt done.
> */
> -static irqreturn_t vip_irq(int irq, struct sta2x11_vip *vip)
> +static irqreturn_t vip_irq(int irq, void *data)
> {
> unsigned int status;
> + struct sta2x11_vip *vip = data;
>
> status = reg_read(vip, DVP_ITS);
>
>
> --
> 2.43.0.429.g432eaa2c6b-goog
>
_______________________________________________
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: [PATCH 2/3] media: usb: pvrusb2: Fix Wcast-function-type-strict warnings
@ 2024-02-01 22:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-01 22:09 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Nick Desaulniers, Bill Wendling,
Justin Stitt, Mike Isely, Tiffany Lin, Andrew-CT Chen,
Yunfei Dong, Matthias Brugger, AngeloGioacchino Del Regno,
linux-media, linux-kernel, llvm, linux-arm-kernel,
linux-mediatek
On Sun, Jan 28, 2024 at 02:12:21AM +0000, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/usb/pvrusb2/pvrusb2-context.c:110:6: warning: cast from 'void (*)(struct pvr2_context *)' to 'void (*)(void *)' converts to incompatible function type [-Wcast-function-type-strict]
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:1070:30: warning: cast from 'void (*)(struct pvr2_v4l2_fh *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] drivers/media/usb/pvrusb2/pvrusb2-dvb.c:152:6: warning: cast from 'void (*)(struct pvr2_dvb_adapter *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict]
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/media/usb/pvrusb2/pvrusb2-context.c | 5 +++--
> drivers/media/usb/pvrusb2/pvrusb2-dvb.c | 7 ++++---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 7 ++++---
> 3 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-context.c b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> index 1764674de98b..16edabda191c 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-context.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> @@ -90,8 +90,9 @@ static void pvr2_context_destroy(struct pvr2_context *mp)
> }
>
>
> -static void pvr2_context_notify(struct pvr2_context *mp)
> +static void pvr2_context_notify(void *data)
> {
> + struct pvr2_context *mp = data;
> pvr2_context_set_notify(mp,!0);
> }
>
> @@ -107,7 +108,7 @@ static void pvr2_context_check(struct pvr2_context *mp)
> "pvr2_context %p (initialize)", mp);
> /* Finish hardware initialization */
> if (pvr2_hdw_initialize(mp->hdw,
> - (void (*)(void *))pvr2_context_notify,
> + pvr2_context_notify,
> mp)) {
> mp->video_stream.stream =
> pvr2_hdw_get_video_stream(mp->hdw);
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> index 26811efe0fb5..8b9f1a09bd53 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> @@ -88,8 +88,9 @@ static int pvr2_dvb_feed_thread(void *data)
> return stat;
> }
>
> -static void pvr2_dvb_notify(struct pvr2_dvb_adapter *adap)
> +static void pvr2_dvb_notify(void *data)
> {
> + struct pvr2_dvb_adapter *adap = data;
> wake_up(&adap->buffer_wait_data);
> }
>
> @@ -148,8 +149,8 @@ static int pvr2_dvb_stream_do_start(struct pvr2_dvb_adapter *adap)
> if (!(adap->buffer_storage[idx])) return -ENOMEM;
> }
>
> - pvr2_stream_set_callback(pvr->video_stream.stream,
> - (pvr2_stream_callback) pvr2_dvb_notify, adap);
> + pvr2_stream_set_callback(pvr->video_stream.stream, pvr2_dvb_notify,
> + adap);
>
> ret = pvr2_stream_set_buffer_count(stream, PVR2_DVB_BUFFER_COUNT);
> if (ret < 0) return ret;
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index c04ab7258d64..590f80949bbf 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -1032,9 +1032,10 @@ static int pvr2_v4l2_open(struct file *file)
> return 0;
> }
>
> -
> -static void pvr2_v4l2_notify(struct pvr2_v4l2_fh *fhp)
> +static void pvr2_v4l2_notify(void *data)
> {
> + struct pvr2_v4l2_fh *fhp = data;
> +
> wake_up(&fhp->wait_data);
> }
>
> @@ -1067,7 +1068,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
>
> hdw = fh->channel.mc_head->hdw;
> sp = fh->pdi->stream->stream;
> - pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
> + pvr2_stream_set_callback(sp, pvr2_v4l2_notify, fh);
> pvr2_hdw_set_stream_type(hdw,fh->pdi->config);
> if ((ret = pvr2_hdw_set_streaming(hdw,!0)) < 0) return ret;
> return pvr2_ioread_set_enabled(fh->rhp,!0);
>
> --
> 2.43.0.429.g432eaa2c6b-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/3] media: usb: pvrusb2: Fix Wcast-function-type-strict warnings
@ 2024-02-01 22:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-01 22:09 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Nick Desaulniers, Bill Wendling,
Justin Stitt, Mike Isely, Tiffany Lin, Andrew-CT Chen,
Yunfei Dong, Matthias Brugger, AngeloGioacchino Del Regno,
linux-media, linux-kernel, llvm, linux-arm-kernel,
linux-mediatek
On Sun, Jan 28, 2024 at 02:12:21AM +0000, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/usb/pvrusb2/pvrusb2-context.c:110:6: warning: cast from 'void (*)(struct pvr2_context *)' to 'void (*)(void *)' converts to incompatible function type [-Wcast-function-type-strict]
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:1070:30: warning: cast from 'void (*)(struct pvr2_v4l2_fh *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] drivers/media/usb/pvrusb2/pvrusb2-dvb.c:152:6: warning: cast from 'void (*)(struct pvr2_dvb_adapter *)' to 'pvr2_stream_callback' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict]
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/media/usb/pvrusb2/pvrusb2-context.c | 5 +++--
> drivers/media/usb/pvrusb2/pvrusb2-dvb.c | 7 ++++---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 7 ++++---
> 3 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-context.c b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> index 1764674de98b..16edabda191c 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-context.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> @@ -90,8 +90,9 @@ static void pvr2_context_destroy(struct pvr2_context *mp)
> }
>
>
> -static void pvr2_context_notify(struct pvr2_context *mp)
> +static void pvr2_context_notify(void *data)
> {
> + struct pvr2_context *mp = data;
> pvr2_context_set_notify(mp,!0);
> }
>
> @@ -107,7 +108,7 @@ static void pvr2_context_check(struct pvr2_context *mp)
> "pvr2_context %p (initialize)", mp);
> /* Finish hardware initialization */
> if (pvr2_hdw_initialize(mp->hdw,
> - (void (*)(void *))pvr2_context_notify,
> + pvr2_context_notify,
> mp)) {
> mp->video_stream.stream =
> pvr2_hdw_get_video_stream(mp->hdw);
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> index 26811efe0fb5..8b9f1a09bd53 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> @@ -88,8 +88,9 @@ static int pvr2_dvb_feed_thread(void *data)
> return stat;
> }
>
> -static void pvr2_dvb_notify(struct pvr2_dvb_adapter *adap)
> +static void pvr2_dvb_notify(void *data)
> {
> + struct pvr2_dvb_adapter *adap = data;
> wake_up(&adap->buffer_wait_data);
> }
>
> @@ -148,8 +149,8 @@ static int pvr2_dvb_stream_do_start(struct pvr2_dvb_adapter *adap)
> if (!(adap->buffer_storage[idx])) return -ENOMEM;
> }
>
> - pvr2_stream_set_callback(pvr->video_stream.stream,
> - (pvr2_stream_callback) pvr2_dvb_notify, adap);
> + pvr2_stream_set_callback(pvr->video_stream.stream, pvr2_dvb_notify,
> + adap);
>
> ret = pvr2_stream_set_buffer_count(stream, PVR2_DVB_BUFFER_COUNT);
> if (ret < 0) return ret;
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index c04ab7258d64..590f80949bbf 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -1032,9 +1032,10 @@ static int pvr2_v4l2_open(struct file *file)
> return 0;
> }
>
> -
> -static void pvr2_v4l2_notify(struct pvr2_v4l2_fh *fhp)
> +static void pvr2_v4l2_notify(void *data)
> {
> + struct pvr2_v4l2_fh *fhp = data;
> +
> wake_up(&fhp->wait_data);
> }
>
> @@ -1067,7 +1068,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
>
> hdw = fh->channel.mc_head->hdw;
> sp = fh->pdi->stream->stream;
> - pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
> + pvr2_stream_set_callback(sp, pvr2_v4l2_notify, fh);
> pvr2_hdw_set_stream_type(hdw,fh->pdi->config);
> if ((ret = pvr2_hdw_set_streaming(hdw,!0)) < 0) return ret;
> return pvr2_ioread_set_enabled(fh->rhp,!0);
>
> --
> 2.43.0.429.g432eaa2c6b-goog
>
_______________________________________________
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: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope
2024-02-03 0:17 99% ` Nathan Chancellor
(?)
@ 2024-02-03 0:17 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-03 0:17 UTC (permalink / raw)
To: Baoquan He
Cc: kexec, akpm, linux-kernel, x86, linux-arm-kernel, linuxppc-dev,
linux-s390, mhklinux
This series resolves the build issues I was seeing. Please feel free to
carry
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
forward if there are any more revisions without drastic changes.
On Mon, Jan 29, 2024 at 09:50:31PM +0800, Baoquan He wrote:
> Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> arch/x86/xen/enlighten_hvm.c.
>
> Although the nesting works well too since CONFIG_CRASH_DUMP has
> dependency on CONFIG_KEXEC_CORE, it may cause confuse because there
> are places where it's not nested, and people may think it need be nested
> even though it doesn't have to.
>
> Fix that by moving CONFIG_CRASH_DUMP ifdeffery of codes out of
> CONFIG_KEXEC_CODE ifdeffery scope.
>
> And also fix a building error Nathan reported as below by replacing
> CONFIG_KEXEC_CORE ifdef with CONFIG_VMCORE_INFO ifdef.
>
> ====
> $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.x86_64
> $ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- olddefconfig all
> ...
> x86_64-linux-ld: arch/x86/xen/mmu_pv.o: in function `paddr_vmcoreinfo_note':
> mmu_pv.c:(.text+0x3af3): undefined reference to `vmcoreinfo_note'
> ====
>
> Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
> Link: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#u
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 10 ++++++----
> arch/x86/kernel/reboot.c | 2 +-
> arch/x86/xen/enlighten_hvm.c | 4 ++--
> arch/x86/xen/mmu_pv.c | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f8163a59026b..2e8cd5a4ae85 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -209,6 +209,7 @@ static void hv_machine_shutdown(void)
> if (kexec_in_progress)
> hyperv_cleanup();
> }
> +#endif /* CONFIG_KEXEC_CORE */
>
> #ifdef CONFIG_CRASH_DUMP
> static void hv_machine_crash_shutdown(struct pt_regs *regs)
> @@ -222,8 +223,7 @@ static void hv_machine_crash_shutdown(struct pt_regs *regs)
> /* Disable the hypercall page when there is only 1 active CPU. */
> hyperv_cleanup();
> }
> -#endif
> -#endif /* CONFIG_KEXEC_CORE */
> +#endif /* CONFIG_CRASH_DUMP */
> #endif /* CONFIG_HYPERV */
>
> static uint32_t __init ms_hyperv_platform(void)
> @@ -497,9 +497,11 @@ static void __init ms_hyperv_init_platform(void)
> no_timer_check = 1;
> #endif
>
> -#if IS_ENABLED(CONFIG_HYPERV) && defined(CONFIG_KEXEC_CORE)
> +#if IS_ENABLED(CONFIG_HYPERV)
> +#if defined(CONFIG_KEXEC_CORE)
> machine_ops.shutdown = hv_machine_shutdown;
> -#ifdef CONFIG_CRASH_DUMP
> +#endif
> +#if defined(CONFIG_CRASH_DUMP)
> machine_ops.crash_shutdown = hv_machine_crash_shutdown;
> #endif
> #endif
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 1287b0d5962f..f3130f762784 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -826,7 +826,7 @@ void machine_halt(void)
> machine_ops.halt();
> }
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
> void machine_crash_shutdown(struct pt_regs *regs)
> {
> machine_ops.crash_shutdown(regs);
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 09e3db7ff990..0b367c1e086d 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -148,6 +148,7 @@ static void xen_hvm_shutdown(void)
> if (kexec_in_progress)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> +#endif
>
> #ifdef CONFIG_CRASH_DUMP
> static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> @@ -156,7 +157,6 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> #endif
> -#endif
>
> static int xen_cpu_up_prepare_hvm(unsigned int cpu)
> {
> @@ -238,10 +238,10 @@ static void __init xen_hvm_guest_init(void)
>
> #ifdef CONFIG_KEXEC_CORE
> machine_ops.shutdown = xen_hvm_shutdown;
> +#endif
> #ifdef CONFIG_CRASH_DUMP
> machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
> #endif
> -#endif
> }
>
> static __init int xen_parse_nopv(char *arg)
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 218773cfb009..e21974f2cf2d 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2520,7 +2520,7 @@ int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL_GPL(xen_remap_pfn);
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_VMCORE_INFO
> phys_addr_t paddr_vmcoreinfo_note(void)
> {
> if (xen_pv_domain())
> --
> 2.41.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope
@ 2024-02-03 0:17 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-03 0:17 UTC (permalink / raw)
To: Baoquan He
Cc: kexec, akpm, linux-kernel, x86, linux-arm-kernel, linuxppc-dev,
linux-s390, mhklinux
This series resolves the build issues I was seeing. Please feel free to
carry
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
forward if there are any more revisions without drastic changes.
On Mon, Jan 29, 2024 at 09:50:31PM +0800, Baoquan He wrote:
> Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> arch/x86/xen/enlighten_hvm.c.
>
> Although the nesting works well too since CONFIG_CRASH_DUMP has
> dependency on CONFIG_KEXEC_CORE, it may cause confuse because there
> are places where it's not nested, and people may think it need be nested
> even though it doesn't have to.
>
> Fix that by moving CONFIG_CRASH_DUMP ifdeffery of codes out of
> CONFIG_KEXEC_CODE ifdeffery scope.
>
> And also fix a building error Nathan reported as below by replacing
> CONFIG_KEXEC_CORE ifdef with CONFIG_VMCORE_INFO ifdef.
>
> ====
> $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.x86_64
> $ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- olddefconfig all
> ...
> x86_64-linux-ld: arch/x86/xen/mmu_pv.o: in function `paddr_vmcoreinfo_note':
> mmu_pv.c:(.text+0x3af3): undefined reference to `vmcoreinfo_note'
> ====
>
> Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
> Link: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#u
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 10 ++++++----
> arch/x86/kernel/reboot.c | 2 +-
> arch/x86/xen/enlighten_hvm.c | 4 ++--
> arch/x86/xen/mmu_pv.c | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f8163a59026b..2e8cd5a4ae85 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -209,6 +209,7 @@ static void hv_machine_shutdown(void)
> if (kexec_in_progress)
> hyperv_cleanup();
> }
> +#endif /* CONFIG_KEXEC_CORE */
>
> #ifdef CONFIG_CRASH_DUMP
> static void hv_machine_crash_shutdown(struct pt_regs *regs)
> @@ -222,8 +223,7 @@ static void hv_machine_crash_shutdown(struct pt_regs *regs)
> /* Disable the hypercall page when there is only 1 active CPU. */
> hyperv_cleanup();
> }
> -#endif
> -#endif /* CONFIG_KEXEC_CORE */
> +#endif /* CONFIG_CRASH_DUMP */
> #endif /* CONFIG_HYPERV */
>
> static uint32_t __init ms_hyperv_platform(void)
> @@ -497,9 +497,11 @@ static void __init ms_hyperv_init_platform(void)
> no_timer_check = 1;
> #endif
>
> -#if IS_ENABLED(CONFIG_HYPERV) && defined(CONFIG_KEXEC_CORE)
> +#if IS_ENABLED(CONFIG_HYPERV)
> +#if defined(CONFIG_KEXEC_CORE)
> machine_ops.shutdown = hv_machine_shutdown;
> -#ifdef CONFIG_CRASH_DUMP
> +#endif
> +#if defined(CONFIG_CRASH_DUMP)
> machine_ops.crash_shutdown = hv_machine_crash_shutdown;
> #endif
> #endif
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 1287b0d5962f..f3130f762784 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -826,7 +826,7 @@ void machine_halt(void)
> machine_ops.halt();
> }
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
> void machine_crash_shutdown(struct pt_regs *regs)
> {
> machine_ops.crash_shutdown(regs);
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 09e3db7ff990..0b367c1e086d 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -148,6 +148,7 @@ static void xen_hvm_shutdown(void)
> if (kexec_in_progress)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> +#endif
>
> #ifdef CONFIG_CRASH_DUMP
> static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> @@ -156,7 +157,6 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> #endif
> -#endif
>
> static int xen_cpu_up_prepare_hvm(unsigned int cpu)
> {
> @@ -238,10 +238,10 @@ static void __init xen_hvm_guest_init(void)
>
> #ifdef CONFIG_KEXEC_CORE
> machine_ops.shutdown = xen_hvm_shutdown;
> +#endif
> #ifdef CONFIG_CRASH_DUMP
> machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
> #endif
> -#endif
> }
>
> static __init int xen_parse_nopv(char *arg)
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 218773cfb009..e21974f2cf2d 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2520,7 +2520,7 @@ int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL_GPL(xen_remap_pfn);
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_VMCORE_INFO
> phys_addr_t paddr_vmcoreinfo_note(void)
> {
> if (xen_pv_domain())
> --
> 2.41.0
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [relevance 99%]
* Re: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope
@ 2024-02-03 0:17 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-03 0:17 UTC (permalink / raw)
To: Baoquan He
Cc: kexec, akpm, linux-kernel, x86, linux-arm-kernel, linuxppc-dev,
linux-s390, mhklinux
This series resolves the build issues I was seeing. Please feel free to
carry
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
forward if there are any more revisions without drastic changes.
On Mon, Jan 29, 2024 at 09:50:31PM +0800, Baoquan He wrote:
> Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> arch/x86/xen/enlighten_hvm.c.
>
> Although the nesting works well too since CONFIG_CRASH_DUMP has
> dependency on CONFIG_KEXEC_CORE, it may cause confuse because there
> are places where it's not nested, and people may think it need be nested
> even though it doesn't have to.
>
> Fix that by moving CONFIG_CRASH_DUMP ifdeffery of codes out of
> CONFIG_KEXEC_CODE ifdeffery scope.
>
> And also fix a building error Nathan reported as below by replacing
> CONFIG_KEXEC_CORE ifdef with CONFIG_VMCORE_INFO ifdef.
>
> ====
> $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.x86_64
> $ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- olddefconfig all
> ...
> x86_64-linux-ld: arch/x86/xen/mmu_pv.o: in function `paddr_vmcoreinfo_note':
> mmu_pv.c:(.text+0x3af3): undefined reference to `vmcoreinfo_note'
> ====
>
> Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
> Link: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#u
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 10 ++++++----
> arch/x86/kernel/reboot.c | 2 +-
> arch/x86/xen/enlighten_hvm.c | 4 ++--
> arch/x86/xen/mmu_pv.c | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f8163a59026b..2e8cd5a4ae85 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -209,6 +209,7 @@ static void hv_machine_shutdown(void)
> if (kexec_in_progress)
> hyperv_cleanup();
> }
> +#endif /* CONFIG_KEXEC_CORE */
>
> #ifdef CONFIG_CRASH_DUMP
> static void hv_machine_crash_shutdown(struct pt_regs *regs)
> @@ -222,8 +223,7 @@ static void hv_machine_crash_shutdown(struct pt_regs *regs)
> /* Disable the hypercall page when there is only 1 active CPU. */
> hyperv_cleanup();
> }
> -#endif
> -#endif /* CONFIG_KEXEC_CORE */
> +#endif /* CONFIG_CRASH_DUMP */
> #endif /* CONFIG_HYPERV */
>
> static uint32_t __init ms_hyperv_platform(void)
> @@ -497,9 +497,11 @@ static void __init ms_hyperv_init_platform(void)
> no_timer_check = 1;
> #endif
>
> -#if IS_ENABLED(CONFIG_HYPERV) && defined(CONFIG_KEXEC_CORE)
> +#if IS_ENABLED(CONFIG_HYPERV)
> +#if defined(CONFIG_KEXEC_CORE)
> machine_ops.shutdown = hv_machine_shutdown;
> -#ifdef CONFIG_CRASH_DUMP
> +#endif
> +#if defined(CONFIG_CRASH_DUMP)
> machine_ops.crash_shutdown = hv_machine_crash_shutdown;
> #endif
> #endif
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 1287b0d5962f..f3130f762784 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -826,7 +826,7 @@ void machine_halt(void)
> machine_ops.halt();
> }
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
> void machine_crash_shutdown(struct pt_regs *regs)
> {
> machine_ops.crash_shutdown(regs);
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 09e3db7ff990..0b367c1e086d 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -148,6 +148,7 @@ static void xen_hvm_shutdown(void)
> if (kexec_in_progress)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> +#endif
>
> #ifdef CONFIG_CRASH_DUMP
> static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> @@ -156,7 +157,6 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> #endif
> -#endif
>
> static int xen_cpu_up_prepare_hvm(unsigned int cpu)
> {
> @@ -238,10 +238,10 @@ static void __init xen_hvm_guest_init(void)
>
> #ifdef CONFIG_KEXEC_CORE
> machine_ops.shutdown = xen_hvm_shutdown;
> +#endif
> #ifdef CONFIG_CRASH_DUMP
> machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
> #endif
> -#endif
> }
>
> static __init int xen_parse_nopv(char *arg)
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 218773cfb009..e21974f2cf2d 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2520,7 +2520,7 @@ int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL_GPL(xen_remap_pfn);
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_VMCORE_INFO
> phys_addr_t paddr_vmcoreinfo_note(void)
> {
> if (xen_pv_domain())
> --
> 2.41.0
>
_______________________________________________
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: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope
@ 2024-02-03 0:17 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-03 0:17 UTC (permalink / raw)
To: Baoquan He
Cc: linux-s390, mhklinux, x86, kexec, linux-kernel, akpm,
linuxppc-dev, linux-arm-kernel
This series resolves the build issues I was seeing. Please feel free to
carry
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
forward if there are any more revisions without drastic changes.
On Mon, Jan 29, 2024 at 09:50:31PM +0800, Baoquan He wrote:
> Michael pointed out that the #ifdef CONFIG_CRASH_DUMP is nested inside
> arch/x86/xen/enlighten_hvm.c.
>
> Although the nesting works well too since CONFIG_CRASH_DUMP has
> dependency on CONFIG_KEXEC_CORE, it may cause confuse because there
> are places where it's not nested, and people may think it need be nested
> even though it doesn't have to.
>
> Fix that by moving CONFIG_CRASH_DUMP ifdeffery of codes out of
> CONFIG_KEXEC_CODE ifdeffery scope.
>
> And also fix a building error Nathan reported as below by replacing
> CONFIG_KEXEC_CORE ifdef with CONFIG_VMCORE_INFO ifdef.
>
> ====
> $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.x86_64
> $ make -skj"$(nproc)" ARCH=x86_64 CROSS_COMPILE=x86_64-linux- olddefconfig all
> ...
> x86_64-linux-ld: arch/x86/xen/mmu_pv.o: in function `paddr_vmcoreinfo_note':
> mmu_pv.c:(.text+0x3af3): undefined reference to `vmcoreinfo_note'
> ====
>
> Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
> Link: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#u
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
> arch/x86/kernel/cpu/mshyperv.c | 10 ++++++----
> arch/x86/kernel/reboot.c | 2 +-
> arch/x86/xen/enlighten_hvm.c | 4 ++--
> arch/x86/xen/mmu_pv.c | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f8163a59026b..2e8cd5a4ae85 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -209,6 +209,7 @@ static void hv_machine_shutdown(void)
> if (kexec_in_progress)
> hyperv_cleanup();
> }
> +#endif /* CONFIG_KEXEC_CORE */
>
> #ifdef CONFIG_CRASH_DUMP
> static void hv_machine_crash_shutdown(struct pt_regs *regs)
> @@ -222,8 +223,7 @@ static void hv_machine_crash_shutdown(struct pt_regs *regs)
> /* Disable the hypercall page when there is only 1 active CPU. */
> hyperv_cleanup();
> }
> -#endif
> -#endif /* CONFIG_KEXEC_CORE */
> +#endif /* CONFIG_CRASH_DUMP */
> #endif /* CONFIG_HYPERV */
>
> static uint32_t __init ms_hyperv_platform(void)
> @@ -497,9 +497,11 @@ static void __init ms_hyperv_init_platform(void)
> no_timer_check = 1;
> #endif
>
> -#if IS_ENABLED(CONFIG_HYPERV) && defined(CONFIG_KEXEC_CORE)
> +#if IS_ENABLED(CONFIG_HYPERV)
> +#if defined(CONFIG_KEXEC_CORE)
> machine_ops.shutdown = hv_machine_shutdown;
> -#ifdef CONFIG_CRASH_DUMP
> +#endif
> +#if defined(CONFIG_CRASH_DUMP)
> machine_ops.crash_shutdown = hv_machine_crash_shutdown;
> #endif
> #endif
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index 1287b0d5962f..f3130f762784 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -826,7 +826,7 @@ void machine_halt(void)
> machine_ops.halt();
> }
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
> void machine_crash_shutdown(struct pt_regs *regs)
> {
> machine_ops.crash_shutdown(regs);
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> index 09e3db7ff990..0b367c1e086d 100644
> --- a/arch/x86/xen/enlighten_hvm.c
> +++ b/arch/x86/xen/enlighten_hvm.c
> @@ -148,6 +148,7 @@ static void xen_hvm_shutdown(void)
> if (kexec_in_progress)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> +#endif
>
> #ifdef CONFIG_CRASH_DUMP
> static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> @@ -156,7 +157,6 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs)
> xen_reboot(SHUTDOWN_soft_reset);
> }
> #endif
> -#endif
>
> static int xen_cpu_up_prepare_hvm(unsigned int cpu)
> {
> @@ -238,10 +238,10 @@ static void __init xen_hvm_guest_init(void)
>
> #ifdef CONFIG_KEXEC_CORE
> machine_ops.shutdown = xen_hvm_shutdown;
> +#endif
> #ifdef CONFIG_CRASH_DUMP
> machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
> #endif
> -#endif
> }
>
> static __init int xen_parse_nopv(char *arg)
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index 218773cfb009..e21974f2cf2d 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2520,7 +2520,7 @@ int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL_GPL(xen_remap_pfn);
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_VMCORE_INFO
> phys_addr_t paddr_vmcoreinfo_note(void)
> {
> if (xen_pv_domain())
> --
> 2.41.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/coco: Define cc_vendor without CONFIG_ARCH_HAS_CC_PLATFORM
@ 2024-02-03 19:35 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-03 19:35 UTC (permalink / raw)
To: Borislav Petkov
Cc: pbonzini, tglx, mingo, dave.hansen, x86, kirill.shutemov,
ndesaulniers, morbo, justinstitt, linux-kernel, llvm, patches
On Sat, Feb 03, 2024 at 08:07:29PM +0100, Borislav Petkov wrote:
> On Sat, Feb 03, 2024 at 09:08:06AM -0700, Nathan Chancellor wrote:
> > I have no issues with blaming a9ef277488cf but I think da86eb961184 is
> > equally blamable for removing the option to use cc_vendor in generic x86
> > code where CONFIG_ARCH_HAS_CC_PLATFORM may not be set. Hopefully that at
> > least carifies the "which is it?" question, I'll do whatever you think
> > is best.
>
> I guess I wasn't clear enough, sorry about that. Of the two, that one
Guess that makes both of us :)
> should be in Fixes which is the first one which causes the build issue
> so that the fix can be backported to the respective kernels.
>
> IOW, if you can't trigger with da86eb961184, then a9ef277488cf should be
> in Fixes and your fix should go through the KVM tree, along with
> a9ef277488cf.
>
> How does that sound?
Yeah, that seems like a fair plan to me. I was a little concerned about
a future change that would require backporting to kernels that have
da86eb961184 (i.e., 6.6) that do not have a9ef277488cf and miss this fix
but that is a bridge that can be crossed if it ever appears, no point in
thinking too hard about it at this point.
I can send a v2 on Monday, unless Paolo wants to just add
Fixes: a9ef277488cf ("x86/kvm: Fix SEV check in sev_map_percpu_data()")
directly during application. I think the rest of the patch is fine but
if there are any other changes that should be made, I am more than happy
do to so.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/2] Compiler Attributes: Add __uninitialized macro
@ 2024-02-06 1:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-06 1:28 UTC (permalink / raw)
To: Heiko Carstens
Cc: Kees Cook, Nick Desaulniers, linux-kernel, linux-s390,
Vasily Gorbik, Alexander Gordeev
On Mon, Feb 05, 2024 at 04:48:43PM +0100, Heiko Carstens wrote:
> With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled the kernel will
> be compiled with -ftrivial-auto-var-init=<...> which causes initialization
> of stack variables at function entry time.
>
> In order to avoid the performance impact that comes with this users can use
> the "uninitialized" attribute to prevent such initialization.
>
> Therefore provide the __uninitialized macro which can be used for cases
> where INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO is enabled, but only
> selected variables should not be initialized.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> include/linux/compiler_attributes.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index 28566624f008..f5859b8c68b4 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -333,6 +333,18 @@
> */
> #define __section(section) __attribute__((__section__(section)))
>
> +/*
> + * Optional: only supported since gcc >= 12
> + *
> + * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-uninitialized-variable-attribute
> + * clang: https://clang.llvm.org/docs/AttributeReference.html#uninitialized
> + */
> +#if __has_attribute(__uninitialized__)
> +# define __uninitialized __attribute__((__uninitialized__))
> +#else
> +# define __uninitialized
> +#endif
> +
> /*
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-unused-function-attribute
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#index-unused-type-attribute
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/2] s390/fpu: make use of __uninitialized macro
@ 2024-02-06 1:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-06 1:31 UTC (permalink / raw)
To: Heiko Carstens
Cc: Kees Cook, Nick Desaulniers, linux-kernel, linux-s390,
Vasily Gorbik, Alexander Gordeev
On Mon, Feb 05, 2024 at 04:48:44PM +0100, Heiko Carstens wrote:
> Code sections in s390 specific kernel code which use floating point or
> vector registers all come with a 520 byte stack variable to save already in
> use registers, if required.
>
> With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled this variable
> will always be initialized on function entry in addition to saving register
> contents, which contradicts the intend (performance improvement) of such
> code sections.
>
> Therefore provide a DECLARE_KERNEL_FPU_ONSTACK() macro which provides
> struct kernel_fpu variables with an __uninitialized attribute, and convert
> all existing code to use this.
>
> This way only this specific type of stack variable will not be initialized,
> regardless of config options.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/s390/crypto/chacha-glue.c | 2 +-
> arch/s390/crypto/crc32-vx.c | 2 +-
> arch/s390/include/asm/fpu/types.h | 3 +++
> arch/s390/kernel/sysinfo.c | 2 +-
> lib/raid6/s390vx.uc | 4 ++--
> 5 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/s390/crypto/chacha-glue.c b/arch/s390/crypto/chacha-glue.c
> index ed9959e6f714..a823132fc563 100644
> --- a/arch/s390/crypto/chacha-glue.c
> +++ b/arch/s390/crypto/chacha-glue.c
> @@ -22,7 +22,7 @@ static void chacha20_crypt_s390(u32 *state, u8 *dst, const u8 *src,
> unsigned int nbytes, const u32 *key,
> u32 *counter)
> {
> - struct kernel_fpu vxstate;
> + DECLARE_KERNEL_FPU_ONSTACK(vxstate);
>
> kernel_fpu_begin(&vxstate, KERNEL_VXR);
> chacha20_vx(dst, src, nbytes, key, counter);
> diff --git a/arch/s390/crypto/crc32-vx.c b/arch/s390/crypto/crc32-vx.c
> index 017143e9cef7..6ae3e3ff5b0a 100644
> --- a/arch/s390/crypto/crc32-vx.c
> +++ b/arch/s390/crypto/crc32-vx.c
> @@ -49,8 +49,8 @@ u32 crc32c_le_vgfm_16(u32 crc, unsigned char const *buf, size_t size);
> static u32 __pure ___fname(u32 crc, \
> unsigned char const *data, size_t datalen) \
> { \
> - struct kernel_fpu vxstate; \
> unsigned long prealign, aligned, remaining; \
> + DECLARE_KERNEL_FPU_ONSTACK(vxstate); \
> \
> if (datalen < VX_MIN_LEN + VX_ALIGN_MASK) \
> return ___crc32_sw(crc, data, datalen); \
> diff --git a/arch/s390/include/asm/fpu/types.h b/arch/s390/include/asm/fpu/types.h
> index d889e9436865..b1afa13c07b7 100644
> --- a/arch/s390/include/asm/fpu/types.h
> +++ b/arch/s390/include/asm/fpu/types.h
> @@ -35,4 +35,7 @@ struct kernel_fpu {
> };
> };
>
> +#define DECLARE_KERNEL_FPU_ONSTACK(name) \
> + struct kernel_fpu name __uninitialized
> +
> #endif /* _ASM_S390_FPU_TYPES_H */
> diff --git a/arch/s390/kernel/sysinfo.c b/arch/s390/kernel/sysinfo.c
> index f6f8f498c9be..b439f17516eb 100644
> --- a/arch/s390/kernel/sysinfo.c
> +++ b/arch/s390/kernel/sysinfo.c
> @@ -426,9 +426,9 @@ subsys_initcall(create_proc_service_level);
> */
> void s390_adjust_jiffies(void)
> {
> + DECLARE_KERNEL_FPU_ONSTACK(fpu);
> struct sysinfo_1_2_2 *info;
> unsigned long capability;
> - struct kernel_fpu fpu;
>
> info = (void *) get_zeroed_page(GFP_KERNEL);
> if (!info)
> diff --git a/lib/raid6/s390vx.uc b/lib/raid6/s390vx.uc
> index cd0b9e95f499..7b0b355e1a26 100644
> --- a/lib/raid6/s390vx.uc
> +++ b/lib/raid6/s390vx.uc
> @@ -81,7 +81,7 @@ static inline void COPY_VEC(int x, int y)
>
> static void raid6_s390vx$#_gen_syndrome(int disks, size_t bytes, void **ptrs)
> {
> - struct kernel_fpu vxstate;
> + DECLARE_KERNEL_FPU_ONSTACK(vxstate);
> u8 **dptr, *p, *q;
> int d, z, z0;
>
> @@ -114,7 +114,7 @@ static void raid6_s390vx$#_gen_syndrome(int disks, size_t bytes, void **ptrs)
> static void raid6_s390vx$#_xor_syndrome(int disks, int start, int stop,
> size_t bytes, void **ptrs)
> {
> - struct kernel_fpu vxstate;
> + DECLARE_KERNEL_FPU_ONSTACK(vxstate);
> u8 **dptr, *p, *q;
> int d, z, z0;
>
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/4] kbuild: rpm-pkg: do not include depmod-generated files
@ 2024-02-06 1:35 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-06 1:35 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-kbuild, Nicolas Schier, linux-kernel
On Fri, Feb 02, 2024 at 10:35:17PM +0900, Masahiro Yamada wrote:
> Installing the kernel package is fine, but when uninstalling it, the
> following warnings are shown:
>
> warning: file modules.symbols.bin: remove failed: No such file or directory
> warning: file modules.symbols: remove failed: No such file or directory
> warning: file modules.softdep: remove failed: No such file or directory
> warning: file modules.devname: remove failed: No such file or directory
> warning: file modules.dep.bin: remove failed: No such file or directory
> warning: file modules.dep: remove failed: No such file or directory
> warning: file modules.builtin.bin: remove failed: No such file or directory
> warning: file modules.builtin.alias.bin: remove failed: No such file or directory
> warning: file modules.alias.bin: remove failed: No such file or directory
> warning: file modules.alias: remove failed: No such file or directory
>
> The %preun scriptlet runs 'kernel-install remove', which in turn invokes
> /usr/lib/kernel/install.d/50-depmod.install to remove those files before
> the actual package removal.
>
> RPM-based distributions do not ship files generated by depmod. Mark them
> as %ghost in order to exclude them from the package, but still claim the
> ownership on them.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> scripts/package/kernel.spec | 22 +++++++++++++++++++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index f58726671fb3..aaedb6d1b26f 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -66,6 +66,20 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA
> %{make} %{makeflags} run-command KBUILD_RUN_COMMAND='${srctree}/scripts/package/install-extmod-build %{buildroot}/usr/src/kernels/%{KERNELRELEASE}'
> %endif
>
> +{
> + for x in System.map config kernel modules.builtin \
> + modules.builtin.modinfo modules.order vmlinuz; do
> + echo "/lib/modules/%{KERNELRELEASE}/${x}"
> + done
> +
> + for x in alias alias.bin builtin.alias.bin builtin.bin dep dep.bin \
> + devname softdep symbols symbols.bin; do
> + echo "%ghost /lib/modules/%{KERNELRELEASE}/modules.${x}"
> + done
> +
> + echo "%exclude /lib/modules/%{KERNELRELEASE}/build"
> +} > %{buildroot}/kernel.list
> +
> %clean
> rm -rf %{buildroot}
>
> @@ -78,6 +92,9 @@ for file in vmlinuz System.map config; do
> cp "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}"
> fi
> done
> +if [ ! -e "/lib/modules/%{KERNELRELEASE}/modules.dep" ]; then
> + /usr/sbin/depmod %{KERNELRELEASE}
> +fi
>
> %preun
> if [ -x /sbin/new-kernel-pkg ]; then
> @@ -91,10 +108,9 @@ if [ -x /sbin/update-bootloader ]; then
> /sbin/update-bootloader --remove %{KERNELRELEASE}
> fi
>
> -%files
> +%files -f %{buildroot}/kernel.list
> %defattr (-, root, root)
> -/lib/modules/%{KERNELRELEASE}
> -%exclude /lib/modules/%{KERNELRELEASE}/build
> +%exclude /kernel.list
>
> %files headers
> %defattr (-, root, root)
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/4] kbuild: rpm-pkg: mark installed files in /boot as %ghost
@ 2024-02-06 1:35 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-06 1:35 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-kbuild, Nicolas Schier, linux-kernel
On Fri, Feb 02, 2024 at 10:35:18PM +0900, Masahiro Yamada wrote:
> Mark the files installed to /boot as %ghost to make sure they will be
> removed when the package is uninstalled.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> scripts/package/kernel.spec | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index aaedb6d1b26f..ecedcfc11e73 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -77,6 +77,10 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA
> echo "%ghost /lib/modules/%{KERNELRELEASE}/modules.${x}"
> done
>
> + for x in System.map config vmlinuz; do
> + echo "%ghost /boot/${x}-%{KERNELRELEASE}"
> + done
> +
> echo "%exclude /lib/modules/%{KERNELRELEASE}/build"
> } > %{buildroot}/kernel.list
>
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* 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 10/11] s390: Select CONFIG_ARCH_WANT_LD_ORPHAN_WARN
@ 2024-02-08 0:15 99% ` Nathan Chancellor
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-08 0:15 UTC (permalink / raw)
To: hca, gor, agordeev
Cc: borntraeger, svens, maskray, ndesaulniers, linux-s390,
linux-kernel, llvm, patches, Nathan Chancellor
Now that all sections have been properly accounted for in the s390
linker scripts, select CONFIG_ARCH_WANT_LD_ORPHAN_WARN so that
'--orphan-handling' is added to LDFLAGS to catch any future sections
that are added without being described in linker scripts.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index fe565f3a3a91..771235aee6bf 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -127,6 +127,7 @@ config S390
select ARCH_WANT_DEFAULT_BPF_JIT
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_KERNEL_PMD_MKWRITE
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS2
--
2.43.0
^ permalink raw reply related [relevance 99%]
* Prebuilt LLVM 18.1.0-rc2 uploaded
@ 2024-02-08 0:28 99% Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-08 0:28 UTC (permalink / raw)
To: llvm, linux-kernel
Hi all,
I have built and uploaded a prebuilt version of LLVM 18.1.0-rc2 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
As with Linux -rc releases, this is not the final version that will
ship. If you run across any issues, especially ones that were not
present in earlier LLVM releases, please consider reporting them to us
so that we have a chance to investigate and fix them before the final
release.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 00/11] s390: Support linking with ld.lld
@ 2024-02-09 15:08 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-09 15:08 UTC (permalink / raw)
To: Heiko Carstens
Cc: gor, agordeev, borntraeger, svens, maskray, ndesaulniers,
linux-s390, linux-kernel, llvm, patches
Hi Heiko,
On Fri, Feb 09, 2024 at 12:20:46PM +0100, Heiko Carstens wrote:
> > This series allows the s390 kernel to be linked with ld.lld (support for
> > s390 is under review at [1]). This implicitly depends on [2], which was
> > created and sent before it was realized that this series was necessary.
> ...
> > There is one outstanding issue due to something that ld.lld does not
> > support that the kernel relies on:
> >
> > ld.lld: error: drivers/nvme/host/fc.o:(__bug_table): writable SHF_MERGE section is not supported
> >
> > This was changed in the kernel in commit e21f8baf8d9a ("s390/bug: add
> > entry size to the __bug_table section"). Is this change truly necessary?
> > I selectively applied a revert on top of current mainline and I did not
> > observe any issues with either Clang or GCC.
>
> No it is not necessary. As the original patch stated this was a pre-req
> patch for objtool, for which we still don't have support. This (or
> something different) might be needed. But for now this can easily be
> reverted.
>
> > Then build the kernel with 'LD=ld.lld' in addition to whatever command
> > line you use (I tested both Clang and GCC). I can boot an ld.lld linked
> > kernel built with both compilers in QEMU with this series.
> >
> > [ 1.386970] Linux version 6.8.0-rc3-00043-g05761ede85d6-dirty (nathan@dev-fedora.aadp) (s390-linux-gcc (GCC) 13.2.0, ClangBuiltLinux LLD 19.0.0) #1 SMP Wed Feb 7 16:51:12 MST 2024
> >
> > [ 0.871923] Linux version 6.8.0-rc3-00043-g05761ede85d6-dirty (nathan@dev-fedora.aadp) (ClangBuiltLinux clang version 19.0.0git (https://github.com/llvm/llvm-project 417075e56aeba5a5b20301c7bfeba9c2a800982b), ClangBuiltLinux LLD 19.0.0) #1 SMP Wed Feb 7 17:01:22 MST 2024
>
> Tested, and works for me. Thanks a lot for your work. This is highly
> appreciated!
>
> I applied this series internally to get some CI runs over the weekend, and
> push it to our external repository beginning of next week. As suggested by
Excellent, please let me know if anything comes up from that!
> you I reverted the commit you mentioned above, and also removed ENTRY from
> our vdso linker scripts, similar to what you did already for powerpc (see
> patches below).
Ah thanks for spotting that, I was so focused on the errors I forgot to
clean up the warning too.
> Please feel free to send patches for both of the issues, and I'll replace
> my patches with your patches.
Honestly, I am not sure that I will write much better commit messages
than the ones you already have and those solutions seem acceptable to
me. Consider them:
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
But if you would prefer patches from myself though, I can send them next
week.
Cheers,
Nathan
> From 30a0a88d0e6c4802b748a942bb3f6f1b223f53ba Mon Sep 17 00:00:00 2001
> From: Heiko Carstens <hca@linux.ibm.com>
> Date: Fri, 9 Feb 2024 11:48:25 +0100
> Subject: [PATCH 1/2] s390/bug: remove entry size from __bug_table section
>
> Commit e21f8baf8d9a ("s390/bug: add entry size to the __bug_table section")
> changed the __EMIT_BUG() inline assembly to emit mergeable __bug_table
> entries. This is at least currently not needed, but causes problems with
> the upcoming s390 ld.lld support:
>
> ld.lld: error: drivers/nvme/host/fc.o:(__bug_table): writable SHF_MERGE section is not supported
>
> Therefore revert the change for now.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Closes: https://lore.kernel.org/all/20240207-s390-lld-and-orphan-warn-v1-0-8a665b3346ab@kernel.org/
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/include/asm/bug.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/include/asm/bug.h b/arch/s390/include/asm/bug.h
> index aebe1e22c7be..c500d45fb465 100644
> --- a/arch/s390/include/asm/bug.h
> +++ b/arch/s390/include/asm/bug.h
> @@ -14,7 +14,7 @@
> ".section .rodata.str,\"aMS\",@progbits,1\n" \
> "1: .asciz \""__FILE__"\"\n" \
> ".previous\n" \
> - ".section __bug_table,\"awM\",@progbits,%2\n" \
> + ".section __bug_table,\"aw\"\n" \
> "2: .long 0b-.\n" \
> " .long 1b-.\n" \
> " .short %0,%1\n" \
> @@ -30,7 +30,7 @@
> #define __EMIT_BUG(x) do { \
> asm_inline volatile( \
> "0: mc 0,0\n" \
> - ".section __bug_table,\"awM\",@progbits,%1\n" \
> + ".section __bug_table,\"aw\"\n" \
> "1: .long 0b-.\n" \
> " .short %0\n" \
> " .org 1b+%1\n" \
> --
> 2.40.1
>
> From bdca9b8dcf3f0884341f491d54502d4cbe660446 Mon Sep 17 00:00:00 2001
> From: Heiko Carstens <hca@linux.ibm.com>
> Date: Fri, 9 Feb 2024 11:54:01 +0100
> Subject: [PATCH 2/2] s390/vdso: remove unused ENTRY in linker scripts
>
> When linking vdso64.so.dbg with ld.lld, there is a warning about not
> finding _start for the starting address:
>
> ld.lld: warning: cannot find entry symbol _start; not setting start address
>
> Fix this be removing the unused ENTRY in both vdso linker scripts. See
> commit e247172854a5 ("powerpc/vdso: Remove unused ENTRY in linker
> scripts"), which solved the same problem for powerpc, for further details.
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/kernel/vdso32/vdso32.lds.S | 1 -
> arch/s390/kernel/vdso64/vdso64.lds.S | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/s390/kernel/vdso32/vdso32.lds.S b/arch/s390/kernel/vdso32/vdso32.lds.S
> index edf5ff1debe1..65b9513a5a0e 100644
> --- a/arch/s390/kernel/vdso32/vdso32.lds.S
> +++ b/arch/s390/kernel/vdso32/vdso32.lds.S
> @@ -9,7 +9,6 @@
>
> OUTPUT_FORMAT("elf32-s390", "elf32-s390", "elf32-s390")
> OUTPUT_ARCH(s390:31-bit)
> -ENTRY(_start)
>
> SECTIONS
> {
> diff --git a/arch/s390/kernel/vdso64/vdso64.lds.S b/arch/s390/kernel/vdso64/vdso64.lds.S
> index 4461ea151e49..37e2a505e81d 100644
> --- a/arch/s390/kernel/vdso64/vdso64.lds.S
> +++ b/arch/s390/kernel/vdso64/vdso64.lds.S
> @@ -9,7 +9,6 @@
>
> OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
> OUTPUT_ARCH(s390:64-bit)
> -ENTRY(_start)
>
> SECTIONS
> {
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* 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%]
* Re: Prebuilt LLVM 18.1.0-rc2 uploaded
@ 2024-02-12 23:48 99% ` Nathan Chancellor
2024-02-13 2:53 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-12 23:48 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: llvm, linux-kernel
Hi Miguel,
On Sat, Feb 10, 2024 at 05:36:01PM +0100, Miguel Ojeda wrote:
> On Thu, Feb 8, 2024 at 1:28 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > I have built and uploaded a prebuilt version of LLVM 18.1.0-rc2 to
> > https://mirrors.edge.kernel.org/pub/tools/llvm/.
> >
> > As with Linux -rc releases, this is not the final version that will
> > ship. If you run across any issues, especially ones that were not
> > present in earlier LLVM releases, please consider reporting them to us
> > so that we have a chance to investigate and fix them before the final
> > release.
>
> I took a look at the LLVM 18 prerelease to see if these would work
> with Rust for e.g. CI and other users (instead of using the
> LLVM-provided apt ones, for instance), and noticed it does not bundle
> `libclang.so`.
>
> Would it be possible to include it so that we can use `bindgen` and
> thus enable Rust with them?
>
> I understand they are intended to be minimal toolchains, but if you
> think it would not be an unreasonable overhead, then it would be great
> to have it.
Absolutely, I am more than happy to include libclang.so and anything
else that would be useful for the kernel. Everything gets built but I
only install what has felt needed for the kernel, so there is no real
overhead aside from package size, which obviously should not increase
much with this change. I've added the targets to my build scripts and
kicked off a set of builds. If they finish successfully, I will upload
them so that you can test them out and make sure they will work.
Thanks for bringing this up and giving them a go, cheers!
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 04/11] s390: vmlinux.lds.S: Discard unnecessary sections
@ 2024-02-13 0:15 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-13 0:15 UTC (permalink / raw)
To: Heiko Carstens
Cc: gor, agordeev, borntraeger, svens, maskray, ndesaulniers,
linux-s390, linux-kernel, llvm, patches
On Mon, Feb 12, 2024 at 02:55:11PM +0100, Heiko Carstens wrote:
> On Wed, Feb 07, 2024 at 05:14:56PM -0700, Nathan Chancellor wrote:
> > When building with CONFIG_LD_ORPHAN_WARN after selecting
> > CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are some warnings around certain
> > ELF sections that are unnecessary for the kernel's purposes.
> >
> > s390-linux-ld: warning: orphan section `.dynstr' from `arch/s390/kernel/head64.o' being placed in section `.dynstr'
> > s390-linux-ld: warning: orphan section `.dynamic' from `arch/s390/kernel/head64.o' being placed in section `.dynamic'
> > s390-linux-ld: warning: orphan section `.hash' from `arch/s390/kernel/head64.o' being placed in section `.hash'
> > s390-linux-ld: warning: orphan section `.gnu.hash' from `arch/s390/kernel/head64.o' being placed in section `.gnu.hash'
> >
> > Add them to the discards to clear up the warnings, which matches other
> > architectures.
> >
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > arch/s390/kernel/vmlinux.lds.S | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> ...
> > - *(.interp)
> > + *(.interp .dynamic)
> > + *(.dynstr .hash .gnu.hash)
>
> This seems to be wrong, since it leads to 1000s of error messages when
> using the "crash" utility e.g. when looking into a live dump of system
> with the generated debug info:
>
> BFD: /usr/lib/debug/usr/lib/modules/6.8.0-20240211.rc3.git0.bdca9b8dcf3f.300.fc39.s390x/vmlinux: attempt to load strings from a non-string section (number 0)
>
> I will change this commit to the below; it seems to work and is in
> line with other architectures:
Thanks a lot for catching that, your final change seems good to me.
Here's to hoping I did not get anything else wrong :)
Cheers,
Nathan
> -----
>
> When building with CONFIG_LD_ORPHAN_WARN after selecting
> CONFIG_ARCH_HAS_LD_ORPHAN_WARN, there are some warnings around certain
> ELF sections:
>
> s390-linux-ld: warning: orphan section `.dynstr' from `arch/s390/kernel/head64.o' being placed in section `.dynstr'
> s390-linux-ld: warning: orphan section `.dynamic' from `arch/s390/kernel/head64.o' being placed in section `.dynamic'
> s390-linux-ld: warning: orphan section `.hash' from `arch/s390/kernel/head64.o' being placed in section `.hash'
> s390-linux-ld: warning: orphan section `.gnu.hash' from `arch/s390/kernel/head64.o' being placed in section `.gnu.hash'
>
> Explicitly keep those sections like other architectures when
> CONFIG_RELOCATABLE is enabled, which is always true for s390.
>
> [hca@linux.ibm.com: keep sections instead of discarding]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> Link: https://lore.kernel.org/r/20240207-s390-lld-and-orphan-warn-v1-4-8a665b3346ab@kernel.org
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
> arch/s390/kernel/vmlinux.lds.S | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
> index 661a487a3048..d46e3c383952 100644
> --- a/arch/s390/kernel/vmlinux.lds.S
> +++ b/arch/s390/kernel/vmlinux.lds.S
> @@ -200,6 +200,21 @@ SECTIONS
> *(.rela*)
> __rela_dyn_end = .;
> }
> + .dynamic ALIGN(8) : {
> + *(.dynamic)
> + }
> + .dynsym ALIGN(8) : {
> + *(.dynsym)
> + }
> + .dynstr ALIGN(8) : {
> + *(.dynstr)
> + }
> + .hash ALIGN(8) : {
> + *(.hash)
> + }
> + .gnu.hash ALIGN(8) : {
> + *(.gnu.hash)
> + }
>
> . = ALIGN(PAGE_SIZE);
> __init_end = .; /* freed after init ends here */
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: Use -fmin-function-alignment when available
@ 2024-02-13 0:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-13 0:27 UTC (permalink / raw)
To: Petr Pavlu; +Cc: masahiroy, nicolas, mark.rutland, linux-kbuild, linux-kernel
Hi Petr,
On Mon, Feb 12, 2024 at 03:53:55PM +0100, Petr Pavlu wrote:
> GCC recently added option -fmin-function-alignment, which should appear
> in GCC 14. Unlike -falign-functions, this option causes all functions to
> be aligned at the specified value, including the cold ones.
>
> Detect availability of -fmin-function-alignment and use it instead of
> -falign-functions when present. Introduce CC_HAS_SANE_FUNCTION_ALIGNMENT
> and make the workarounds for the broken function alignment conditional
> on this setting.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> Makefile | 7 ++++++-
> arch/Kconfig | 8 ++++++++
> include/linux/compiler_types.h | 10 +++++-----
> kernel/exit.c | 5 ++++-
> 4 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7e0b2ad98905..9516e43f6e45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -974,7 +974,12 @@ export CC_FLAGS_CFI
> endif
>
> ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
> -KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
> +# Set the minimal function alignment. Try to use the newer GCC option
> +# -fmin-function-alignment, or fall back to -falign-funtions. See also
> +# CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT.
> +KBUILD_CFLAGS += $(call cc-option, \
> + -fmin-function-alignment=$(CONFIG_FUNCTION_ALIGNMENT), \
> + -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT))
> endif
>
> # arch Makefile may override CC so keep this after arch Makefile is included
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a5af0edd3eb8..e2448f927fae 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1507,4 +1507,12 @@ config FUNCTION_ALIGNMENT
> default 4 if FUNCTION_ALIGNMENT_4B
> default 0
>
> +config CC_HAS_SANE_FUNCTION_ALIGNMENT
> + # Detect availability of the GCC option -fmin-function-alignment which
> + # guarantees minimal alignment for all functions. GCC 13 and older have
> + # only -falign-functions which the compiler ignores for cold functions
> + # and this hence requires extra care in the kernel. Clang provides
> + # strict alignment always when using -falign-functions.
> + def_bool $(cc-option, -fmin-function-alignment=8) || CC_IS_CLANG
> +
I think this configuration should be split into something like
CONFIG_CC_HAS_MIN_FUNCTION_ALIGNMENT that has the cc-option check then
CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT can depend on that configuration
or Clang as you have it here, so that we can drop the cc-option check in
the main Makefile and have it be:
ifdef CONFIG_CC_HAS_MIN_FUNCTION_ALIGNMENT
KBUILD_CFLAGS += -fmin-function-alignment=$(CONFIG_FUNCTION_ALIGNMENT)
else
KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
endif
It is wasteful to call cc-option twice in my opinion, especially if we
are checking it in Kconfig.
> endmenu
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 663d8791c871..f0152165e83c 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -99,17 +99,17 @@ static inline void __chk_io_ptr(const volatile void __iomem *ptr) { }
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/Label-Attributes.html#index-cold-label-attribute
> *
> * When -falign-functions=N is in use, we must avoid the cold attribute as
> - * contemporary versions of GCC drop the alignment for cold functions. Worse,
> - * GCC can implicitly mark callees of cold functions as cold themselves, so
> - * it's not sufficient to add __function_aligned here as that will not ensure
> - * that callees are correctly aligned.
> + * GCC drops the alignment for cold functions. Worse, GCC can implicitly mark
> + * callees of cold functions as cold themselves, so it's not sufficient to add
> + * __function_aligned here as that will not ensure that callees are correctly
> + * aligned.
> *
> * See:
> *
> * https://lore.kernel.org/lkml/Y77%2FqVgvaJidFpYt@FVFF77S0Q05N
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345#c9
> */
> -#if !defined(CONFIG_CC_IS_GCC) || (CONFIG_FUNCTION_ALIGNMENT == 0)
> +#if defined(CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT) || (CONFIG_FUNCTION_ALIGNMENT == 0)
> #define __cold __attribute__((__cold__))
> #else
> #define __cold
> diff --git a/kernel/exit.c b/kernel/exit.c
> index dfb963d2f862..5a6fed4ad3df 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -1920,7 +1920,10 @@ EXPORT_SYMBOL(thread_group_exited);
> *
> * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345#c11
> */
> -__weak __function_aligned void abort(void)
> +#ifndef CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT
> +__function_aligned
> +#endif
> +__weak void abort(void)
> {
> BUG();
>
>
> base-commit: 841c35169323cd833294798e58b9bf63fa4fa1de
> --
> 2.35.3
>
^ permalink raw reply [relevance 99%]
* Re: Prebuilt LLVM 18.1.0-rc2 uploaded
2024-02-12 23:48 99% ` Nathan Chancellor
@ 2024-02-13 2:53 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-13 2:53 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: llvm, linux-kernel
On Mon, Feb 12, 2024 at 04:48:52PM -0700, Nathan Chancellor wrote:
> Hi Miguel,
>
> On Sat, Feb 10, 2024 at 05:36:01PM +0100, Miguel Ojeda wrote:
> > On Thu, Feb 8, 2024 at 1:28 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > I have built and uploaded a prebuilt version of LLVM 18.1.0-rc2 to
> > > https://mirrors.edge.kernel.org/pub/tools/llvm/.
> > >
> > > As with Linux -rc releases, this is not the final version that will
> > > ship. If you run across any issues, especially ones that were not
> > > present in earlier LLVM releases, please consider reporting them to us
> > > so that we have a chance to investigate and fix them before the final
> > > release.
> >
> > I took a look at the LLVM 18 prerelease to see if these would work
> > with Rust for e.g. CI and other users (instead of using the
> > LLVM-provided apt ones, for instance), and noticed it does not bundle
> > `libclang.so`.
> >
> > Would it be possible to include it so that we can use `bindgen` and
> > thus enable Rust with them?
> >
> > I understand they are intended to be minimal toolchains, but if you
> > think it would not be an unreasonable overhead, then it would be great
> > to have it.
>
> Absolutely, I am more than happy to include libclang.so and anything
> else that would be useful for the kernel. Everything gets built but I
> only install what has felt needed for the kernel, so there is no real
> overhead aside from package size, which obviously should not increase
> much with this change. I've added the targets to my build scripts and
> kicked off a set of builds. If they finish successfully, I will upload
> them so that you can test them out and make sure they will work.
Alright, I reuploaded 18.1.0-rc2 with libclang.so included, please let
me know if this will work for you going forward.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 03/11] s390: vmlinux.lds.S: Explicitly handle '.got' and '.plt' sections
@ 2024-02-14 19:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-14 19:48 UTC (permalink / raw)
To: Heiko Carstens
Cc: Fangrui Song, gor, agordeev, borntraeger, svens, ndesaulniers,
linux-s390, linux-kernel, llvm, patches
On Wed, Feb 14, 2024 at 01:20:55PM +0100, Heiko Carstens wrote:
> On Mon, Feb 12, 2024 at 09:31:53PM -0800, Fangrui Song wrote:
> > On Wed, Feb 7, 2024 at 4:15 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > + ASSERT(SIZEOF(.got.plt) == 0, "Unexpected GOT/PLT entries detected!")
> > > + .plt : {
> > > + *(.plt)
> > > + *(.plt.*)
> > > + *(.iplt)
> > > + *(.igot .igot.plt)
> > > + }
> > > + ASSERT(SIZEOF(.plt) == 0, "Unexpected run-time procedure linkages detected!")
> > > +
> >
> > It seems that arches that drop .plt typically place input section
> > description on one line. This saves vertical space.
> > It's shorter to use one input section description to match multiple
> > sections, e.g.
> >
> > *(.plt .iplt)
>
> Yes, I'll change Nathan's patch so it looks like arm64:
>
> /*
> * Sections that should stay zero sized, which is safer to
> * explicitly check instead of blindly discarding.
> */
> .plt : {
> *(.plt) *(.plt.*) *(.iplt) *(.igot .igot.plt)
> }
Thanks a lot for changing this. I tried to be consistent with the rest
of the linker script but I guess there were not really any sections that
had this many lines to make it one lining it worth it prior to this
point. Stylistic expectations are hard to account for :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] [RFC] xfrm: work around a clang-19 fortifiy-string false-positive
@ 2024-02-16 20:42 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-16 20:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Arnd Bergmann, Nick Desaulniers,
Bill Wendling, Justin Stitt, Gustavo A. R. Silva, Kees Cook,
Leon Romanovsky, Lin Ma, Simon Horman, Breno Leitao,
Tobias Brunner, Raed Salem, netdev, linux-kernel, llvm
Hi Arnd,
On Fri, Feb 16, 2024 at 09:26:40PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> clang-19 recently got branched from clang-18 and is not yet released.
> The current version introduces exactly one new warning that I came
> across in randconfig testing, in the copy_to_user_tmpl() function:
>
> include/linux/fortify-string.h:420: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]
> 420 | __write_overflow_field(p_size_field, size);
>
> I have not yet produced a minimized test case for it, but I have a
> local workaround, which avoids the memset() here by replacing it with
> an initializer.
>
> The memset is required to avoid leaking stack data to user space
> and was added in commit 1f86840f8977 ("xfrm_user: fix info leak in
> copy_to_user_tmpl()"). Simply changing the initializer to set all fields
> still risks leaking data in the padding between them, which the compiler
> is free to do here. To work around that problem, explicit padding fields
> have to get added as well.
>
> My first idea was that just adding the padding would avoid the warning
> as well, as the padding tends to confused the fortified string helpers,
> but it turns out that both changes are required here.
>
> Since this is a false positive, a better fix would likely be to
> fix the compiler.
I have some observations and notes from my initial investigation into
this issue on our GitHub issue tracker but I have not produced a
minimized test case either.
https://github.com/ClangBuiltLinux/linux/issues/1985
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> include/uapi/linux/xfrm.h | 3 +++
> net/xfrm/xfrm_user.c | 3 +--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
> index 6a77328be114..99adac4fa648 100644
> --- a/include/uapi/linux/xfrm.h
> +++ b/include/uapi/linux/xfrm.h
> @@ -27,6 +27,7 @@ struct xfrm_id {
> xfrm_address_t daddr;
> __be32 spi;
> __u8 proto;
> + __u8 __pad[3];
> };
>
> struct xfrm_sec_ctx {
> @@ -242,11 +243,13 @@ struct xfrm_user_sec_ctx {
> struct xfrm_user_tmpl {
> struct xfrm_id id;
> __u16 family;
> + __u16 __pad1;
> xfrm_address_t saddr;
> __u32 reqid;
> __u8 mode;
> __u8 share;
> __u8 optional;
> + __u8 __pad2;
> __u32 aalgos;
> __u32 ealgos;
> __u32 calgos;
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index a5232dcfea46..e81f977e183c 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -2011,7 +2011,7 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
>
> static int copy_to_user_tmpl(struct xfrm_policy *xp, struct sk_buff *skb)
> {
> - struct xfrm_user_tmpl vec[XFRM_MAX_DEPTH];
> + struct xfrm_user_tmpl vec[XFRM_MAX_DEPTH] = {};
> int i;
>
> if (xp->xfrm_nr == 0)
> @@ -2021,7 +2021,6 @@ static int copy_to_user_tmpl(struct xfrm_policy *xp, struct sk_buff *skb)
> struct xfrm_user_tmpl *up = &vec[i];
> struct xfrm_tmpl *kp = &xp->xfrm_vec[i];
>
> - memset(up, 0, sizeof(*up));
> memcpy(&up->id, &kp->id, sizeof(up->id));
> up->family = kp->encap_family;
> memcpy(&up->saddr, &kp->saddr, sizeof(up->saddr));
> --
> 2.39.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] kbuild: Use -fmin-function-alignment when available
@ 2024-02-17 0:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-17 0:07 UTC (permalink / raw)
To: Petr Pavlu; +Cc: masahiroy, nicolas, mark.rutland, linux-kbuild, linux-kernel
On Thu, Feb 15, 2024 at 04:16:42PM +0100, Petr Pavlu wrote:
> GCC recently added option -fmin-function-alignment, which should appear
> in GCC 14. Unlike -falign-functions, this option causes all functions to
> be aligned at the specified value, including the cold ones.
>
> Detect availability of -fmin-function-alignment and use it instead of
> -falign-functions when present. Introduce CC_HAS_SANE_FUNCTION_ALIGNMENT
> and make the workarounds for the broken function alignment conditional
> on this setting.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Thanks, this looks good to me from a Kbuild perspective.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> Changes since v1 [1]:
> - Check the availability of -fmin-function-alignment only in one place.
>
> [1] https://lore.kernel.org/linux-kbuild/20240212145355.1050-1-petr.pavlu@suse.com/
>
> Makefile | 7 +++++++
> arch/Kconfig | 12 ++++++++++++
> include/linux/compiler_types.h | 10 +++++-----
> kernel/exit.c | 5 ++++-
> 4 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7e0b2ad98905..6f20ab5e2e44 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -974,8 +974,15 @@ export CC_FLAGS_CFI
> endif
>
> ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
> +# Set the minimal function alignment. Use the newer GCC option
> +# -fmin-function-alignment if it is available, or fall back to -falign-funtions.
> +# See also CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT.
> +ifdef CONFIG_CC_HAS_MIN_FUNCTION_ALIGNMENT
> +KBUILD_CFLAGS += -fmin-function-alignment=$(CONFIG_FUNCTION_ALIGNMENT)
> +else
> KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
> endif
> +endif
>
> # arch Makefile may override CC so keep this after arch Makefile is included
> NOSTDINC_FLAGS += -nostdinc
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a5af0edd3eb8..bd6c6335efac 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1507,4 +1507,16 @@ config FUNCTION_ALIGNMENT
> default 4 if FUNCTION_ALIGNMENT_4B
> default 0
>
> +config CC_HAS_MIN_FUNCTION_ALIGNMENT
> + # Detect availability of the GCC option -fmin-function-alignment which
> + # guarantees minimal alignment for all functions, unlike
> + # -falign-functions which the compiler ignores for cold functions.
> + def_bool $(cc-option, -fmin-function-alignment=8)
> +
> +config CC_HAS_SANE_FUNCTION_ALIGNMENT
> + # Set if the guaranteed alignment with -fmin-function-alignment is
> + # available or extra care is required in the kernel. Clang provides
> + # strict alignment always, even with -falign-functions.
> + def_bool CC_HAS_MIN_FUNCTION_ALIGNMENT || CC_IS_CLANG
> +
> endmenu
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index 663d8791c871..f0152165e83c 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -99,17 +99,17 @@ static inline void __chk_io_ptr(const volatile void __iomem *ptr) { }
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/Label-Attributes.html#index-cold-label-attribute
> *
> * When -falign-functions=N is in use, we must avoid the cold attribute as
> - * contemporary versions of GCC drop the alignment for cold functions. Worse,
> - * GCC can implicitly mark callees of cold functions as cold themselves, so
> - * it's not sufficient to add __function_aligned here as that will not ensure
> - * that callees are correctly aligned.
> + * GCC drops the alignment for cold functions. Worse, GCC can implicitly mark
> + * callees of cold functions as cold themselves, so it's not sufficient to add
> + * __function_aligned here as that will not ensure that callees are correctly
> + * aligned.
> *
> * See:
> *
> * https://lore.kernel.org/lkml/Y77%2FqVgvaJidFpYt@FVFF77S0Q05N
> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345#c9
> */
> -#if !defined(CONFIG_CC_IS_GCC) || (CONFIG_FUNCTION_ALIGNMENT == 0)
> +#if defined(CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT) || (CONFIG_FUNCTION_ALIGNMENT == 0)
> #define __cold __attribute__((__cold__))
> #else
> #define __cold
> diff --git a/kernel/exit.c b/kernel/exit.c
> index dfb963d2f862..5a6fed4ad3df 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -1920,7 +1920,10 @@ EXPORT_SYMBOL(thread_group_exited);
> *
> * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345#c11
> */
> -__weak __function_aligned void abort(void)
> +#ifndef CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT
> +__function_aligned
> +#endif
> +__weak void abort(void)
> {
> BUG();
>
>
> base-commit: 841c35169323cd833294798e58b9bf63fa4fa1de
> --
> 2.35.3
>
^ permalink raw reply [relevance 99%]
* Re: Patch "modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS" has been added to the 6.6-stable tree
[not found] <2024021932-overpass-stinger-b897@gregkh>
@ 2024-02-19 19:04 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-19 19:04 UTC (permalink / raw)
To: gregkh; +Cc: masahiroy, stable-commits, llvm, linux-kbuild
Hi Greg,
On Mon, Feb 19, 2024 at 05:28:33PM +0100, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
>
> to the 6.6-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:
> modpost-add-.ltext-and-.ltext.-to-text_sections.patch
> and it can be found in the queue-6.6 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.
>
>
> From 397586506c3da005b9333ce5947ad01e8018a3be Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Tue, 23 Jan 2024 15:59:55 -0700
> Subject: modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS
>
> From: Nathan Chancellor <nathan@kernel.org>
>
> commit 397586506c3da005b9333ce5947ad01e8018a3be upstream.
Please apply upstream commit 6a4e59eeedc3 ("linux/init: remove __memexit*
annotations") before this change, as there is a warning in modpost
without it:
scripts/mod/modpost.c:916:37: warning: excess elements in array initializer [-Wexcess-initializers]
916 | .good_tosec = {ALL_TEXT_SECTIONS , NULL},
| ^~~~
.../lib/clang/19/include/__stddef_null.h:26:14: note: expanded from macro 'NULL'
26 | #define NULL ((void*)0)
| ^~~~~~~~~~
1 warning generated.
It applies cleanly with 'git format-patch | patch' for me and I don't
think it is unreasonable as a fix for this issue in stable.
This will be needed in 6.1 as well but that backport is a little more
involved, I will reply there with an mbox series.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: Patch "um: Fix adding '-no-pie' for clang" has been added to the 6.1-stable tree
[not found] <2024021953-shrimp-trilogy-590a@gregkh>
@ 2024-02-19 19:23 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-19 19:23 UTC (permalink / raw)
To: gregkh; +Cc: masahiroy, stable-commits, llvm, linux-kbuild
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Hi Greg,
On Mon, Feb 19, 2024 at 05:50:54PM +0100, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> um: Fix adding '-no-pie' for clang
>
> to the 6.1-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:
> um-fix-adding-no-pie-for-clang.patch
> and it can be found in the queue-6.1 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.
>
>
> From 846cfbeed09b45d985079a9173cf390cc053715b Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Tue, 23 Jan 2024 15:59:54 -0700
> Subject: um: Fix adding '-no-pie' for clang
>
> From: Nathan Chancellor <nathan@kernel.org>
>
> commit 846cfbeed09b45d985079a9173cf390cc053715b upstream.
Please replace this patch with the attached series. While this patch
does fix this particular issue, commit 397586506c3d ("modpost: Add
'.ltext' and '.ltext.*' to TEXT_SECTIONS") is also needed to resolve all
errors with clang-18+ and ARCH=um. That commit needs a few (reasonable,
imo) prerequisite patches to apply cleanly without causing any build
warnings, as I point out on the 6.6 patch.
If there are any issues, please let me know.
Cheers,
Nathan
[-- Attachment #2: 6.1-fix-um-clang-18.mbox --]
[-- Type: application/mbox, Size: 17858 bytes --]
^ permalink raw reply [relevance 99%]
* Re: Patch "um: Fix adding '-no-pie' for clang" has been added to the 5.15-stable tree
[not found] <2024021939-dullness-calculate-a293@gregkh>
@ 2024-02-19 19:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-19 19:28 UTC (permalink / raw)
To: gregkh; +Cc: masahiroy, stable-commits, llvm, linux-kbuild
Hi Greg,
On Mon, Feb 19, 2024 at 06:02:39PM +0100, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> um: Fix adding '-no-pie' for clang
>
> to the 5.15-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:
> um-fix-adding-no-pie-for-clang.patch
> and it can be found in the queue-5.15 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.
>
>
> From 846cfbeed09b45d985079a9173cf390cc053715b Mon Sep 17 00:00:00 2001
> From: Nathan Chancellor <nathan@kernel.org>
> Date: Tue, 23 Jan 2024 15:59:54 -0700
> Subject: um: Fix adding '-no-pie' for clang
>
> From: Nathan Chancellor <nathan@kernel.org>
>
> commit 846cfbeed09b45d985079a9173cf390cc053715b upstream.
>
> 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>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> arch/um/Makefile | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -118,7 +118,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
5.15 does not have support for gcc-min-version, so I think this just
breaks ARCH=um for GCC. I do not think this patch matters much in 5.15
and earlier, we only test ARCH=um with Linux 6.1 and newer, so it can be
dropped.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] s390/boot: Workaround current 'llvm-objdump -t -j ...' behavior
@ 2024-02-21 16:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-21 16:48 UTC (permalink / raw)
To: Heiko Carstens
Cc: gor, agordeev, borntraeger, svens, morbo, justinstitt,
linux-s390, llvm, patches
Hi Heiko,
On Wed, Feb 21, 2024 at 10:16:12AM +0100, Heiko Carstens wrote:
> On Tue, Feb 20, 2024 at 01:44:48PM -0700, Nathan Chancellor wrote:
> > When building with OBJDUMP=llvm-objdump, there are a series of warnings
> > from the section comparisons that arch/s390/boot/Makefile performs
> > between vmlinux and arch/s390/boot/vmlinux:
> ...
> > It may be possible to change llvm-objdump's behavior to match GNU
> > objdump's behavior but the difficulty of that task has not yet been
> > explored. The combination of '$(OBJDUMP) -t -j' is not common in the
> > kernel tree on a whole, so workaround this tool difference by grepping
> > for the sections in the full symbol table output in a similar manner to
> > the sed invocation. This results in no visible change for GNU objdump
> > users while fixing the warnings for OBJDUMP=llvm-objdump, further
> > enabling use of LLVM=1 for ARCH=s390 with versions of LLVM that have
> > support for s390 in ld.lld and llvm-objcopy.
> >
> > Reported-by: Heiko Carstens <hca@linux.ibm.com>
> > Closes: https://lore.kernel.org/20240219113248.16287-C-hca@linux.ibm.com/
> > Link: https://github.com/ClangBuiltLinux/linux/issues/859
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > s390 llvm-objcopy support may be backported to LLVM 18.1.0 in time for
> > the final release.
> >
> > https://github.com/llvm/llvm-project/pull/82324
> >
> > s390 ld.lld has already made it into release/18.x:
> >
> > https://github.com/llvm/llvm-project/commit/0a44c3792a6ff799df5f100670d7e19d1bc49f03
> >
> > If the objcopy change makes 18.1.0 final, features + this change should
> > build cleanly with LLVM 18.1.0+ using LLVM=1 :)
> > ---
> > arch/s390/boot/Makefile | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> This seems to work like expected (also verified with a couple of scenarios
> where things are supposed to break).
>
> So compiling the kernel with LLVM=1 finally works on s390!
>
> Patch applied - Thanks a lot!
Thanks a lot for testing and applying this quickly! Small update on the
LLVM side, the llvm-objcopy change made it into 18.1.0-rc3:
https://github.com/llvm/llvm-project/commit/5ef297ab611822537a385d45244867519563d3ef
https://github.com/llvm/llvm-project/commits/llvmorg-18.1.0-rc3
So it's pretty much official, 'ARCH=s390 LLVM=1' should build without
any issues with Linux 6.9+ and LLVM 18.1.0+ :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] wifi: ath12k: Fix uninitialized use of ret in ath12k_mac_allocate()
@ 2024-02-21 18:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-21 18:00 UTC (permalink / raw)
To: Kalle Valo
Cc: quic_jjohnson, morbo, justinstitt, quic_periyasa, ath12k,
linux-wireless, llvm, patches
Hi Kalle,
On Wed, Feb 07, 2024 at 03:08:14PM +0000, Kalle Valo wrote:
> Nathan Chancellor <nathan@kernel.org> wrote:
>
> > Clang warns (or errors with CONFIG_WERROR=y):
> >
> > drivers/net/wireless/ath/ath12k/mac.c:8060:9: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized]
> > 8060 | return ret;
> > | ^~~
> > drivers/net/wireless/ath/ath12k/mac.c:8022:9: note: initialize the variable 'ret' to silence this warning
> > 8022 | int ret, i, j;
> > | ^
> > | = 0
> > 1 error generated.
> >
> > Commit 6db6e70a17f6 ("wifi: ath12k: Introduce the container for mac80211
> > hw") added a completely uninitialized use of ret. Prior to that change,
> > -ENOMEM was returned to the callers of ath12k_mac_allocate() whenever
> > ath12k_mac_hw_allocate() failed. Assign that value to ret to make sure
> > it is always initialized when used and clear up the warning.
> >
> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1989i
> > Fixes: 6db6e70a17f6 ("wifi: ath12k: Introduce the container for mac80211 hw")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
> > Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> 04edb5dc68f4 wifi: ath12k: Fix uninitialized use of ret in ath12k_mac_allocate()
It doesn't seem like this tree or branch flows into -next on its own, so
this patch is not present in and the build still breaks on
next-20240221. Can this be fixed so that this warning stops breaking our
builds?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.0-rc3 uploaded
@ 2024-02-21 19:36 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-21 19:36 UTC (permalink / raw)
To: llvm, linux-kernel
Hi all,
I have built and uploaded a prebuilt version of LLVM 18.1.0-rc2 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
This release is the first one to have SystemZ (s390) support in ld.lld
and llvm-objcopy, so this release will be the first one to allow
'ARCH=s390 LLVM=1' to work properly, along with several patches to the
kernel that are pending in the s390 features branch (targetting 6.9):
https://git.kernel.org/s390/l/features
Another change in this release is the inclusion of libclang.so on the
packaging side, which allows bindgen to be used with these toolchains:
https://lore.kernel.org/CANiq72npYCD-zKqcXPNOAxnKiUCCXGbFQaGo-8=0-171ni+ncQ@mail.gmail.com/
As with Linux -rc releases, this is not the final version that will
ship. If you run across any issues, especially ones that were not
present in earlier LLVM releases, please consider reporting them to us
so that we have a chance to investigate and fix them before the final
release.
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%]
* Re: [PATCH] arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with Clang
@ 2024-02-25 19:54 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-25 19:54 UTC (permalink / raw)
To: Stephen Boyd
Cc: Catalin Marinas, Will Deacon, linux-kernel, patches,
linux-arm-kernel, Jason Ling, Florian Fainelli, Mark Rutland,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm
On Thu, Feb 22, 2024 at 10:40:29PM -0800, Stephen Boyd wrote:
> Per commit b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with
> CC_OPTIMIZE_FOR_SIZE"), GCC is silently ignoring `-falign-functions=N`
> when passed `-Os`, causing functions to be improperly aligned. This
> doesn't seem to be a problem with Clang though, where enabling CALL_OPS
> with CC_OPTIMIZE_FOR_SIZE doesn't spit out any warnings at boot about
> misaligned patch-sites. Only forbid CALL_OPS if GCC is used and we're
> optimizing for size so that CALL_OPS can be used with clang optimizing
> for size.
>
> Cc: Jason Ling <jasonling@chromium.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> 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: <llvm@lists.linux.dev>
> Fixes: b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with CC_OPTIMIZE_FOR_SIZE")
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I wonder if that GCC issue is resolved with '-fmin-function-alignment'
that is being introduced in GCC 14 [1]. If it is, I suspect this
conditional could actually be CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT
instead of CONFIG_CC_IS_CLANG, but that can obviously happen as a clean
up later down the road (more just food for thought for the arm64 folks,
not sure how much '-Os' is used in general)
[1]: https://git.kernel.org/masahiroy/linux-kbuild/c/5270316c9fec8cc99aa0e0a258509c5c7f789d12
> ---
> arch/arm64/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index aa7c1d435139..6b96d75a3a3d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -198,7 +198,7 @@ config ARM64
> if DYNAMIC_FTRACE_WITH_ARGS && DYNAMIC_FTRACE_WITH_CALL_OPS
> select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
> if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG && \
> - !CC_OPTIMIZE_FOR_SIZE)
> + (CC_IS_CLANG || !CC_OPTIMIZE_FOR_SIZE))
> select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
> if DYNAMIC_FTRACE_WITH_ARGS
> select HAVE_SAMPLE_FTRACE_DIRECT
>
> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> --
> https://chromeos.dev
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with Clang
@ 2024-02-25 19:54 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-25 19:54 UTC (permalink / raw)
To: Stephen Boyd
Cc: Catalin Marinas, Will Deacon, linux-kernel, patches,
linux-arm-kernel, Jason Ling, Florian Fainelli, Mark Rutland,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm
On Thu, Feb 22, 2024 at 10:40:29PM -0800, Stephen Boyd wrote:
> Per commit b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with
> CC_OPTIMIZE_FOR_SIZE"), GCC is silently ignoring `-falign-functions=N`
> when passed `-Os`, causing functions to be improperly aligned. This
> doesn't seem to be a problem with Clang though, where enabling CALL_OPS
> with CC_OPTIMIZE_FOR_SIZE doesn't spit out any warnings at boot about
> misaligned patch-sites. Only forbid CALL_OPS if GCC is used and we're
> optimizing for size so that CALL_OPS can be used with clang optimizing
> for size.
>
> Cc: Jason Ling <jasonling@chromium.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> 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: <llvm@lists.linux.dev>
> Fixes: b3f11af9b2ce ("arm64: ftrace: forbid CALL_OPS with CC_OPTIMIZE_FOR_SIZE")
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
I wonder if that GCC issue is resolved with '-fmin-function-alignment'
that is being introduced in GCC 14 [1]. If it is, I suspect this
conditional could actually be CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT
instead of CONFIG_CC_IS_CLANG, but that can obviously happen as a clean
up later down the road (more just food for thought for the arm64 folks,
not sure how much '-Os' is used in general)
[1]: https://git.kernel.org/masahiroy/linux-kbuild/c/5270316c9fec8cc99aa0e0a258509c5c7f789d12
> ---
> arch/arm64/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index aa7c1d435139..6b96d75a3a3d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -198,7 +198,7 @@ config ARM64
> if DYNAMIC_FTRACE_WITH_ARGS && DYNAMIC_FTRACE_WITH_CALL_OPS
> select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
> if (DYNAMIC_FTRACE_WITH_ARGS && !CFI_CLANG && \
> - !CC_OPTIMIZE_FOR_SIZE)
> + (CC_IS_CLANG || !CC_OPTIMIZE_FOR_SIZE))
> select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
> if DYNAMIC_FTRACE_WITH_ARGS
> select HAVE_SAMPLE_FTRACE_DIRECT
>
> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> --
> https://chromeos.dev
>
_______________________________________________
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: Prebuilt LLVM 18.1.0-rc2 uploaded
@ 2024-02-27 15:37 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-27 15:37 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: llvm, linux-kernel, Conor Dooley, Conor Dooley
On Tue, Feb 27, 2024 at 01:32:36PM +0100, Miguel Ojeda wrote:
> On Tue, Feb 13, 2024 at 9:37 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > Thanks Nathan, that was quick!
>
> Is it possible to add libclang for the older toolchains? Or are they
> supposed to be immutable?
How far back would you like it added? I don't necessarily mind
rebuilding older releases but certain entities may notice the checksums
change.
https://gitlab.com/Linaro/tuxmake/-/merge_requests/364
Not the end of the world though.
> Relatedly, Connor reports KCFI not working with LLVM 18:
> https://lore.kernel.org/rust-for-linux/20240227-uncertain-amaze-6197e627ad95@wendy/
I see now this was PEBKAC :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] power: supply: core: Fix power_supply_init_attrs() stub
@ 2024-02-27 21:49 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-27 21:49 UTC (permalink / raw)
To: Ricardo B. Marliere; +Cc: sre, linux-pm, patches
On Tue, Feb 27, 2024 at 05:39:55PM -0300, Ricardo B. Marliere wrote:
> Hi Nathan,
>
> On 27 Feb 13:34, Nathan Chancellor wrote:
> > When building without CONFIG_SYSFS, there is an error because of a
> > recent refactoring that failed to update the stub of
> > power_supply_init_attrs():
> >
> > drivers/power/supply/power_supply_core.c: In function 'power_supply_class_init':
> > drivers/power/supply/power_supply_core.c:1630:9: error: too few arguments to function 'power_supply_init_attrs'
> > 1630 | power_supply_init_attrs();
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/power/supply/power_supply_core.c:25:
> > drivers/power/supply/power_supply.h:25:20: note: declared here
> > 25 | static inline void power_supply_init_attrs(struct device_type *dev_type) {}
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Update the stub function to take no parameters like the rest of the
> > refactoring, which resolves the build error.
> >
> > Fixes: 7b46b60944d7 ("power: supply: core: constify the struct device_type usage")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > drivers/power/supply/power_supply.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> > ────────────────────────────────────────────────────────────────────────────────
> > modified: drivers/power/supply/power_supply.h
> > ────────────────────────────────────────────────────────────────────────────────
> > @ drivers/power/supply/power_supply.h:25 @ extern int power_supply_uevent(const struct device *dev, struct kobj_uevent_env
> >
> > #else
> >
> > static inline void power_supply_init_attrs(struct device_type *dev_type) {}
> > static inline void power_supply_init_attrs(void) {}
>
> I've missed that #else in my building test. Thanks for catching it.
>
> Reviewed-by: Ricardo B. Marliere <ricardo@marliere.net>
Thanks a lot for the quick feedback and no worries, it is hard to test
to catch these without doing a lot of build tests.
Unfortunately, I caught another problem with that change that is
independent of this one:
ld.lld: error: undefined symbol: power_supply_attr_group
>>> referenced by power_supply_core.c
>>> drivers/power/supply/power_supply_core.o:(power_supply_attr_groups) in archive vmlinux.a
>>> did you mean: power_supply_attr_groups
>>> defined in: vmlinux.a(drivers/power/supply/power_supply_core.o)
It looks like power_supply_attr_groups refers to power_supply_attr_group
but power_supply_attr_group is declared extern without a definition with
CONFIG_SYSFS=n. It is not immediately obvious to me what the fix is.
Cheers,
Nathan
> > #define power_supply_uevent NULL
> >
> > #endif /* CONFIG_SYSFS */
> >
> > --
> > base-commit: 3da8d71754d3c1aa0b72d74c8a324a4bc7fab473
> > change-id: 20240227-fix-power_supply_init_attrs-stub-7be5328b4e72
> >
> > Best regards,
> > -
> > Nathan Chancellor <nathan@kernel.org>
> >
^ permalink raw reply [relevance 99%]
* Re: Prebuilt LLVM 18.1.0-rc2 uploaded
@ 2024-02-27 21:56 99% ` Nathan Chancellor
2024-02-28 18:43 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-27 21:56 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: llvm, linux-kernel, Conor Dooley, Conor Dooley
On Tue, Feb 27, 2024 at 05:51:04PM +0100, Miguel Ojeda wrote:
> On Tue, Feb 27, 2024 at 4:37 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > How far back would you like it added? I don't necessarily mind
> > rebuilding older releases but certain entities may notice the checksums
> > change.
> >
> > https://gitlab.com/Linaro/tuxmake/-/merge_requests/364
> >
> > Not the end of the world though.
>
> I think a reasonable set would be those versions matching the LLVM
> that Rust bundles (for `rustc` versions we have since 6.1 LTS). That
> is: 15, 16 and 17.
>
> Conveniently, LLVM 15 also matches the minimum external LLVM supported
> by `rustc` in 6.6 LTS.
>
> If those are too much, LLVM 17 would already cover what 6.6 LTS' Rust bundles.
15 through 17 is a reasonable rebuild request, I've added it to the
queue along with 18.1.0-rc4, which was just released. I'll message you
when I have them uploaded.
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%]
* Re: [PATCH] thermal: core: Move initial num_trips assignment before memcpy()
@ 2024-02-28 16:56 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28 16:56 UTC (permalink / raw)
To: Lukasz Luba
Cc: Kees Cook, Rafael J. Wysocki, rui.zhang, gustavoars, morbo,
justinstitt, stanislaw.gruszka, linux-pm, linux-hardening, llvm,
patches, Daniel Lezcano
On Wed, Feb 28, 2024 at 08:41:07AM +0000, Lukasz Luba wrote:
> Hi Nathan and Kees,
>
> On 2/27/24 17:00, Kees Cook wrote:
> > On Tue, Feb 27, 2024 at 05:47:44PM +0100, Daniel Lezcano wrote:
> > > Ok my misunderstanding was I thought sizeof() was calling _bdos under the
> > > hood, so when calling sizeof(flex_array), it was returning the computed size
> > > inferring from the __counted_by field.
> >
> > Yeah, sizeof() has a very limited scope. __builtin_object_size() has
> > more flexibility (via the 2nd argument, "type"), but it was still
> > compile-time only. __builtin_dynamic_object_size() was added to bring
> > runtime evaluations into the mix (initially to support the alloc_size
> > attribute, and now includes the counted_by attribute too).
> >
>
> Thanks for your earlier emails explaining these stuff.
> Do you have maybe some presentation about those features
> for the kernel (ideally w/ a video from some conference)?
I think Kees's 2022 and 2023 talks at LPC are a good place to start:
https://youtu.be/tQwv79i02ks?si=Nj9hpvmQwPB4K3Y4&t=452
https://youtu.be/OEFFqhP5sts?si=u6RnOP641S8FkouD&t=614
https://outflux.net/slides/2022/lpc/features.pdf
https://outflux.net/slides/2023/lpc/features.pdf
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [Linaro-TCWG-CI] llvmorg-19-init-3481-g8c2ae42b3e1c: Failure on aarch64
@ 2024-02-28 17:05 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28 17:05 UTC (permalink / raw)
To: linaro-toolchain; +Cc: llvm
On Wed, Feb 28, 2024 at 02:47:11PM +0000, ci_notify@linaro.org wrote:
> Dear contributor, our automatic CI has detected problems related to your patch(es). Please find some details below. If you have any questions, please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the usual project channel.
>
> We appreciate that it might be difficult to find the necessary logs or reproduce the issue locally. If you can't get what you need from our CI within minutes, let us know and we will be happy to help.
>
> We track this report status in https://linaro.atlassian.net/browse/LLVM-1153 , please let us know if you are looking at the problem and/or when you have a fix.
>
> In CI config tcwg_kernel/llvm-master-aarch64-lts-allyesconfig after:
>
> | commit llvmorg-19-init-3481-g8c2ae42b3e1c
> | Author: Kupa-Martin <84517188+Kupa-Martin@users.noreply.github.com>
> | Date: Tue Feb 27 11:58:59 2024 -0300
> |
> | [Clang][Sema] Fix missing warning when comparing mismatched enums in … (#81418)
> |
> | …C mode
> |
> | Factored logic from `CheckImplicitConversion` into new methods
> | `Expr::getEnumConstantDecl` and `Expr::getEnumCoercedType` for use in
> | `checkEnumArithmeticConversions`.
> | ... 2 lines of the commit log omitted.
>
> Results changed to
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_kernel_llvm:
> -5
> # build_abe qemu:
> -2
> # linux_n_obj:
> 37
>
> From
> # reset_artifacts:
> -10
> # build_abe binutils:
> -9
> # build_kernel_llvm:
> -5
> # build_abe qemu:
> -2
> # linux_n_obj:
> 22291
>
> The configuration of this build is:
> CI config tcwg_kernel/llvm-master-aarch64-lts-allyesconfig
>
> -----------------8<--------------------------8<--------------------------8<--------------------------
> The information below can be used to reproduce a debug environment:
>
> Current build : https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-lts-allyesconfig-build/143/artifact/artifacts
> Reference build : https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-lts-allyesconfig-build/142/artifact/artifacts
>
> Reproduce last good and first bad builds: https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/sha1/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e/tcwg_kernel/llvm-master-aarch64-lts-allyesconfig/reproduction_instructions.txt
>
> Full commit : https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
>
> List of configurations that regressed due to this commit :
> * tcwg_kernel
> ** llvm-master-aarch64-lts-allyesconfig
> *** Failure
> *** https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/llvm/sha1/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e/tcwg_kernel/llvm-master-aarch64-lts-allyesconfig/details.txt
> *** https://ci.linaro.org/job/tcwg_kernel--llvm-master-aarch64-lts-allyesconfig-build/143/artifact/artifacts
Thanks a lot for the report, this is expected with that change. How we
want to handle this in the kernel is currently under discussion at
https://github.com/ClangBuiltLinux/linux/issues/2002.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] power: supply: move power_supply_attr_group into #ifdef block
@ 2024-02-28 17:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28 17:10 UTC (permalink / raw)
To: Ricardo B. Marliere
Cc: Sebastian Reichel, Sebastian Reichel, linux-pm, linux-kernel,
Greg Kroah-Hartman
On Wed, Feb 28, 2024 at 10:46:28AM -0300, Ricardo B. Marliere wrote:
> When building with CONFIG_SYSFS=n, the build error below is triggered:
>
> ld: drivers/power/supply/power_supply_core.o:(.data+0x0): undefined
> reference to `power_supply_attr_group'
>
> The problem is that power_supply_attr_group is needed in
> power_supply_core.c but defined in power_supply_sysfs.c, which is only
> targeted with CONFIG_SYSFS=y. Therefore, move the extern declaration into
> the #ifdef block that checks for CONFIG_SYSFS, and define an empty static
> const struct otherwise. This is safe because the macro __ATRIBUTE_GROUPS in
> power_supply_core.c will expand into an empty attribute_group array.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Link: https://lore.kernel.org/all/20240227214916.GA3699076@dev-arch.thelio-3990X/
> Fixes: 7b46b60944d7 ("power: supply: core: constify the struct device_type usage")
> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Thanks for the quick fix!
> ---
> This patch depends on [1].
> [1]: 20240227-fix-power_supply_init_attrs-stub-v1-1-43365e68d4b3@kernel.org
> ---
> drivers/power/supply/power_supply.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/power_supply.h b/drivers/power/supply/power_supply.h
> index 7d05756398b9..06749a534db4 100644
> --- a/drivers/power/supply/power_supply.h
> +++ b/drivers/power/supply/power_supply.h
> @@ -13,16 +13,16 @@ struct device;
> struct device_type;
> struct power_supply;
>
> -extern const struct attribute_group power_supply_attr_group;
> -
> #ifdef CONFIG_SYSFS
>
> extern void power_supply_init_attrs(void);
> extern int power_supply_uevent(const struct device *dev, struct kobj_uevent_env *env);
> +extern const struct attribute_group power_supply_attr_group;
>
> #else
>
> static inline void power_supply_init_attrs(void) {}
> +static const struct attribute_group power_supply_attr_group;
> #define power_supply_uevent NULL
>
> #endif /* CONFIG_SYSFS */
>
> ---
> base-commit: 837af6b0cdb2b8df56d2df35db0444cfa1ea47c2
> change-id: 20240228-device_cleanup-power-2dcfaa7b7f2b
>
> Best regards,
> --
> Ricardo B. Marliere <ricardo@marliere.net>
>
^ permalink raw reply [relevance 99%]
* Re: Prebuilt LLVM 18.1.0-rc2 uploaded
2024-02-27 21:56 99% ` Nathan Chancellor
@ 2024-02-28 18:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28 18:43 UTC (permalink / raw)
To: Miguel Ojeda; +Cc: llvm, linux-kernel, Conor Dooley, Conor Dooley
O Tue, Feb 27, 2024 at 02:56:05PM -0700, Nathan Chancellor wrote:
> On Tue, Feb 27, 2024 at 05:51:04PM +0100, Miguel Ojeda wrote:
> > On Tue, Feb 27, 2024 at 4:37 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > How far back would you like it added? I don't necessarily mind
> > > rebuilding older releases but certain entities may notice the checksums
> > > change.
> > >
> > > https://gitlab.com/Linaro/tuxmake/-/merge_requests/364
> > >
> > > Not the end of the world though.
> >
> > I think a reasonable set would be those versions matching the LLVM
> > that Rust bundles (for `rustc` versions we have since 6.1 LTS). That
> > is: 15, 16 and 17.
> >
> > Conveniently, LLVM 15 also matches the minimum external LLVM supported
> > by `rustc` in 6.6 LTS.
> >
> > If those are too much, LLVM 17 would already cover what 6.6 LTS' Rust bundles.
>
> 15 through 17 is a reasonable rebuild request, I've added it to the
> queue along with 18.1.0-rc4, which was just released. I'll message you
> when I have them uploaded.
This is now done, please let me know if there are any issues!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.0-rc4 uploaded
@ 2024-02-28 18:46 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-28 18:46 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded a prebuilt version of LLVM 18.1.0-rc4 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
As with Linux -rc releases, this is not the final version that will
ship. If you run across any issues, especially ones that were not
present in earlier LLVM releases, please consider reporting them to us
so that we have a chance to investigate and fix them before the final
release.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: pinctrl: single: Cannot disable bias - PIN_CONFIG_BIAS_DISABLE not handled
@ 2024-02-29 18:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-02-29 18:31 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Matthijs Kooijman, linux-gpio, Haojian Zhuang
On Thu, Feb 29, 2024 at 09:32:11AM +0200, Tony Lindgren wrote:
> > cause. I also do not have a good toolchain setup for compiling custom
> > kernels for this setup (and limited time for setting up one), so I do
> > not expect to be able to provide more testing or a patch anytime soon.
>
> The buildall script should allow you to easily build a cross compiler
> on pretty much any current Linux host. I think this is the current
> git tree for it:
>
> https://github.com/nathanchance/buildall
That is actually a fork of
http://git.infradead.org/users/segher/buildall.git from Segher
Boessenkool, which appears to no longer exist, so good thing I did that
:)
> Seems like buildall should be hosted at kernel.org but I don't know the
> details, so adding Nathan to Cc too.
For what it's worth, there are prebuilt GCC and LLVM toolchains on
kernel.org that should work with the majority of distros on aarch64 and
x86_64 hosts.
https://mirrors.edge.kernel.org/pub/tools/crosstool/
https://mirrors.edge.kernel.org/pub/tools/llvm/
Arnd maintains the GCC ones, I maintain the LLVM ones.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [trace:trace/for-next 28/29] include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead)
@ 2024-02-29 23:44 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-02-29 23:44 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, llvm, oe-kbuild-all, Masami Hiramatsu (Google)
Hi Steve,
On Thu, Feb 29, 2024 at 06:06:16PM -0500, Steven Rostedt wrote:
> On Thu, 29 Feb 2024 21:35:53 +0800
> kernel test robot <lkp@intel.com> wrote:
>
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace trace/for-next
> > head: eb1533d156d307c2125943eaf1925e268094d984
> > commit: 433e1d88a3be93222989e52fa99594fe9eb93622 [28/29] tracing: Add warning if string in __assign_str() does not match __string()
> > config: x86_64-kexec (https://download.01.org/0day-ci/archive/20240229/202402292111.KIdExylU-lkp@intel.com/config)
> > compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240229/202402292111.KIdExylU-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202402292111.KIdExylU-lkp@intel.com/
> >
> > All warnings (new ones prefixed by >>):
> >
> > In file included from net/sunrpc/sched.c:31:
> > In file included from include/trace/events/sunrpc.h:2520:
> > In file included from include/trace/define_trace.h:102:
> > In file included from include/trace/trace_events.h:419:
> > >> include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]
> > 663 | __assign_str(progname,
> > | ~~~~~~~~~~~~~~~~~~~~~~
> > 664 | task->tk_client->cl_program->name);
> > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 665 | __entry->version = task->tk_client->cl_vers;
> > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 666 | __assign_str(procedure, task->tk_msg.rpc_proc->p_name);
> > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 667 | } else {
> > | ~~~~~~~~
> > 668 | __entry->task_id = -1;
> > | ~~~~~~~~~~~~~~~~~~~~~~
> > 669 | __entry->client_id = -1;
> > | ~~~~~~~~~~~~~~~~~~~~~~~~
> > 670 | __assign_str(progname, "unknown");
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 671 | __entry->version = 0;
> > | ~~~~~~~~~~~~~~~~~~~~~
> > 672 | __assign_str(procedure, "unknown");
> > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 673 | }
>
>
> I don't build with clang, does this quiet the warning?
Unfortunately, it does not. I tested with LLVM 17.0.6 from kernel.org:
https://mirrors.edge.kernel.org/pub/tools/llvm/
If there is no other way to silence it, we could potentially use the
diag infrastructure to silence it, I could look at that tomorrow.
Cheers,
Nathan
> diff --git a/include/trace/stages/stage6_event_callback.h b/include/trace/stages/stage6_event_callback.h
> index a0c15f67eabe..83da83a0c14f 100644
> --- a/include/trace/stages/stage6_event_callback.h
> +++ b/include/trace/stages/stage6_event_callback.h
> @@ -35,7 +35,9 @@
> do { \
> char *__str__ = __get_str(dst); \
> int __len__ = __get_dynamic_array_len(dst) - 1; \
> - WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_); \
> + WARN_ON_ONCE(__builtin_constant_p(src) ? \
> + strcmp((src), __data_offsets.dst##_ptr_) : \
> + (src) != __data_offsets.dst##_ptr_); \
> memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
> EVENT_NULL_STR, __len__); \
> __str__[__len__] = '\0'; \
> --
> 2.43.0
>
>
^ permalink raw reply [relevance 99%]
* Re: net/netfilter/nf_bpf_link.c:186:33: warning: bitwise operation between different enumeration types ('enum bpf_reg_type' and 'enum bpf_type_flag')
@ 2024-03-01 3:50 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-01 3:50 UTC (permalink / raw)
To: kernel test robot
Cc: Florian Westphal, llvm, oe-kbuild-all, linux-kernel, Alexei Starovoitov
Hi all,
On Fri, Mar 01, 2024 at 08:57:56AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 87adedeba51a822533649b143232418b9e26d08b
> commit: fd9c663b9ad67dedfc9a3fd3429ddd3e83782b4d bpf: minimal support for programs hooked into netfilter framework
> date: 10 months ago
> config: riscv-defconfig (https://download.01.org/0day-ci/archive/20240301/202403010842.hhJY5TFK-lkp@intel.com/config)
> compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project edd4aee4dd9b5b98b2576a6f783e4086173d902a)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240301/202403010842.hhJY5TFK-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202403010842.hhJY5TFK-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
<snip>
While this change may introduce an instance of this warning, it is
actually a change on the clang side that causes this and I am still
looking for input on what to do about it:
https://github.com/ClangBuiltLinux/linux/issues/2002
I think this report can just be ignored for now. The Intel folks may
want to consider sending -Wenum-enum-conversion and
-Wenum-compare-conditional reports to our mailing list only until we can
sort this out. Sorry for the noise.
Cheers,
Nathan
> >> net/netfilter/nf_bpf_link.c:186:33: warning: bitwise operation between different enumeration types ('enum bpf_reg_type' and 'enum bpf_type_flag') [-Wenum-enum-conversion]
> 186 | info->reg_type = PTR_TO_BTF_ID | PTR_TRUSTED;
> | ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~
> 22 warnings generated.
>
>
> vim +186 net/netfilter/nf_bpf_link.c
>
> 170
> 171 static bool nf_ptr_to_btf_id(struct bpf_insn_access_aux *info, const char *name)
> 172 {
> 173 struct btf *btf;
> 174 s32 type_id;
> 175
> 176 btf = bpf_get_btf_vmlinux();
> 177 if (IS_ERR_OR_NULL(btf))
> 178 return false;
> 179
> 180 type_id = btf_find_by_name_kind(btf, name, BTF_KIND_STRUCT);
> 181 if (WARN_ON_ONCE(type_id < 0))
> 182 return false;
> 183
> 184 info->btf = btf;
> 185 info->btf_id = type_id;
> > 186 info->reg_type = PTR_TO_BTF_ID | PTR_TRUSTED;
> 187 return true;
> 188 }
> 189
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
^ permalink raw reply [relevance 99%]
* Re: [trace:trace/for-next 28/29] include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead)
@ 2024-03-01 4:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-01 4:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, llvm, oe-kbuild-all, Masami Hiramatsu (Google)
On Thu, Feb 29, 2024 at 06:55:58PM -0500, Steven Rostedt wrote:
> On Thu, 29 Feb 2024 16:44:55 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
>
> > > I don't build with clang, does this quiet the warning?
> >
> > Unfortunately, it does not. I tested with LLVM 17.0.6 from kernel.org:
> >
> > https://mirrors.edge.kernel.org/pub/tools/llvm/
> >
> > If there is no other way to silence it, we could potentially use the
> > diag infrastructure to silence it, I could look at that tomorrow.
>
> Is it the exact same warning? I wonder if I make it into an if statement,
> it would be better?
>
> #define __assign_str(dst, src) \
> do { \
> char *__str__ = __get_str(dst); \
> int __len__ = __get_dynamic_array_len(dst) - 1; \
> if (__builtin_constant_p(src)) \
> WARN_ON_ONCE(strcmp((src), __data_offsets.dst##_ptr_)); \
> else \
> WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_);\
> memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
> EVENT_NULL_STR, __len__); \
> __str__[__len__] = '\0'; \
> } while (0)
>
> Then the compiler may be better in optimizing out the "bad" portion.
No, that does not work either, I diffed the warnings and they are
identical minus line numbers. I don't think clang takes
__builtin_constant_p() into account in the front end but I could be
wrong. In fact, I think clang (and even gcc sometimes) will still warn
for code even if it is within an 'if (0)' block, it's been used as
justification before in commit 37b47298ab86 ("sched: Disable
-Wunused-but-set-variable").
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 05/24] ALSA: hwdep: Use guard() for locking
@ 2024-03-01 17:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-01 17:10 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-sound, llvm
On Fri, Mar 01, 2024 at 08:27:43AM +0100, Takashi Iwai wrote:
> On Thu, 29 Feb 2024 22:00:34 +0100,
> Nathan Chancellor wrote:
> >
> > Hi Takashi,
> >
> > On Tue, Feb 27, 2024 at 09:52:47AM +0100, Takashi Iwai wrote:
> > > We can simplify the code gracefully with new guard() macro and co for
> > > automatic cleanup of locks.
> > >
> > > There are still a few remaining explicit mutex_lock/unlock calls, and
> > > those are for the places where we do temporary unlock/relock, which
> > > doesn't fit well with the guard(), so far.
> > >
> > > Only the code refactoring, and no functional changes.
> > >
> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > ---
> > > sound/core/hwdep.c | 85 +++++++++++++++++++++-------------------------
> > > 1 file changed, 38 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/sound/core/hwdep.c b/sound/core/hwdep.c
> > > index de7476034f2c..9d7e5039c893 100644
> > > --- a/sound/core/hwdep.c
> > > +++ b/sound/core/hwdep.c
> > > @@ -149,12 +149,12 @@ static int snd_hwdep_release(struct inode *inode, struct file * file)
> > > struct snd_hwdep *hw = file->private_data;
> > > struct module *mod = hw->card->module;
> > >
> > > - mutex_lock(&hw->open_mutex);
> > > - if (hw->ops.release)
> > > - err = hw->ops.release(hw, file);
> > > - if (hw->used > 0)
> > > - hw->used--;
> > > - mutex_unlock(&hw->open_mutex);
> > > + scoped_guard(mutex, &hw->open_mutex) {
> > > + if (hw->ops.release)
> > > + err = hw->ops.release(hw, file);
> > > + if (hw->used > 0)
> > > + hw->used--;
> > > + }
> > > wake_up(&hw->open_wait);
> > >
> > > snd_card_file_remove(hw->card, file);
> > > @@ -272,43 +272,43 @@ static int snd_hwdep_control_ioctl(struct snd_card *card,
> > >
> > > if (get_user(device, (int __user *)arg))
> > > return -EFAULT;
> > > - mutex_lock(®ister_mutex);
> > >
> > > - if (device < 0)
> > > - device = 0;
> > > - else if (device < SNDRV_MINOR_HWDEPS)
> > > - device++;
> > > - else
> > > - device = SNDRV_MINOR_HWDEPS;
> > > + scoped_guard(mutex, ®ister_mutex) {
> > > + if (device < 0)
> > > + device = 0;
> > > + else if (device < SNDRV_MINOR_HWDEPS)
> > > + device++;
> > > + else
> > > + device = SNDRV_MINOR_HWDEPS;
> > >
> > > - while (device < SNDRV_MINOR_HWDEPS) {
> > > - if (snd_hwdep_search(card, device))
> > > - break;
> > > - device++;
> > > + while (device < SNDRV_MINOR_HWDEPS) {
> > > + if (snd_hwdep_search(card, device))
> > > + break;
> > > + device++;
> > > + }
> > > + if (device >= SNDRV_MINOR_HWDEPS)
> > > + device = -1;
> > > + if (put_user(device, (int __user *)arg))
> > > + return -EFAULT;
> > > + return 0;
> > > }
> > > - if (device >= SNDRV_MINOR_HWDEPS)
> > > - device = -1;
> > > - mutex_unlock(®ister_mutex);
> > > - if (put_user(device, (int __user *)arg))
> > > - return -EFAULT;
> > > - return 0;
> > > + break;
> > > }
> >
> > Due to a bug in clang that was resolved in clang-17 [1], clang-13
> > through clang-16 fail to build this file for ARCH=powerpc after this
> > change in -next as commit e6684d08cc19 ("ALSA: hwdep: Use guard() for
> > locking"):
> >
> > sound/core/hwdep.c:291:9: error: cannot jump from this asm goto statement to one of its possible targets
> > if (put_user(device, (int __user *)arg))
> > ^
> > arch/powerpc/include/asm/uaccess.h:66:5: note: expanded from macro 'put_user'
> > __put_user(x, _pu_addr) : -EFAULT; \
> > ^
> > arch/powerpc/include/asm/uaccess.h:48:3: note: expanded from macro '__put_user'
> > __put_user_size_goto(__pu_val, __pu_addr, __pu_size, __pu_failed); \
> > ^
> > arch/powerpc/include/asm/uaccess.h:116:10: note: expanded from macro '__put_user_size_goto'
> > case 1: __put_user_asm_goto(x, __pus_addr, label, "stb"); break; \
> > ^
> > arch/powerpc/include/asm/uaccess.h:86:2: note: expanded from macro '__put_user_asm_goto'
> > asm goto( \
> > ^
> > sound/core/hwdep.c:273:8: note: possible target of asm goto statement
> > if (get_user(device, (int __user *)arg))
> > ^
> > arch/powerpc/include/asm/uaccess.h:295:5: note: expanded from macro 'get_user'
> > __get_user(x, _gu_addr) : \
> > ^
> > arch/powerpc/include/asm/uaccess.h:283:2: note: expanded from macro '__get_user'
> > __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
> > ^
> > arch/powerpc/include/asm/uaccess.h:201:16: note: expanded from macro '__get_user_size_allowed'
> > break; \
> > ^
> > sound/core/hwdep.c:276:4: note: jump exits scope of variable with __attribute__((cleanup))
> > scoped_guard(mutex, ®ister_mutex) {
> > ^
> > include/linux/cleanup.h:169:20: note: expanded from macro 'scoped_guard'
> > for (CLASS(_name, scope)(args), \
> > ^
> > sound/core/hwdep.c:273:8: error: cannot jump from this asm goto statement to one of its possible targets
> > if (get_user(device, (int __user *)arg))
> > ^
> > arch/powerpc/include/asm/uaccess.h:295:5: note: expanded from macro 'get_user'
> > __get_user(x, _gu_addr) : \
> > ^
> > arch/powerpc/include/asm/uaccess.h:283:2: note: expanded from macro '__get_user'
> > __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
> > ^
> > arch/powerpc/include/asm/uaccess.h:199:3: note: expanded from macro '__get_user_size_allowed'
> > __get_user_size_goto(x, ptr, size, __gus_failed); \
> > ^
> > arch/powerpc/include/asm/uaccess.h:187:10: note: expanded from macro '__get_user_size_goto'
> > case 1: __get_user_asm_goto(x, (u8 __user *)ptr, label, "lbz"); break; \
> > ^
> > arch/powerpc/include/asm/uaccess.h:158:2: note: expanded from macro '__get_user_asm_goto'
> > asm_goto_output( \
> > ^
> > include/linux/compiler_types.h:380:31: note: expanded from macro 'asm_goto_output'
> > #define asm_goto_output(x...) asm volatile goto(x)
> > ^
> > sound/core/hwdep.c:291:9: note: possible target of asm goto statement
> > if (put_user(device, (int __user *)arg))
> > ^
> > arch/powerpc/include/asm/uaccess.h:66:5: note: expanded from macro 'put_user'
> > __put_user(x, _pu_addr) : -EFAULT; \
> > ^
> > arch/powerpc/include/asm/uaccess.h:52:9: note: expanded from macro '__put_user'
> > \
> > ^
> > sound/core/hwdep.c:276:4: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > scoped_guard(mutex, ®ister_mutex) {
> > ^
> > include/linux/cleanup.h:169:20: note: expanded from macro 'scoped_guard'
> > for (CLASS(_name, scope)(args), \
> > ^
> > 2 errors generated.
> >
> > However, looking at the original change, could this be avoided/worked
> > around by just moving the put_user() call out of the scoped_guard()?
> > The put_user() call was not originally under register_mutex, so it seems
> > like this would work? As I understand it, mutex_unlock() will be called
> > once the scope of the guard is left. I am happy to send a formal patch.
>
> Yes, that was my intention but somehow it slipped :-<
> Could you submit the fix patch?
Sure thing: https://lore.kernel.org/20240301-fix-snd-hwdep-guard-v1-1-6aab033f3f83@kernel.org/
Thanks for the input!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* 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%]
* Re: [PATCH] kbuild: fix inconsistent indentation in top Makefile
@ 2024-03-01 22:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-01 22:16 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-kbuild, linux-kernel, Nicolas Schier
On Fri, Mar 01, 2024 at 08:21:07PM +0900, Masahiro Yamada wrote:
> Commit 3b9ab248bc45 ("kbuild: use 4-space indentation when followed
> by conditionals") introduced inconsistent indentation because it
> deliberately touched only the conditional directives to minimize the
> change set.
>
> This commit reformats some blocks in the top Makefile so they are
> consistently indented with 4 spaces.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> Makefile | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d84c0fb215fd..859b0f52949e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -295,51 +295,51 @@ single-build :=
>
> ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
> ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
> - need-config :=
> + need-config :=
> endif
> endif
>
> ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
> ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
> - may-sync-config :=
> + may-sync-config :=
> endif
> endif
>
> need-compiler := $(may-sync-config)
>
> ifneq ($(KBUILD_EXTMOD),)
> - may-sync-config :=
> + may-sync-config :=
> endif
>
> ifeq ($(KBUILD_EXTMOD),)
> - ifneq ($(filter %config,$(MAKECMDGOALS)),)
> - config-build := 1
> - ifneq ($(words $(MAKECMDGOALS)),1)
> - mixed-build := 1
> - endif
> + ifneq ($(filter %config,$(MAKECMDGOALS)),)
> + config-build := 1
> + ifneq ($(words $(MAKECMDGOALS)),1)
> + mixed-build := 1
> endif
> + endif
> endif
>
> # We cannot build single targets and the others at the same time
> ifneq ($(filter $(single-targets), $(MAKECMDGOALS)),)
> - single-build := 1
> + single-build := 1
> ifneq ($(filter-out $(single-targets), $(MAKECMDGOALS)),)
> - mixed-build := 1
> + mixed-build := 1
> endif
> endif
>
> # For "make -j clean all", "make -j mrproper defconfig all", etc.
> ifneq ($(filter $(clean-targets),$(MAKECMDGOALS)),)
> - ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
> - mixed-build := 1
> - endif
> + ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
> + mixed-build := 1
> + endif
> endif
>
> # install and modules_install need also be processed one by one
> ifneq ($(filter install,$(MAKECMDGOALS)),)
> - ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
> - mixed-build := 1
> - endif
> + ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
> + mixed-build := 1
> + endif
> endif
>
> ifdef mixed-build
> --
> 2.40.1
>
^ 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%]
* Re: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
@ 2024-03-05 22:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 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] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
@ 2024-03-05 22:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-05 22:43 UTC (permalink / raw)
To: mpe
Cc: llvm, patches, aneesh.kumar, npiggin, justinstitt, naveen.n.rao,
stable, linuxppc-dev, morbo
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] 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%]
* 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: llvm, patches, aneesh.kumar, npiggin, justinstitt, naveen.n.rao,
stable, linuxppc-dev, morbo
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%]
* Re: [PATCH] kbuild: remove GCC's default -Wpacked-bitfield-compat flag
@ 2024-03-06 16:49 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-06 16:49 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, linux-kernel, Bill Wendling, Justin Stitt,
Nick Desaulniers, Nicolas Schier, llvm
On Wed, Mar 06, 2024 at 09:47:09PM +0900, Masahiro Yamada wrote:
> Commit 4a5838ad9d2d ("kbuild: Add extra gcc checks") added the
> -Wpacked-bitfield-compat flag.
>
> GCC manual says:
> "This warning is enabled by default. Use -Wno-packed-bitfield-compat
> to disable this warning."
>
> The test code in the manual:
>
> struct foo
> {
> char a:4;
> char b:8;
> } __attribute__ ((packed));
>
> ... emits "note: offset of packed bit-field ‘b’ has changed in GCC 4.4"
> without W=3.
>
> Let's remove it, as it is a default with GCC.
>
> Clang does not support this flag, so its removal will not affect Clang
> builds.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> scripts/Makefile.extrawarn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index a9e552a1e910..8192b497aae8 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -185,7 +185,6 @@ KBUILD_CFLAGS += -Wpointer-arith
> KBUILD_CFLAGS += -Wredundant-decls
> KBUILD_CFLAGS += -Wsign-compare
> KBUILD_CFLAGS += -Wswitch-default
> -KBUILD_CFLAGS += $(call cc-option, -Wpacked-bitfield-compat)
>
> KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN3
>
> --
> 2.40.1
>
>
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.0 uploaded
@ 2024-03-07 0:08 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-07 0:08 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.0 to
https://mirrors.edge.kernel.org/pub/tools/llvm/. This is the first
stable release of the 18.x series, as LLVM has adopted a similar
versioning scheme to GCC where main/tip of tree is x.0.0 and that is
bumped to x.1.0 when the release branch is created for the final
release, with subsequent ABI compatible releases being x.1.1, x.1.2,
etc.
https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: Migration to Debian Bookworm and compiler updates for KernelCI
@ 2024-03-07 17:05 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-07 17:05 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: kernelci, Nick Desaulniers, clang-built-linux
Hi Denys,
On Thu, Mar 07, 2024 at 01:02:26PM +0200, Denys Fedoryshchenko wrote:
> Hello,
>
> I'm reaching out on behalf of the KernelCI project team to discuss our
> current compiler setup and planned migration to Debian Bookworm.
>
> As you may know, our compiler images are currently based on Debian
> Bullseye, which is approaching its end of life in July 2024. We have
> been testing using gcc-10, which has presented us with some recent
> challenges, notably a significant bug that results in false positive
> compilation errors (specifically, the -Werror memcpy issue in
> security.c). This situation has prompted us to consider an urgent
> migration to Debian Bookworm. Additionally, the migration is
> necessitated by our requirement to upgrade to a newer Python version to
> support KernelCI v2 development efforts.
>
> However, before we proceed, we have a couple of pending questions that
> we hope to get clarity on:
>
> 1) We've noticed that the minimal available version of clang on
> https://apt.llvm.org/bookworm/dists/ is 15, whereas our current minimal
> requirement for the Linux kernel compilation is clang-13.0.1
> (https://www.kernel.org/doc/html/next/process/changes.html). How
> critical is it to continue providing compile tests for clang-13 (and
> potentially clang-14)? This information would be vital for us in
> planning our compiler support strategy moving forward.
Coverage of the minimum version of a particular toolchain for building
the kernel is important but I would not describe it as critical.
While apt.llvm.org's Bookworm distribution does not have clang-13 and
clang-14, the Bullseye distribution of clang-13 and clang-14 does work
on Bookworm, I personally do that for my Debian development containers:
https://github.com/nathanchance/env/blob/12927502f12ec63f50a460f842c9d0a70a82c629/podman/dev/debian/setup-env.sh#L54-L64
Have you explored using the kernel.org GCC and LLVM toolchains instead
of the ones in Debian?
https://mirrors.edge.kernel.org/pub/tools/crosstool/
https://mirrors.edge.kernel.org/pub/tools/llvm/
That would potentially give you more flexibility with distribution
upgrades and stable/deterministic compiler versions around that. I
maintain the LLVM ones, which are optimized at build time to be quicker
than the Debian one's, so that would save you build minutes over time.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ssb: use "break" on default case to prevent warning
@ 2024-03-13 15:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-13 15:32 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, kernel test robot, Michael Büsch,
linux-wireless, Kalle Valo, Johannes Berg, llvm
On Tue, Mar 12, 2024 at 05:13:03PM -0700, Randy Dunlap wrote:
> Having an empty default: case in a switch statement causes a warning
> (when using Clang; I don't see the warning when using gcc),
> so add a "break;" to the default case to prevent the warning:
>
> drivers/ssb/main.c:1149:2: warning: label at end of compound statement is a C2x extension [-Wc2x-extensions]
It is a hard error with earlier versions of clang as well:
drivers/ssb/main.c:1148:10: error: label at end of compound statement: expected statement
default:
^
;
1 error generated.
> Fixes: e27b02e23a70 ("ssb: drop use of non-existing CONFIG_SSB_DEBUG symbol")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202403130717.TWm17FiD-lkp@intel.com/
> Cc: Michael Büsch <m@bues.ch>
> Cc: linux-wireless@vger.kernel.org
> Cc: Kalle Valo <kvalo@kernel.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: llvm@lists.linux.dev
Thanks for the quick fix!
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/ssb/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -- a/drivers/ssb/main.c b/drivers/ssb/main.c
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -1144,6 +1144,7 @@ u32 ssb_dma_translation(struct ssb_devic
> return SSB_PCI_DMA;
> }
> default:
> + break;
> }
> return 0;
> }
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] tracing: Use strcmp() in __assign_str() WARN_ON() check
@ 2024-03-13 16:59 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-13 16:59 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
kernel test robot, llvm
On Tue, Mar 12, 2024 at 11:30:02AM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
>
> The WARN_ON() check in __assign_str() to catch where the source variable
> to the macro doesn't match the source variable to __string() gives an
> error in clang:
>
> >> include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Wstring-compare]
> 670 | __assign_str(progname, "unknown");
>
> That's because the __assign_str() macro has:
>
> WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_);
>
> Where "src" is a string literal. Clang warns when comparing a string
> literal directly as it is undefined to what the value of the literal is.
>
> Since this is still to make sure the same string that goes to __string()
> is the same as __assign_str(), for string literals do a test for that and
> then use strcmp() in those cases
>
> Note that this depends on commit 51270d573a8d ("tracing/net_sched: Fix
> tracepoints that save qdisc_dev() as a string") being applied, as this was
> what found that bug.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202402292111.KIdExylU-lkp@intel.com/
> Fixes: 433e1d88a3be ("tracing: Add warning if string in __assign_str() does not match __string()")
Is this change destined for 6.9 or 6.10? I applied it to current
trace/core (eb1533d156d3) along with 51270d573a8d but the warning is
still present. I even tried
__builtin_choose_expr(__is_constexpr((src)),
strcmp((src), __data_offsets.dst##_ptr_),
(src) != __data_offsets.dst##_ptr_));
but not even that silenced the warning. I think we will still need a
diag directive to fully silence this warning.
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> ---
> include/trace/stages/stage6_event_callback.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/stages/stage6_event_callback.h b/include/trace/stages/stage6_event_callback.h
> index a0c15f67eabe..83da83a0c14f 100644
> --- a/include/trace/stages/stage6_event_callback.h
> +++ b/include/trace/stages/stage6_event_callback.h
> @@ -35,7 +35,9 @@
> do { \
> char *__str__ = __get_str(dst); \
> int __len__ = __get_dynamic_array_len(dst) - 1; \
> - WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_); \
> + WARN_ON_ONCE(__builtin_constant_p(src) ? \
> + strcmp((src), __data_offsets.dst##_ptr_) : \
> + (src) != __data_offsets.dst##_ptr_); \
> memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
> EVENT_NULL_STR, __len__); \
> __str__[__len__] = '\0'; \
> --
> 2.43.0
>
^ 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] 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: Migration to Debian Bookworm and compiler updates for KernelCI
@ 2024-03-13 17:56 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-13 17:56 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Denys Fedoryshchenko, kernelci, Nick Desaulniers,
clang-built-linux, Miguel Ojeda
On Mon, Mar 11, 2024 at 08:10:31PM +0100, Guillaume Tucker wrote:
> Hello,
>
> On 07/03/2024 6:05 pm, Nathan Chancellor wrote:
> > Hi Denys,
> >
> > On Thu, Mar 07, 2024 at 01:02:26PM +0200, Denys Fedoryshchenko wrote:
> > > Hello,
> > >
> > > I'm reaching out on behalf of the KernelCI project team to discuss our
> > > current compiler setup and planned migration to Debian Bookworm.
> > >
> > > As you may know, our compiler images are currently based on Debian
> > > Bullseye, which is approaching its end of life in July 2024. We have
> > > been testing using gcc-10, which has presented us with some recent
> > > challenges, notably a significant bug that results in false positive
> > > compilation errors (specifically, the -Werror memcpy issue in
> > > security.c). This situation has prompted us to consider an urgent
> > > migration to Debian Bookworm. Additionally, the migration is
> > > necessitated by our requirement to upgrade to a newer Python version to
> > > support KernelCI v2 development efforts.
> > >
> > > However, before we proceed, we have a couple of pending questions that
> > > we hope to get clarity on:
> > >
> > > 1) We've noticed that the minimal available version of clang on
> > > https://apt.llvm.org/bookworm/dists/ is 15, whereas our current minimal
> > > requirement for the Linux kernel compilation is clang-13.0.1
> > > (https://www.kernel.org/doc/html/next/process/changes.html). How
> > > critical is it to continue providing compile tests for clang-13 (and
> > > potentially clang-14)? This information would be vital for us in
> > > planning our compiler support strategy moving forward.
> >
> > Coverage of the minimum version of a particular toolchain for building
> > the kernel is important but I would not describe it as critical.
> >
> > While apt.llvm.org's Bookworm distribution does not have clang-13 and
> > clang-14, the Bullseye distribution of clang-13 and clang-14 does work
> > on Bookworm, I personally do that for my Debian development containers:
> >
> > https://github.com/nathanchance/env/blob/12927502f12ec63f50a460f842c9d0a70a82c629/podman/dev/debian/setup-env.sh#L54-L64
> >
> > Have you explored using the kernel.org GCC and LLVM toolchains instead
> > of the ones in Debian?
> >
> > https://mirrors.edge.kernel.org/pub/tools/crosstool/
> > https://mirrors.edge.kernel.org/pub/tools/llvm/
> >
> > That would potentially give you more flexibility with distribution
> > upgrades and stable/deterministic compiler versions around that. I
> > maintain the LLVM ones, which are optimized at build time to be quicker
> > than the Debian one's, so that would save you build minutes over time.
>
> Ah nice, Arnd suggested a while ago that we used his GCC
> cross-compiler toolchains in KernelCI but it got stuck at a
> slightly lower priority than everything else for core developers.
> It has always been considered a nice thing to do one day, and I
Heh, story of my life :)
> guess there may be additional reasons to pick it up now with the
> need for a wider GCC version coverage and LLVM/Clang too.
>
> Out of interest, is there going to be some Rust toolchains there
> as well? Having all the reference toolchains to build the kernel
> in a single location would be great I think. Of course Rust
> support is still a moving target, so maybe it's still a bit too
> early right now - just wondering.
As Miguel mentioned, we are talking about providing a combo LLVM + Rust
tarball to help make it more accessible to more people.
> Then in addition to the tarballs, one thing that was discussed
> with Linaro in the very early days of tuxmake was to have a
> reference set of Docker image with the toolchains already
> installed - to save everyone creating their own like in Nathan's
> GitHub link. Has anyone done that already?
>
> I started looking into it while I was writing my tutorial to
> build a kernel last month but didn't find anything, so it's kind
> of going up on my TODO list now. It would greatly help unify
> kernel builds across CI systems in particular and improve
> reproducibility. The TuxBuild / tuxmake Docker images were
> forked from the KernelCI ones so that's already something that
> could be reunited at some point.
I am not aware of that. As far as I can tell, the TuxMake images are
only lightly customized for TuxMake itself, so it is possible they are
already usable by other entities (I maintain my own containers for other
reasons). They recently added images for my kernel.org LLVM builds as
well:
https://gitlab.com/Linaro/tuxmake/-/commit/dca69b3e2f007cc31ab08200ad59593b7eaa5f40
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH-next] arm: fix clang build warning in include/asm/memory.h
@ 2024-03-15 0:43 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-15 0:43 UTC (permalink / raw)
To: Yipeng Zou
Cc: linux, ndesaulniers, morbo, justinstitt, linus.walleij, ssantosh,
linux-arm-kernel
On Thu, Mar 14, 2024 at 03:54:09PM +0800, Yipeng Zou wrote:
> There is a build error has been founded with build in clang-15.0.4:
>
> ./arch/arm/include/asm/memory.h:358:12: error: result of comparison "phys addr_t’ (aka 'unsigned int’) > 4294967295 is always false [-Werror, -Wtautological-type-limit-compare]
> if (addr > (u32)~0)
> ~~~~ ^ ~~~~~~~
>
> It will be always goes fail without CONFIG_PHYS_ADDR_T_64BIT.
>
> Directly silence it by Use CONFIG_PHYS_ADDR_T_64BIT.
>
> Fixes: 981b6714dbd2 ("ARM: provide improved virt_to_idmap() functionality")
> Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ef2aa79ece5a..64ced9eb42ff 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -347,14 +347,18 @@ static inline bool arm_has_idmap_alias(void)
> return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> }
>
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define IDMAP_INVALID_ADDR ((u32)~0)
> +#endif
>
> static inline unsigned long phys_to_idmap(phys_addr_t addr)
> {
> if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
> addr += arch_phys_to_idmap_offset;
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> if (addr > (u32)~0)
> addr = IDMAP_INVALID_ADDR;
> +#endif
> }
> return addr;
> }
> --
> 2.34.1
>
Would it be better to avoid the ifdef's here and just use IS_ENABLED()?
I can't see why this would not work for avoiding that warning.
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ef2aa79ece5a..fbff07bc3b28 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -353,7 +353,7 @@ static inline unsigned long phys_to_idmap(phys_addr_t addr)
{
if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
addr += arch_phys_to_idmap_offset;
- if (addr > (u32)~0)
+ if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) && addr > (u32)~0)
addr = IDMAP_INVALID_ADDR;
}
return addr;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 99%]
* Prebuilt LLVM 18.1.1 uploaded
@ 2024-03-15 14:26 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-15 14:26 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.1 to
https://mirrors.edge.kernel.org/pub/tools/llvm/. There should be no
functional difference between 18.1.0 and 18.1.1, it is only fixing
LLVM_VERSION_SUFFIX to remove 'rc' from the version string:
https://github.com/llvm/llvm-project/commit/b92012c777e602d557124583651313a0afa33484
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH V2] kbuild: rpm-pkg: add dtb files in kernel rpm
@ 2024-03-15 19:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-15 19:00 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: masahiroy, linux-kbuild, linux-kernel, nicolas
On Mon, Mar 11, 2024 at 05:22:38PM +0100, Jose Ignacio Tornos Martinez wrote:
> Some architectures, like aarch64 ones, need a dtb file to configure the
> hardware. The default dtb file can be preloaded from u-boot, but the final
> and/or more complete dtb file needs to be able to be loaded later from
> rootfs.
>
> Add the possible dtb files to the kernel rpm and mimic Fedora shipping
> process, storing the dtb files in the module directory. These dtb files
> will be copied to /boot directory by the install scripts, but add fallback
> just in case, checking if the content in /boot directory is correct.
>
> Mark the files installed to /boot as %ghost to make sure they will be
> removed when the package is uninstalled.
>
> Tested with Fedora Rawhide (x86_64 and aarch64) with dnf and rpm tools.
> In addition, fallback was also tested after modifying the install scripts.
>
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
I can see the new files in my arm64 package using 'rpm -qf'.
> ---
> V1 -> V2:
> - Follow the suggestions from Masahiro Yamada to improve the checks and
> avoid the loop to ghost the dtb files in /boot folder.
>
> scripts/package/kernel.spec | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec
> index c256b73cca3e..e095eb1e290e 100644
> --- a/scripts/package/kernel.spec
> +++ b/scripts/package/kernel.spec
> @@ -61,6 +61,9 @@ cp $(%{make} %{makeflags} -s image_name) %{buildroot}/lib/modules/%{KERNELRELEAS
> %{make} %{makeflags} INSTALL_HDR_PATH=%{buildroot}/usr headers_install
> cp System.map %{buildroot}/lib/modules/%{KERNELRELEASE}
> cp .config %{buildroot}/lib/modules/%{KERNELRELEASE}/config
> +if %{make} %{makeflags} run-command KBUILD_RUN_COMMAND='test -d ${srctree}/arch/${SRCARCH}/boot/dts' 2>/dev/null; then
> + %{make} %{makeflags} INSTALL_DTBS_PATH=%{buildroot}/lib/modules/%{KERNELRELEASE}/dtb dtbs_install
> +fi
> 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}'
> @@ -81,6 +84,11 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA
> echo "%ghost /boot/${x}-%{KERNELRELEASE}"
> done
>
> + if [ -d "%{buildroot}/lib/modules/%{KERNELRELEASE}/dtb" ];then
> + echo "/lib/modules/%{KERNELRELEASE}/dtb"
> + find "%{buildroot}/lib/modules/%{KERNELRELEASE}/dtb" -printf "%%%ghost /boot/dtb-%{KERNELRELEASE}/%%P\n"
> + fi
> +
> echo "%exclude /lib/modules/%{KERNELRELEASE}/build"
> } > %{buildroot}/kernel.list
>
> @@ -96,6 +104,11 @@ for file in vmlinuz System.map config; do
> cp "/lib/modules/%{KERNELRELEASE}/${file}" "/boot/${file}-%{KERNELRELEASE}"
> fi
> done
> +if [ -d "/lib/modules/%{KERNELRELEASE}/dtb" ] && \
> + ! diff -rq "/lib/modules/%{KERNELRELEASE}/dtb" "/boot/dtb-%{KERNELRELEASE}" >/dev/null 2>&1; then
> + rm -rf "/boot/dtb-%{KERNELRELEASE}"
> + cp -r "/lib/modules/%{KERNELRELEASE}/dtb" "/boot/dtb-%{KERNELRELEASE}"
> +fi
> if [ ! -e "/lib/modules/%{KERNELRELEASE}/modules.dep" ]; then
> /usr/sbin/depmod %{KERNELRELEASE}
> fi
> --
> 2.44.0
>
^ permalink raw reply [relevance 99%]
* [PATCH 1/2] clk: qcom: Fix SC_CAMCC_8280XP dependencies
2024-03-18 15:18 99% [PATCH 0/2] clk: qcom: Fix two driver Kconfig dependencies Nathan Chancellor
@ 2024-03-18 15:18 99% ` Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 2/2] clk: qcom: Fix SM_GPUCC_8650 dependencies Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-18 15:18 UTC (permalink / raw)
To: sboyd, andersson
Cc: konrad.dybcio, mturquette, bryan.odonoghue, neil.armstrong,
linux-arm-msm, linux-clk, patches, Nathan Chancellor
CONFIG_SC_GCC_8280XP depends on ARM64 but it is selected by
CONFIG_SC_CAMCC_8280XP, which can be selected on ARM, resulting in a
Kconfig warning.
WARNING: unmet direct dependencies detected for SC_GCC_8280XP
Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n])
Selected by [y]:
- SC_CAMCC_8280XP [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y]
Add the same dependencies to CONFIG_SC_CAMCC_8280XP to resolve the
warning.
Fixes: ff93872a9c61 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/clk/qcom/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 8ab08e7b5b6c..b9ff32cab329 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -474,6 +474,7 @@ config SC_CAMCC_7280
config SC_CAMCC_8280XP
tristate "SC8280XP Camera Clock Controller"
+ depends on ARM64 || COMPILE_TEST
select SC_GCC_8280XP
help
Support for the camera clock controller on Qualcomm Technologies, Inc
--
2.44.0
^ permalink raw reply related [relevance 99%]
* [PATCH 0/2] clk: qcom: Fix two driver Kconfig dependencies
@ 2024-03-18 15:18 99% Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 1/2] clk: qcom: Fix SC_CAMCC_8280XP dependencies Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 2/2] clk: qcom: Fix SM_GPUCC_8650 dependencies Nathan Chancellor
0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2024-03-18 15:18 UTC (permalink / raw)
To: sboyd, andersson
Cc: konrad.dybcio, mturquette, bryan.odonoghue, neil.armstrong,
linux-arm-msm, linux-clk, patches, Nathan Chancellor
This series fixes two Kconfig warnings that I recently saw crop up in my
build tests because the dependencies for newly added drivers in 6.8 are
not correct.
This is now the fourth set of changes to avoid warnings of this nature
for the exact same reason... is there anything that can be done to
ensure this does not continue to happen? See
b6bcd1c0c27e ("clk: qcom: fix some Kconfig corner cases")
75d1d3a433f0 ("clk: qcom: Fix SM_GPUCC_8450 dependencies")
e8d66d02defd ("clk: qcom: Fix SM_CAMCC_8550 dependencies")
---
Nathan Chancellor (2):
clk: qcom: Fix SC_CAMCC_8280XP dependencies
clk: qcom: Fix SM_GPUCC_8650 dependencies
drivers/clk/qcom/Kconfig | 2 ++
1 file changed, 2 insertions(+)
---
base-commit: 3066c521be9db14964d78c6c431c97a424468ded
change-id: 20240318-fix-some-qcom-kconfig-deps-cc9be94f63ba
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply [relevance 99%]
* [PATCH 2/2] clk: qcom: Fix SM_GPUCC_8650 dependencies
2024-03-18 15:18 99% [PATCH 0/2] clk: qcom: Fix two driver Kconfig dependencies Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 1/2] clk: qcom: Fix SC_CAMCC_8280XP dependencies Nathan Chancellor
@ 2024-03-18 15:18 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-18 15:18 UTC (permalink / raw)
To: sboyd, andersson
Cc: konrad.dybcio, mturquette, bryan.odonoghue, neil.armstrong,
linux-arm-msm, linux-clk, patches, Nathan Chancellor
CONFIG_SM_GCC_8650 depends on ARM64 but it is selected by
CONFIG_SM_GPUCC_8650, which can be selected on ARM, resulting in a
Kconfig warning.
WARNING: unmet direct dependencies detected for SM_GCC_8650
Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n])
Selected by [y]:
- SM_GPUCC_8650 [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y]
Add the same dependencies to CONFIG_SM_GPUCC_8650 to resolve the
warning.
Fixes: 8676fd4f3874 ("clk: qcom: add the SM8650 GPU Clock Controller driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/clk/qcom/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index b9ff32cab329..1bb51a058872 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -1095,6 +1095,7 @@ config SM_GPUCC_8550
config SM_GPUCC_8650
tristate "SM8650 Graphics Clock Controller"
+ depends on ARM64 || COMPILE_TEST
select SM_GCC_8650
help
Support for the graphics clock controller on SM8650 devices.
--
2.44.0
^ permalink raw reply related [relevance 99%]
* Re: [PATCH-next] arm: fix clang build warning in include/asm/memory.h
@ 2024-03-19 14:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-19 14:46 UTC (permalink / raw)
To: Yipeng Zou
Cc: linux, ndesaulniers, morbo, justinstitt, linus.walleij, ssantosh,
linux-arm-kernel
On Tue, Mar 19, 2024 at 11:38:02AM +0800, Yipeng Zou wrote:
>
> 在 2024/3/19 11:16, Yipeng Zou 写道:
> >
> > 在 2024/3/15 8:43, Nathan Chancellor 写道:
> > > On Thu, Mar 14, 2024 at 03:54:09PM +0800, Yipeng Zou wrote:
> > > > There is a build error has been founded with build in clang-15.0.4:
> > > >
> > > > ./arch/arm/include/asm/memory.h:358:12: error: result of
> > > > comparison "phys addr_t’ (aka 'unsigned int’) > 4294967295 is
> > > > always false [-Werror, -Wtautological-type-limit-compare]
> > > > if (addr > (u32)~0)
> > > > ~~~~ ^ ~~~~~~~
> > > >
> > > > It will be always goes fail without CONFIG_PHYS_ADDR_T_64BIT.
> > > >
> > > > Directly silence it by Use CONFIG_PHYS_ADDR_T_64BIT.
> > > >
> > > > Fixes: 981b6714dbd2 ("ARM: provide improved virt_to_idmap()
> > > > functionality")
> > > > Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
> > > > ---
> > > > arch/arm/include/asm/memory.h | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/arch/arm/include/asm/memory.h
> > > > b/arch/arm/include/asm/memory.h
> > > > index ef2aa79ece5a..64ced9eb42ff 100644
> > > > --- a/arch/arm/include/asm/memory.h
> > > > +++ b/arch/arm/include/asm/memory.h
> > > > @@ -347,14 +347,18 @@ static inline bool arm_has_idmap_alias(void)
> > > > return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> > > > }
> > > > +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> > > > #define IDMAP_INVALID_ADDR ((u32)~0)
> > > > +#endif
> > > > static inline unsigned long phys_to_idmap(phys_addr_t addr)
> > > > {
> > > > if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
> > > > addr += arch_phys_to_idmap_offset;
> > > > +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> > > > if (addr > (u32)~0)
> > > > addr = IDMAP_INVALID_ADDR;
> > > > +#endif
> > > > }
> > > > return addr;
> > > > }
> > > > --
> > > > 2.34.1
> > > >
> > > Would it be better to avoid the ifdef's here and just use IS_ENABLED()?
> > > I can't see why this would not work for avoiding that warning.
> > >
> > > diff --git a/arch/arm/include/asm/memory.h
> > > b/arch/arm/include/asm/memory.h
> > > index ef2aa79ece5a..fbff07bc3b28 100644
> > > --- a/arch/arm/include/asm/memory.h
> > > +++ b/arch/arm/include/asm/memory.h
> > > @@ -353,7 +353,7 @@ static inline unsigned long
> > > phys_to_idmap(phys_addr_t addr)
> > > {
> > > if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
> > > addr += arch_phys_to_idmap_offset;
> > > - if (addr > (u32)~0)
> > > + if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) && addr > (u32)~0)
> > > addr = IDMAP_INVALID_ADDR;
> > > }
> > > return addr;
> >
> > It absolutely works for it and yes, It's a better way to avoiding that.
> >
> > Will fix it in that way.
> >
> But I notice that, this way can not silence it when compile, it only can
> avoid it in running time.
Yeah, I actually tested my suggestion and saw the same thing. Sometimes
diagnostics will be hidden by '0 &&' but it seems like that is not the
case here. It is not the end of the world, I think that diff looks fine
for the issue at hand.
> So, maybe we still need to silence it in ifdef's.
>
> Other than that, IDMAP_INVALID_ADDR was used in other place, need to keep it
> defined.
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 158ad13e9f6a..7143147cd7cc 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -351,8 +351,10 @@ static inline unsigned long phys_to_idmap(phys_addr_t
> addr)
> {
> if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
> addr += arch_phys_to_idmap_offset;
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> if (addr > (u32)~0)
> addr = IDMAP_INVALID_ADDR;
> +#endif
> }
> return addr;
> }
>
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> --
> Regards,
> Yipeng Zou
>
_______________________________________________
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: [GIT PULL v2] tracing: Updates for v6.9
@ 2024-03-19 21:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-19 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Alison Schofield, Beau Belgrave, Huang Yiwei, John Garry,
Randy Dunlap, Thorsten Blum, Vincent Donnefort, linke li, llvm
On Tue, Mar 19, 2024 at 02:22:27PM -0700, Linus Torvalds wrote:
> On Tue, 19 Mar 2024 at 14:03, Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > For what it's worth, I applied that change and built ARCH=x86_64
> > defconfig with LLVM 18.1.1 from [1] but it does not appear to help the
> > instances of -Wstring-compare; in fact, it adds some additional warnings
> > that I have not seen before. I have attached the full build log.
>
> Hmm. I'm no longer seeing any problems with commit 24f5bb9f24ad
> ("tracing: Just use strcmp() for testing __string() and __assign_str()
> match").
>
> But that's clang 17.0.6.
>
> The patch that Steven sent out (and that I applied) is a bit different
> from his "I'll change it to this" email, though. A couple of casts and
> parentheses different.
>
> So maybe current -git works for you?
Ah, I did not notice your tree was updated, I was working off of
b3603fcb79b1. Works for me here, thanks for letting me know.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/2] tracing: Fully silence instance of -Wstring-compare
@ 2024-03-19 22:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-19 22:27 UTC (permalink / raw)
To: Steven Rostedt
Cc: mhiramat, mathieu.desnoyers, ndesaulniers, morbo, justinstitt,
linux-kernel, linux-trace-kernel, llvm, patches,
Linux Kernel Functional Testing
On Tue, Mar 19, 2024 at 06:15:09PM -0400, Steven Rostedt wrote:
> On Tue, 19 Mar 2024 09:07:51 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
>
> > Hi all,
> >
> > This series fully resolves the new instance of -Wstring-compare from
> > within the __assign_str() macro. The first patch resolves a build
> > failure with GCC that would be seen with just the second patch applied.
> > The second patch actually hides the warning.
> >
> > NOTE: This is based on trace/for-next, which does not contain the
> > minimum LLVM version bump that occurred later in the current merge
> > window, so this uses
> >
> > __diag_ignore(clang, 11, ...
> >
> > instead of
> >
> > __diag_ignore(clang, 13, ...
> >
> > which will be required when this is merged into Linus's tree. If you can
> > base this series on a tree that has the merge commit e5eb28f6d1af ("Merge
> > tag 'mm-nonmm-stable-2024-03-14-09-36' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") in it, then that
> > change can be done at application time, rather than merge time (or I can
> > send a v2). It would be really nice for this to make the merge window so
> > that this warning does not proliferate into other trees that base on
> > -rc1.
> >
>
> I'm guessing this isn't needed with the last update.
Correct, this is resolved in Linus's tree and should be in -next
tomorrow. The first patch may be worth sending standalone, I'll think
about sending it later but that can go in via some other tree, not
yours.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.2 uploaded
@ 2024-03-20 15:50 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-20 15:50 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.2 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* New meeting link
@ 2024-03-20 22:11 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-20 22:11 UTC (permalink / raw)
To: llvm; +Cc: keescook
Hi all,
Starting with the April 3rd ClangBuiltLinux meeting, there is a new
meeting link [1]. The old link [2] will no longer work. The
ClangBuiltLinux project page [2] will be updated shortly [4]. I believe
Kees added every one that was on the original invite but it should be
easier for people outside of Google to join now and it can be added to
your own calendar through the calendar link on the project page.
[1]: https://meet.google.com/wrr-mxkn-hdo
[2]: https://meet.google.com/yjf-jyqk-iaz
[3]: https://ClangBuiltLinux.github.io
[4]: https://github.com/ClangBuiltLinux/ClangBuiltLinux.github.io/pull/68
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
@ 2024-03-21 13:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-21 13:48 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Andrew Morton, Arnd Bergmann, linux-kernel, llvm
On Thu, Mar 21, 2024 at 02:02:19PM +0100, Greg KH wrote:
> All of these have been in linux-next for a long time with no reported
> issue, other than a build warning with some older versions of gcc for a
> speakup driver, fix for that will come in a few days when I catch up
> with my pending patch queues.
...
> Samuel Thibault (2):
> speakup: Fix 8bit characters from direct synth
> speakup: Add /dev/synthu device
That build warning actually happens with clang, not GCC as far as I am
aware, and it is actually a hard build error with older versions of
clang, as Arnd points out in his patch to fix this (although the warning
is a hard error with CONFIG_WERROR too, which causes allmodconfig to
break):
https://lore.kernel.org/20240313100413.875280-1-arnd@kernel.org/
Samuel's patch was even simpler:
https://lore.kernel.org/20240309203549.jj2l6epnznyjsrje@begin/
Why was one of these changes not applied before this was sent? I am
aware you were on vacation recently but you are now adding a known issue
to -rc1, which can proliferate to other maintainer's trees and makes
testing for us more difficult :/ -next has been broken for the entire
merge window over this, which is usually when there is a chance we can
get maybe a week of green builds...
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] scripts/package: buildtar: Output as vmlinuz for riscv
@ 2024-03-21 15:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-21 15:43 UTC (permalink / raw)
To: Matt Coster
Cc: linux-kbuild, Karolis Mituzas, Masahiro Yamada, Nicolas Schier,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Carlos de Paula,
linux-riscv
On Thu, Mar 21, 2024 at 11:58:51AM +0000, Matt Coster wrote:
> From: Karolis Mituzas <karolis.mituzas@imgtec.com>
>
> This matches the behavior for arm64 [1] and prevents clobbering of
> vmlinux-${KERNELRELEASE}.
>
> [1]: commit 0df57d90bfd6 ("kbuild: buildtar: add arm64 support")
>
> Fixes: 7d0bc44bd0ea ("kbuild: buildtar: add riscv support")
> Signed-off-by: Karolis Mituzas <karolis.mituzas@imgtec.com>
> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
> ---
> scripts/package/buildtar | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index 72c91a1b832f..a36aca2a27cc 100755
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -96,7 +96,7 @@ case "${ARCH}" in
> riscv)
> for i in Image.bz2 Image.gz Image; do
This patch seems fine but it does introduce a slight inconsistency with
the rest of this script, as vmlinuz implies a compressed boot image but
Image is not compressed. Probably does not really matter but I feel like
it is worth mentioning.
> if [ -f "${objtree}/arch/riscv/boot/${i}" ] ; then
> - cp -v -- "${objtree}/arch/riscv/boot/${i}" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
> + cp -v -- "${objtree}/arch/riscv/boot/${i}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> break
> fi
> done
> --
> 2.44.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] scripts/package: buildtar: Output as vmlinuz for riscv
@ 2024-03-21 15:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-21 15:43 UTC (permalink / raw)
To: Matt Coster
Cc: linux-kbuild, Karolis Mituzas, Masahiro Yamada, Nicolas Schier,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Carlos de Paula,
linux-riscv
On Thu, Mar 21, 2024 at 11:58:51AM +0000, Matt Coster wrote:
> From: Karolis Mituzas <karolis.mituzas@imgtec.com>
>
> This matches the behavior for arm64 [1] and prevents clobbering of
> vmlinux-${KERNELRELEASE}.
>
> [1]: commit 0df57d90bfd6 ("kbuild: buildtar: add arm64 support")
>
> Fixes: 7d0bc44bd0ea ("kbuild: buildtar: add riscv support")
> Signed-off-by: Karolis Mituzas <karolis.mituzas@imgtec.com>
> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
> ---
> scripts/package/buildtar | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index 72c91a1b832f..a36aca2a27cc 100755
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -96,7 +96,7 @@ case "${ARCH}" in
> riscv)
> for i in Image.bz2 Image.gz Image; do
This patch seems fine but it does introduce a slight inconsistency with
the rest of this script, as vmlinuz implies a compressed boot image but
Image is not compressed. Probably does not really matter but I feel like
it is worth mentioning.
> if [ -f "${objtree}/arch/riscv/boot/${i}" ] ; then
> - cp -v -- "${objtree}/arch/riscv/boot/${i}" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
> + cp -v -- "${objtree}/arch/riscv/boot/${i}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> break
> fi
> done
> --
> 2.44.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [relevance 99%]
* [PATCH] lkdtm/bugs: Improve warning message for compilers without counted_by support
@ 2024-03-21 20:18 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-21 20:18 UTC (permalink / raw)
To: keescook; +Cc: gustavoars, linux-hardening, patches, Nathan Chancellor
The current message for telling the user that their compiler does not
support the counted_by attribute in the FAM_BOUNDS test does not make
much sense either grammatically or semantically. Fix it to make it
correct in both aspects.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/misc/lkdtm/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index b92767d6bdd2..5178c02b21eb 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -417,7 +417,7 @@ static void lkdtm_FAM_BOUNDS(void)
pr_err("FAIL: survived access of invalid flexible array member index!\n");
if (!__has_attribute(__counted_by__))
- pr_warn("This is expected since this %s was built a compiler supporting __counted_by\n",
+ pr_warn("This is expected since this %s was built with a compiler that does not support __counted_by\n",
lkdtm_kernel_info);
else if (IS_ENABLED(CONFIG_UBSAN_BOUNDS))
pr_expected_config(CONFIG_UBSAN_TRAP);
---
base-commit: 8d8b79685237b15f4bb676781f6bf241beb068a8
change-id: 20240321-lkdtm-improve-lack-of-counted_by-msg-d3b9006bd6e3
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related [relevance 99%]
* Re: [PATCH] ARM: vfp: use asm volatile for FP control register accesses
@ 2024-03-26 23:55 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-03-26 23:55 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux, arnd, linus.walleij, Ard Biesheuvel, stable
On Mon, Mar 18, 2024 at 10:30:05AM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Clang may reorder FP control register reads and writes, due to the fact
> that the inline asm() blocks in the read/write wrappers are not volatile
> qualified, and the compiler has no idea that these reads and writes may
> have side effects.
>
> In particular, reads of FPSCR may generate an UNDEF exception if a
> floating point exception is pending, and the FP emulation code in
> VFP_bounce() explicitly clears FP exceptions temporarily in order to be
> able to perform the emulation on behalf of user space. This requires
> that the writes to FPEXC are never reordered with respect to accesses to
> other FP control registers, such as FPSCR.
>
> So use asm volatile for both the read and the write helpers.
>
> Cc: <stable@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This seems reasonable to me based on my understanding of GCC's
documentation. However, their documentation states "the compiler can
move even volatile asm instructions relative to other code, including
across jump instructions" and I feel like there was some discussion
around this sentence in the past but I can't remember what the
conclusion was, although I want to say Clang did not have the same
behavior. Regardless:
Acked-by: Nathan Chancellor <nathan@kernel.org>
I am just curious, how was this discovered or noticed? Was there a
report I missed?
> ---
> arch/arm/vfp/vfpinstr.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> index 3c7938fd40aa..c4ac778e6fc9 100644
> --- a/arch/arm/vfp/vfpinstr.h
> +++ b/arch/arm/vfp/vfpinstr.h
> @@ -66,14 +66,14 @@
>
> #define fmrx(_vfp_) ({ \
> u32 __v; \
> - asm(".fpu vfpv2\n" \
> + asm volatile(".fpu vfpv2\n" \
> "vmrs %0, " #_vfp_ \
> : "=r" (__v) : : "cc"); \
> __v; \
> })
>
> #define fmxr(_vfp_,_var_) \
> - asm(".fpu vfpv2\n" \
> + asm volatile(".fpu vfpv2\n" \
> "vmsr " #_vfp_ ", %0" \
> : : "r" (_var_) : "cc")
>
> --
> 2.39.2
>
_______________________________________________
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: [PATCH v2] arm: fix clang build warning in include/asm/memory.h
@ 2024-03-26 23:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-26 23:55 UTC (permalink / raw)
To: Yipeng Zou
Cc: linux, ndesaulniers, morbo, justinstitt, linus.walleij, ssantosh,
linux-arm-kernel
On Thu, Mar 21, 2024 at 09:35:29AM +0800, Yipeng Zou wrote:
> There is a build error has been founded with build in clang-15.0.4:
>
> ./arch/arm/include/asm/memory.h:358:12: error: result of comparison "phys addr_t’ (aka 'unsigned int’) > 4294967295 is always false [-Werror, -Wtautological-type-limit-compare]
> if (addr > (u32)~0)
> ~~~~ ^ ~~~~~~~
>
> It will be always goes fail without CONFIG_PHYS_ADDR_T_64BIT.
>
> Directly silence it by Use CONFIG_PHYS_ADDR_T_64BIT.
>
> Fixes: 981b6714dbd2 ("ARM: provide improved virt_to_idmap() functionality")
> Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> V2: IDMAP_INVALID_ADDR was used in other place, keep it defined.
> arch/arm/include/asm/memory.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ef2aa79ece5a..07c7e759d04c 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -353,8 +353,10 @@ static inline unsigned long phys_to_idmap(phys_addr_t addr)
> {
> if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
> addr += arch_phys_to_idmap_offset;
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> if (addr > (u32)~0)
> addr = IDMAP_INVALID_ADDR;
> +#endif
> }
> return addr;
> }
> --
> 2.34.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: [PATCH] ARM: vfp: use asm volatile for FP control register accesses
@ 2024-03-27 14:41 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-27 14:41 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-arm-kernel, linux, arnd, linus.walleij, stable
On Wed, Mar 27, 2024 at 09:05:17AM +0200, Ard Biesheuvel wrote:
> On Wed, 27 Mar 2024 at 01:55, Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Mon, Mar 18, 2024 at 10:30:05AM +0100, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb@kernel.org>
> > >
> > > Clang may reorder FP control register reads and writes, due to the fact
> > > that the inline asm() blocks in the read/write wrappers are not volatile
> > > qualified, and the compiler has no idea that these reads and writes may
> > > have side effects.
> > >
> > > In particular, reads of FPSCR may generate an UNDEF exception if a
> > > floating point exception is pending, and the FP emulation code in
> > > VFP_bounce() explicitly clears FP exceptions temporarily in order to be
> > > able to perform the emulation on behalf of user space. This requires
> > > that the writes to FPEXC are never reordered with respect to accesses to
> > > other FP control registers, such as FPSCR.
> > >
> > > So use asm volatile for both the read and the write helpers.
> > >
> > > Cc: <stable@kernel.org>
> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >
> > This seems reasonable to me based on my understanding of GCC's
> > documentation. However, their documentation states "the compiler can
> > move even volatile asm instructions relative to other code, including
> > across jump instructions" and I feel like there was some discussion
> > around this sentence in the past but I can't remember what the
> > conclusion was, although I want to say Clang did not have the same
> > behavior.
>
> The only thing that matters here is whether two asm blocks are emitted
> in a different order than they appear in the program, and I would be
> very surprised if volatile permits that. Otherwise, we might introduce
> a fake input dependency or a memory clobber instead.
Yeah, I think it is reasonable to go with this approach and fall back to
your follow up suggestion if this proves not to be robust enough.
> > Regardless:
> >
> > Acked-by: Nathan Chancellor <nathan@kernel.org>
> >
>
> Thanks.
>
> > I am just curious, how was this discovered or noticed? Was there a
> > report I missed?
> >
>
> I noticed this when building a recent kernel for the original
> Raspberry Pi, which is ARMv6 not ARMv7, and has a VFP which partially
> relies on emulation. On more recent cores, we never hit the issue
> because emulation is never needed. On older cores, there is no VFP so
> we never reach this code path either.
Ah, good to know. I boot test -next on a Pi 3 with a 32-bit kernel, so
that explains why I have not seen any issues. Just wanted to make sure I
did not miss something :)
Cheers,
Nathan
_______________________________________________
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: [akpm-mm:mm-nonmm-unstable 53/62] lib/raid6/recov_neon_inner.c:7:10: fatal error: 'arm_neon.h' file not found
@ 2024-03-29 15:20 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-29 15:20 UTC (permalink / raw)
To: kernel test robot
Cc: Samuel Holland, llvm, oe-kbuild-all, Andrew Morton,
Linux Memory Management List, Christoph Hellwig
On Fri, Mar 29, 2024 at 12:27:57PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> head: b065e14a3960a495216a032e6d383c104147c9ef
> commit: aa73a95380b4ef76ccf00344b777d0d415026b7b [53/62] lib/raid6: use CC_FLAGS_FPU for NEON CFLAGS
> config: arm-randconfig-002-20240329 (https://download.01.org/0day-ci/archive/20240329/202403291210.ioK7bfPA-lkp@intel.com/config)
> compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 79ba323bdd0843275019e16b6e9b35133677c514)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240329/202403291210.ioK7bfPA-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202403291210.ioK7bfPA-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> >> lib/raid6/recov_neon_inner.c:7:10: fatal error: 'arm_neon.h' file not found
> 7 | #include <arm_neon.h>
> | ^~~~~~~~~~~~
> 1 error generated.
Looks like the CFLAGS for recov_neon_inner.o got lost. This resolves it
for me.
Cheers,
Nathan
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index c71984e04c4d..0e88bfe6445b 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -60,10 +60,12 @@ CFLAGS_neon1.o += $(CC_FLAGS_FPU)
CFLAGS_neon2.o += $(CC_FLAGS_FPU)
CFLAGS_neon4.o += $(CC_FLAGS_FPU)
CFLAGS_neon8.o += $(CC_FLAGS_FPU)
+CFLAGS_recov_neon_inner.o += $(CC_FLAGS_FPU)
CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
+CFLAGS_REMOVE_recov_neon_inner.o += $(CC_FLAGS_NO_FPU)
targets += neon1.c neon2.c neon4.c neon8.c
$(obj)/neon%.c: $(src)/neon.uc $(src)/unroll.awk FORCE
$(call if_changed,unroll)
^ permalink raw reply related [relevance 99%]
* Re: [PATCH 05/12] firmware: dmi-id: add a release callback function
@ 2024-03-29 16:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-03-29 16:12 UTC (permalink / raw)
To: Jean Delvare
Cc: Arnd Bergmann, linux-kbuild, Masahiro Yamada, Greg Kroah-Hartman,
Nicolas Schier, Arnd Bergmann, Nick Desaulniers, Bill Wendling,
Justin Stitt, linux-kernel, llvm
On Fri, Mar 29, 2024 at 01:49:17PM +0100, Jean Delvare wrote:
> Hi Arnd,
>
> On Tue, 26 Mar 2024 15:51:30 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > dmi_class uses kfree() as the .release function, but that now causes
> > a warning with clang-16 as it violates control flow integrity (KCFI)
> > rules:
> >
> > drivers/firmware/dmi-id.c:174:17: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
> > 174 | .dev_release = (void(*)(struct device *)) kfree,
> >
> > Add an explicit function to call kfree() instead.
> >
> > Fixes: 4f5c791a850e ("DMI-based module autoloading")
>
> Not sure if this fixes tag is really warranted. As I understand it,
> your change only removes a warning but there was no actual bug, right?
Sort of, the warning is really pointing out that calling this callback
will result in a crash at runtime when the kernel is built with kCFI
enabled, which I would consider a bug.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.3
@ 2024-04-04 18:46 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-04 18:46 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.3 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] powerpc: Fix fatal warnings flag for LLVM's integrated assembler
@ 2024-04-05 19:31 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-05 19:31 UTC (permalink / raw)
To: mpe
Cc: justinstitt, ajd, llvm, patches, Nathan Chancellor, morbo, bgray,
linuxppc-dev
When building with LLVM_IAS=1, there is an error because
'-fatal-warnings' is not recognized as a valid flag:
clang: error: unsupported argument '-fatal-warnings' to option '-Wa,'
Use the double hyphen version of the flag, '--fatal-warnings', which
works with both the GNU assembler and LLVM's integrated assembler.
Fixes: 608d4a5ca563 ("powerpc: Error on assembly warnings")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/powerpc/Kbuild | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kbuild b/arch/powerpc/Kbuild
index da862e9558bc..571f260b0842 100644
--- a/arch/powerpc/Kbuild
+++ b/arch/powerpc/Kbuild
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror -Wa,-fatal-warnings
-subdir-asflags-$(CONFIG_PPC_WERROR) := -Wa,-fatal-warnings
+subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror -Wa,--fatal-warnings
+subdir-asflags-$(CONFIG_PPC_WERROR) := -Wa,--fatal-warnings
obj-y += kernel/
obj-y += mm/
---
base-commit: bfe51886ca544956eb4ff924d1937ac01d0ca9c8
change-id: 20240405-ppc-fix-wa-fatal-warnings-clang-603f0ebb0133
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply related [relevance 99%]
* Re: [PATCH] [RFC] xfrm: work around a clang-19 fortifiy-string false-positive
@ 2024-04-09 16:15 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-09 16:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kees Cook, Arnd Bergmann, Steffen Klassert, Herbert Xu,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Nick Desaulniers, Bill Wendling, Justin Stitt,
Gustavo A. R. Silva, Leon Romanovsky, Lin Ma, Simon Horman,
Breno Leitao, Tobias Brunner, Raed Salem, Netdev, linux-kernel,
llvm
On Mon, Apr 08, 2024 at 09:06:21AM +0200, Arnd Bergmann wrote:
> On Fri, Feb 16, 2024, at 22:19, Kees Cook wrote:
> > On Fri, Feb 16, 2024 at 09:26:40PM +0100, Arnd Bergmann wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> clang-19 recently got branched from clang-18 and is not yet released.
> >> The current version introduces exactly one new warning that I came
> >> across in randconfig testing, in the copy_to_user_tmpl() function:
> >>
> >> include/linux/fortify-string.h:420: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]
> >> 420 | __write_overflow_field(p_size_field, size);
> >>
> >> I have not yet produced a minimized test case for it, but I have a
> >> local workaround, which avoids the memset() here by replacing it with
> >> an initializer.
> >>
> >> The memset is required to avoid leaking stack data to user space
> >> and was added in commit 1f86840f8977 ("xfrm_user: fix info leak in
> >> copy_to_user_tmpl()"). Simply changing the initializer to set all fields
> >> still risks leaking data in the padding between them, which the compiler
> >> is free to do here. To work around that problem, explicit padding fields
> >> have to get added as well.
> >
> > Per C11, padding bits are zero initialized if there is an initializer,
> > so "= { }" here should be sufficient -- no need to add the struct
> > members.
> >
> >> Since this is a false positive, a better fix would likely be to
> >> fix the compiler.
> >
> > As Nathan has found, this appears to be a loop unrolling bug in Clang.
> > https://github.com/ClangBuiltLinux/linux/issues/1985
> >
> > The shorter fix (in the issue) is to explicitly range-check before
> > the loop:
> >
> > if (xp->xfrm_nr > XFRM_MAX_DEPTH)
> > return -ENOBUFS;
>
> I ran into this issue again and I see that Nathan's fix has
> made it into mainline and backports, but it's apparently
> not sufficient.
>
> I don't see the warning with my patch from this thread, but
> there may still be a better fix.
Is it the exact same warning? clang-19 or older? What
architecture/configuration? If my change is not sufficient then maybe
there are two separate issues here? I have not seen this warning appear
in our CI since my change was applied.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ARM: Add a memory clobber to the fmrx instruction
@ 2024-04-09 16:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-09 16:46 UTC (permalink / raw)
To: zhuqiuer
Cc: linux, ndesaulniers, morbo, justinstitt, linux-arm-kernel,
linux-kernel, ardb, llvm
+ Ard
On Tue, Apr 09, 2024 at 07:38:44PM +0800, zhuqiuer wrote:
> The instruction fmrx is used throughout the kernel,
> where it is sometimes expected to be skipped
> by incrementing the program counter, such as in vfpmodule.c:vfp_init().
> Therefore, the instruction should not be reordered when it is not intended.
> Adding a barrier() instruction before and after this call cannot prevent
> reordering by the compiler, as the fmrx instruction is constrained
> by '=r', meaning it works on the general register but not on memory.
> To ensure the order of the instruction after compiling,
> adding a memory clobber is necessary.
>
> Below is the code snippet disassembled from the method:
> vfpmodule.c:vfp_init(), compiled by LLVM.
>
> Before the patching:
> xxxxx: xxxxx bl c010c688 <register_undef_hook>
> xxxxx: xxxxx mov r0, r4
> xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> ...
> xxxxx: xxxxx bl c0791c8c <printk>
> xxxxx: xxxxx movw r5, #23132 ; 0x5a5c
> xxxxx: xxxxx vmrs r4, fpsid <- this is the fmrx instruction
>
> After the patching:
> xxxxx: xxxxx bl c010c688 <register_undef_hook>
> xxxxx: xxxxx mov r0, r4
> xxxxx: xxxxx vmrs r5, fpsid <- this is the fmrx instruction
> xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
>
> Signed-off-by: zhuqiuer <zhuqiuer1@huawei.com>
> ---
> arch/arm/vfp/vfpinstr.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> index 3c7938fd40aa..e70129e10b8e 100644
> --- a/arch/arm/vfp/vfpinstr.h
> +++ b/arch/arm/vfp/vfpinstr.h
> @@ -68,7 +68,7 @@
> u32 __v; \
> asm(".fpu vfpv2\n" \
> "vmrs %0, " #_vfp_ \
> - : "=r" (__v) : : "cc"); \
> + : "=r" (__v) : : "memory", "cc"); \
> __v; \
> })
>
> --
> 2.12.3
>
This seems like the same issue that Ard was addressing with this patch
at https://lore.kernel.org/20240318093004.117153-2-ardb+git@google.com/,
does that change work for your situation as well? I do not really have a
strong preference between the two approaches, Ard also mentioned using
*current in the asm constraints as another option.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ARM: Add a memory clobber to the fmrx instruction
@ 2024-04-09 16:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-09 16:46 UTC (permalink / raw)
To: zhuqiuer
Cc: linux, ndesaulniers, morbo, justinstitt, linux-arm-kernel,
linux-kernel, ardb, llvm
+ Ard
On Tue, Apr 09, 2024 at 07:38:44PM +0800, zhuqiuer wrote:
> The instruction fmrx is used throughout the kernel,
> where it is sometimes expected to be skipped
> by incrementing the program counter, such as in vfpmodule.c:vfp_init().
> Therefore, the instruction should not be reordered when it is not intended.
> Adding a barrier() instruction before and after this call cannot prevent
> reordering by the compiler, as the fmrx instruction is constrained
> by '=r', meaning it works on the general register but not on memory.
> To ensure the order of the instruction after compiling,
> adding a memory clobber is necessary.
>
> Below is the code snippet disassembled from the method:
> vfpmodule.c:vfp_init(), compiled by LLVM.
>
> Before the patching:
> xxxxx: xxxxx bl c010c688 <register_undef_hook>
> xxxxx: xxxxx mov r0, r4
> xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> ...
> xxxxx: xxxxx bl c0791c8c <printk>
> xxxxx: xxxxx movw r5, #23132 ; 0x5a5c
> xxxxx: xxxxx vmrs r4, fpsid <- this is the fmrx instruction
>
> After the patching:
> xxxxx: xxxxx bl c010c688 <register_undef_hook>
> xxxxx: xxxxx mov r0, r4
> xxxxx: xxxxx vmrs r5, fpsid <- this is the fmrx instruction
> xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
>
> Signed-off-by: zhuqiuer <zhuqiuer1@huawei.com>
> ---
> arch/arm/vfp/vfpinstr.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> index 3c7938fd40aa..e70129e10b8e 100644
> --- a/arch/arm/vfp/vfpinstr.h
> +++ b/arch/arm/vfp/vfpinstr.h
> @@ -68,7 +68,7 @@
> u32 __v; \
> asm(".fpu vfpv2\n" \
> "vmrs %0, " #_vfp_ \
> - : "=r" (__v) : : "cc"); \
> + : "=r" (__v) : : "memory", "cc"); \
> __v; \
> })
>
> --
> 2.12.3
>
This seems like the same issue that Ard was addressing with this patch
at https://lore.kernel.org/20240318093004.117153-2-ardb+git@google.com/,
does that change work for your situation as well? I do not really have a
strong preference between the two approaches, Ard also mentioned using
*current in the asm constraints as another option.
Cheers,
Nathan
_______________________________________________
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: [PATCH v2] ARM: Add a memory clobber to the fmrx instruction
@ 2024-04-10 15:35 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-10 15:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: zhuqiuer, justinstitt, linux-arm-kernel, linux-kernel, linux,
llvm, morbo, ndesaulniers
On Wed, Apr 10, 2024 at 02:31:11PM +0200, Ard Biesheuvel wrote:
> On Wed, 10 Apr 2024 at 04:41, zhuqiuer <zhuqiuer1@huawei.com> wrote:
> >
> > The instruction fmrx is used throughout the kernel,
> > where it is sometimes expected to be skipped
> > by incrementing the program counter, such as in vfpmodule.c:vfp_init().
> > Therefore, the instruction should not be reordered when it is not intended.
> > Adding a barrier() instruction before and after this call cannot prevent
> > reordering by the compiler, as the fmrx instruction is constrained
> > by '=r', meaning it works on the general register but not on memory.
> > To ensure the order of the instruction after compiling,
> > adding a memory clobber is necessary.
> >
> > Below is the code snippet disassembled from the method:
> > vfpmodule.c:vfp_init(), compiled by LLVM.
> >
> > Before the patching:
> > xxxxx: xxxxx bl c010c688 <register_undef_hook>
> > xxxxx: xxxxx mov r0, r4
> > xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> > ...
> > xxxxx: xxxxx bl c0791c8c <printk>
> > xxxxx: xxxxx movw r5, #23132 ; 0x5a5c
> > xxxxx: xxxxx vmrs r4, fpsid <- this is the fmrx instruction
> >
> > After the patching:
> > xxxxx: xxxxx bl c010c688 <register_undef_hook>
> > xxxxx: xxxxx mov r0, r4
> > xxxxx: xxxxx vmrs r5, fpsid <- this is the fmrx instruction
> > xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> >
> > Signed-off-by: zhuqiuer <zhuqiuer1@huawei.com>
>
> This also fixes the issue I observed so
>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
This can probably go in Russell's patch tracker? Your patch had
Cc: stable@vger.kernel.org
in it, should this one as well?
> > ---
> > arch/arm/vfp/vfpinstr.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> > index 3c7938fd40aa..ae2c9b9b7701 100644
> > --- a/arch/arm/vfp/vfpinstr.h
> > +++ b/arch/arm/vfp/vfpinstr.h
> > @@ -68,14 +68,14 @@
> > u32 __v; \
> > asm(".fpu vfpv2\n" \
> > "vmrs %0, " #_vfp_ \
> > - : "=r" (__v) : : "cc"); \
> > + : "=r" (__v) : : "memory", "cc"); \
> > __v; \
> > })
> >
> > #define fmxr(_vfp_,_var_) \
> > asm(".fpu vfpv2\n" \
> > "vmsr " #_vfp_ ", %0" \
> > - : : "r" (_var_) : "cc")
> > + : : "r" (_var_) : "memory", "cc")
> >
> > #else
> >
> > --
> > 2.12.3
> >
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] ARM: Add a memory clobber to the fmrx instruction
@ 2024-04-10 15:35 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-10 15:35 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: zhuqiuer, justinstitt, linux-arm-kernel, linux-kernel, linux,
llvm, morbo, ndesaulniers
On Wed, Apr 10, 2024 at 02:31:11PM +0200, Ard Biesheuvel wrote:
> On Wed, 10 Apr 2024 at 04:41, zhuqiuer <zhuqiuer1@huawei.com> wrote:
> >
> > The instruction fmrx is used throughout the kernel,
> > where it is sometimes expected to be skipped
> > by incrementing the program counter, such as in vfpmodule.c:vfp_init().
> > Therefore, the instruction should not be reordered when it is not intended.
> > Adding a barrier() instruction before and after this call cannot prevent
> > reordering by the compiler, as the fmrx instruction is constrained
> > by '=r', meaning it works on the general register but not on memory.
> > To ensure the order of the instruction after compiling,
> > adding a memory clobber is necessary.
> >
> > Below is the code snippet disassembled from the method:
> > vfpmodule.c:vfp_init(), compiled by LLVM.
> >
> > Before the patching:
> > xxxxx: xxxxx bl c010c688 <register_undef_hook>
> > xxxxx: xxxxx mov r0, r4
> > xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> > ...
> > xxxxx: xxxxx bl c0791c8c <printk>
> > xxxxx: xxxxx movw r5, #23132 ; 0x5a5c
> > xxxxx: xxxxx vmrs r4, fpsid <- this is the fmrx instruction
> >
> > After the patching:
> > xxxxx: xxxxx bl c010c688 <register_undef_hook>
> > xxxxx: xxxxx mov r0, r4
> > xxxxx: xxxxx vmrs r5, fpsid <- this is the fmrx instruction
> > xxxxx: xxxxx bl c010c6e4 <unregister_undef_hook>
> >
> > Signed-off-by: zhuqiuer <zhuqiuer1@huawei.com>
>
> This also fixes the issue I observed so
>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
This can probably go in Russell's patch tracker? Your patch had
Cc: stable@vger.kernel.org
in it, should this one as well?
> > ---
> > arch/arm/vfp/vfpinstr.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/vfp/vfpinstr.h b/arch/arm/vfp/vfpinstr.h
> > index 3c7938fd40aa..ae2c9b9b7701 100644
> > --- a/arch/arm/vfp/vfpinstr.h
> > +++ b/arch/arm/vfp/vfpinstr.h
> > @@ -68,14 +68,14 @@
> > u32 __v; \
> > asm(".fpu vfpv2\n" \
> > "vmrs %0, " #_vfp_ \
> > - : "=r" (__v) : : "cc"); \
> > + : "=r" (__v) : : "memory", "cc"); \
> > __v; \
> > })
> >
> > #define fmxr(_vfp_,_var_) \
> > asm(".fpu vfpv2\n" \
> > "vmsr " #_vfp_ ", %0" \
> > - : : "r" (_var_) : "cc")
> > + : : "r" (_var_) : "memory", "cc")
> >
> > #else
> >
> > --
> > 2.12.3
> >
_______________________________________________
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: [PATCH 2/3] selftests: timers: Fix uninitialized variable warning in ksft_min_kernel_version
@ 2024-04-11 18:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-11 18:47 UTC (permalink / raw)
To: John Stultz
Cc: LKML, Shuah Khan, Anna-Maria Behnsen, Frederic Weisbecker,
Thomas Gleixner, Stephen Boyd, Nick Desaulniers, Bill Wendling,
Justin Stitt, Oleg Nesterov, Andrew Morton, Edward Liaw,
Carlos Llamas, kernel-team, linux-kselftest
On Thu, Apr 11, 2024 at 11:11:59AM -0700, John Stultz wrote:
> On Thu, Apr 11, 2024 at 8:39 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > On Wed, Apr 10, 2024 at 04:26:29PM -0700, John Stultz wrote:
> > > Building with clang, I see the following warning:
> > >
> > > In file included from posix_timers.c:17:
> > > ./../kselftest.h:398:6: warning: variable 'major' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized]
> > > if (uname(&info) || sscanf(info.release, "%u.%u.", &major, &minor) != 2)
> > > ^~~~~~~~~~~~
> > > ./../kselftest.h:401:9: note: uninitialized use occurs here
> > > return major > min_major || (major == min_major && minor >= min_minor);
> > > ^~~~~
> > >
> > > This is a bit of a red-herring as if the uname() call did fail,
> > > we would hit ksft_exit_fail_msg() which should exit.
> >
> > Correct, although we have not really conveyed that to the compiler,
> > right? exit() is noreturn, which means all functions that call exit()
> > unconditionally are also noreturn, such as ksft_exit_fail_msg(). LLVM
> > will figure this out once it performs inlining and such but that happens
> > after clang's static analysis phase that this warning occurs in. I think
> > a better solution would be to add __noreturn to the functions in
> > tools/testing/selftests/kselftest.h that call exit(), so that the
> > compiler is aware of this through all pipeline phases, maybe something
> > like this? It resolves the wawrning for me.
>
> No objection from me if this is the better approach.
>
> Would you send that patch out?
Done: https://lore.kernel.org/20240411-mark-kselftest-exit-funcs-noreturn-v1-1-b027c948f586@kernel.org/
If you have to respin this series for some reason, feel free to include
that change so that they go together, up to you though.
Cheers,
nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: buildtar: Add arm support
@ 2024-04-12 21:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-12 21:47 UTC (permalink / raw)
To: Calvin Owens; +Cc: linux-kernel, Masahiro Yamada, Nicolas Schier, linux-kbuild
On Fri, Apr 12, 2024 at 12:23:42PM -0700, Calvin Owens wrote:
> On Wednesday 04/10 at 15:56 -0700, Calvin Owens wrote:
> > On Wednesday 04/10 at 10:04 -0700, Nathan Chancellor wrote:
> > > Hi Calvin,
> > >
> > > Thanks for the patch!
> > >
> > > On Tue, Apr 09, 2024 at 10:17:07AM -0700, Calvin Owens wrote:
> > > > Make 'make tar-pkg' and friends work on 32-bit arm.
> > > >
> > > > Signed-off-by: Calvin Owens <calvin@wbinvd.org>
> > >
> > > Technically speaking, buildtar works for 32-bit ARM right now (I use it
> > > almost daily), this is just explicitly adding it to the supported list
> > > to avoid the warning and putting zImage at vmlinuz-${KERNELRELEASE}
> > > instead of vmlinux-kbuild-${KERNELRELEASE}, right?
> >
> > Exactly. I assumed (maybe incorrectly?) the vmlinux-kbuild-* name was
> > generic "unimplemented" filler that was meant to be replaced. It seems
> > like the vmlinuz-* naming has sort of become a de facto standard in the
> > tar-pkgs.
I think your first assumption is likely correct although I have not
looked back at the history to confirm that. I am not as sure on the
second statement, mainly just because not all kernel images are
compressed so they wouldn't necessarily make sense as vmlinuz. I think
it just happens that many of the most popular architectures have default
compressed kernel images.
> > The context for me is a pile of scripts that build kernels and boot them
> > with QEMU on arm and arm64: it's convenient if the tar-pkg structure is
> > consistent between the two (and across other architectures too).
Yes, I think including that reasoning in the commit message makes sense,
since it is justification for changing the status quo.
> > > That said, looks mostly fine to me, one comment below.
> > >
> > > Before:
> > >
> > > './System.map' -> 'tar-install/boot/System.map-6.9.0-rc3-00023-g2c71fdf02a95'
> > > '.config' -> 'tar-install/boot/config-6.9.0-rc3-00023-g2c71fdf02a95'
> > > './vmlinux' -> 'tar-install/boot/vmlinux-6.9.0-rc3-00023-g2c71fdf02a95'
> > > 'arch/arm/boot/zImage' -> 'tar-install/boot/vmlinux-kbuild-6.9.0-rc3-00023-g2c71fdf02a95'
> > >
> > > ** ** ** WARNING ** ** **
> > >
> > > Your architecture did not define any architecture-dependent files
> > > to be placed into the tarball. Please add those to scripts/package/buildtar ...
> > >
> > > After:
> > >
> > > './System.map' -> 'tar-install/boot/System.map-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
> > > '.config' -> 'tar-install/boot/config-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
> > > './vmlinux' -> 'tar-install/boot/vmlinux-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
> > > './arch/arm/boot/zImage' -> 'tar-install/boot/vmlinuz-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
> > >
> > > and the location of zImage is the only thing that changes as expected.
> > >
> > > > ---
> > > > scripts/package/buildtar | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> > > > index 72c91a1b832f..0939f9eabbf2 100755
> > > > --- a/scripts/package/buildtar
> > > > +++ b/scripts/package/buildtar
> > > > @@ -101,6 +101,9 @@ case "${ARCH}" in
> > > > fi
> > > > done
> > > > ;;
> > > > + arm)
> > > > + [ -f "${objtree}/arch/arm/boot/zImage" ] && cp -v -- "${objtree}/arch/arm/boot/zImage" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> > >
> > > While it probably does not matter too much, it would be more proper to
> > > make this
> > >
> > > [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> > >
> > > as the current line does not work with CONFIG_XIP_KERNEL=y, since zImage
> > > does not exist (KBUILD_IMAGE is arch/arm/boot/xipImage with this
> > > configuration)
> > >
> > > $ ls arch/arm/boot
> > > compressed dts xipImage
> > >
> > > resulting in buildtar failing because
> > >
> > > [ -f "${objtree}/arch/arm/boot/zImage" ]
> > >
> > > fails and is the last statement that runs in the script (and the tar
> > > package is not really complete in this configuration anyways).
> > >
> > > Prior to this change, the correct image would get placed into the
> > > tarball.
> > >
> > > 'arch/arm/boot/xipImage' -> 'tar-install/boot/vmlinux-kbuild-6.9.0-rc3-00023-g2c71fdf02a95'
> >
> > Makes sense, thanks. Although...
> >
> > > > + ;;
> > > > *)
> > > > [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
> > > > echo "" >&2
> >
> > ...it ends up looking almost identical to the default case. Does it make
> > make more sense to change the destination in the default case and remove
> > the warning? I'm not sure if anything might rely on the current
> > behavior, it goes all the way back (git sha 6d983feab809).
>
> What I'm trying to say is: using KBUILD_IMAGE like you suggest allows
> more of the existing cases to be combined, like the below (and probably
> alpha too, at least).
I see you already sent v2, which I will review shortly, but doing this
change certainly seems reasonable to me. We could add a comment above it
like
# Architectures with just a compressed KBUILD_IMAGE
> ---8<---
>
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index 72c91a1b832f..66b4d8d308b6 100755
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -54,8 +54,8 @@ cp -v -- "${objtree}/vmlinux" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
> # Install arch-specific kernel image(s)
> #
> case "${ARCH}" in
> - x86|i386|x86_64)
> - [ -f "${objtree}/arch/x86/boot/bzImage" ] && cp -v -- "${objtree}/arch/x86/boot/bzImage" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> + x86|i386|x86_64|arm)
> + [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> ;;
> alpha)
> [ -f "${objtree}/arch/alpha/boot/vmlinux.gz" ] && cp -v -- "${objtree}/arch/alpha/boot/vmlinux.gz" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] kbuild: buildtar: Add explicit 32-bit arm support
@ 2024-04-12 21:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-12 21:48 UTC (permalink / raw)
To: Calvin Owens; +Cc: linux-kernel, Masahiro Yamada, Nicolas Schier, linux-kbuild
On Fri, Apr 12, 2024 at 12:26:06PM -0700, Calvin Owens wrote:
> Implement buildtar for 32-bit arm, so the zImage (or xipimage) appears
> at boot/vmlinuz-$foo, rather than at boot/vmlinux-kbuild-$foo, matching
> the structure of the tar-pkg on arm64 and other architectures.
>
> Link: https://lore.kernel.org/all/e7c14a0d329e28bdcda21376b54a43c85a4aaf3f.1712682861.git.calvin@wbinvd.org/
> Signed-off-by: Calvin Owens <calvin@wbinvd.org>
Looks good to me, especially with the added justification of matching
other architectures.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> scripts/package/buildtar | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index 72c91a1b832f..86035c990aec 100755
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -101,6 +101,9 @@ case "${ARCH}" in
> fi
> done
> ;;
> + arm)
> + [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> + ;;
> *)
> [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
> echo "" >&2
> --
> 2.39.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 0/8] CFI for ARM32 using LLVM
@ 2024-04-12 22:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-12 22:07 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Sami Tolvanen, Kees Cook, Nick Desaulniers,
Ard Biesheuvel, Arnd Bergmann, linux-arm-kernel, llvm
On Fri, Apr 12, 2024 at 09:38:24AM +0200, Linus Walleij wrote:
> On Thu, Mar 28, 2024 at 9:19 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > This is a first patch set to support CLANG CFI (Control Flow
> > Integrity) on ARM32.
>
> Not much reaction to this apart from Kees' ACK and I think
> most patches are pretty straight-forward so I'll soon put them
> in Russell's tracker, I can always update them if there is some
> issue.
I've given the patches a quick glance and I do not see anything
obviously wrong so consider this a soft LGTM. Given that it is an option
and I am sure there are arm64 and x86_64 configurations that are not
clean, I don't think having all CFI issues patched before the support
lands is necessary or desirable.
> As mentioned, there will be some rough edges (e.g. eBPF)
> but a slew of machines boot fine with it and it should be able
> to provide additional hardening on a slew of embedded use
> cases.
Agreed.
I will try to file an issue for the EFI issue I noticed before so that
it can be investigated and fixed at some point.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 0/8] CFI for ARM32 using LLVM
@ 2024-04-12 22:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-12 22:07 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Sami Tolvanen, Kees Cook, Nick Desaulniers,
Ard Biesheuvel, Arnd Bergmann, linux-arm-kernel, llvm
On Fri, Apr 12, 2024 at 09:38:24AM +0200, Linus Walleij wrote:
> On Thu, Mar 28, 2024 at 9:19 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> > This is a first patch set to support CLANG CFI (Control Flow
> > Integrity) on ARM32.
>
> Not much reaction to this apart from Kees' ACK and I think
> most patches are pretty straight-forward so I'll soon put them
> in Russell's tracker, I can always update them if there is some
> issue.
I've given the patches a quick glance and I do not see anything
obviously wrong so consider this a soft LGTM. Given that it is an option
and I am sure there are arm64 and x86_64 configurations that are not
clean, I don't think having all CFI issues patched before the support
lands is necessary or desirable.
> As mentioned, there will be some rough edges (e.g. eBPF)
> but a slew of machines boot fine with it and it should be able
> to provide additional hardening on a slew of embedded use
> cases.
Agreed.
I will try to file an issue for the EFI issue I noticed before so that
it can be investigated and fixed at some point.
Cheers,
Nathan
_______________________________________________
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: [PATCH] selftests: Mark ksft_exit_fail_perror() as __noreturn
@ 2024-04-15 15:41 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-15 15:41 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Shuah Khan, Nick Desaulniers, Bill Wendling, Justin Stitt,
kernel, linux-kselftest, linux-kernel, llvm
On Sun, Apr 14, 2024 at 11:26:53AM +0500, Muhammad Usama Anjum wrote:
> Let the compilers (clang) know that this function would just call
> exit() and would never return. It is needed to avoid false positive
> static analysis errors. All similar functions calling exit()
> unconditionally have been marked as __noreturn.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> This patch has been suggested [1] and tested on top of the following
> patches:
> - f07041728422 ("selftests: add ksft_exit_fail_perror()") which is
> in kselftest tree already
> - ("kselftest: Mark functions that unconditionally call exit() as
> __noreturn") would appear in tip/timers/urgent
>
> [1] https://lore.kernel.org/all/8254ab4d-9cb6-402e-80dd-d9ec70d77de5@linuxfoundation.org
> ---
> tools/testing/selftests/kselftest.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h
> index 050c5fd018400..b43a7a7ca4b40 100644
> --- a/tools/testing/selftests/kselftest.h
> +++ b/tools/testing/selftests/kselftest.h
> @@ -372,7 +372,7 @@ static inline __printf(1, 2) int ksft_exit_fail_msg(const char *msg, ...)
> exit(KSFT_FAIL);
> }
>
> -static inline void ksft_exit_fail_perror(const char *msg)
> +static inline __noreturn void ksft_exit_fail_perror(const char *msg)
> {
> #ifndef NOLIBC
> ksft_exit_fail_msg("%s: %s (%d)\n", msg, strerror(errno), errno);
> --
> 2.39.2
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: Add awareness of signed integer overflow traps
@ 2024-04-15 18:34 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-15 18:34 UTC (permalink / raw)
To: Kees Cook
Cc: Marco Elver, Justin Stitt, Andrey Konovalov, Andrey Ryabinin,
Andrew Morton, kasan-dev, linux-hardening, Nick Desaulniers,
Bill Wendling, linux-kernel, llvm
On Mon, Apr 15, 2024 at 11:28:35AM -0700, Kees Cook wrote:
> On arm64, UBSAN traps can be decoded from the trap instruction. Add the
> add, sub, and mul overflow trap codes now that CONFIG_UBSAN_SIGNED_WRAP
> exists. Seen under clang 19:
>
> Internal error: UBSAN: unrecognized failure code: 00000000f2005515 [#1] PREEMPT SMP
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Closes: https://lore.kernel.org/lkml/20240411-fix-ubsan-in-hardening-config-v1-0-e0177c80ffaa@kernel.org
> Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer")
> Signed-off-by: Kees Cook <keescook@chromium.org>
As I mentioned, CONFIG_UBSAN_SIGNED_INTEGER_WRAP needs to be
CONFIG_UBSAN_SIGNED_WRAP. I applied this change with that fix up and the
warning now becomes:
Internal error: UBSAN: integer subtraction overflow: 00000000f2005515 [#1] PREEMPT SMP
So:
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Marco Elver <elver@google.com>
> Cc: Justin Stitt <justinstitt@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: kasan-dev@googlegroups.com
> Cc: linux-hardening@vger.kernel.org
> ---
> lib/ubsan.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/lib/ubsan.c b/lib/ubsan.c
> index 5fc107f61934..ad32beb8c058 100644
> --- a/lib/ubsan.c
> +++ b/lib/ubsan.c
> @@ -44,9 +44,10 @@ const char *report_ubsan_failure(struct pt_regs *regs, u32 check_type)
> case ubsan_shift_out_of_bounds:
> return "UBSAN: shift out of bounds";
> #endif
> -#ifdef CONFIG_UBSAN_DIV_ZERO
> +#if defined(CONFIG_UBSAN_DIV_ZERO) || defined(CONFIG_UBSAN_SIGNED_INTEGER_WRAP)
> /*
> - * SanitizerKind::IntegerDivideByZero emits
> + * SanitizerKind::IntegerDivideByZero and
> + * SanitizerKind::SignedIntegerOverflow emit
> * SanitizerHandler::DivremOverflow.
> */
> case ubsan_divrem_overflow:
> @@ -77,6 +78,19 @@ const char *report_ubsan_failure(struct pt_regs *regs, u32 check_type)
> return "UBSAN: alignment assumption";
> case ubsan_type_mismatch:
> return "UBSAN: type mismatch";
> +#endif
> +#ifdef CONFIG_UBSAN_SIGNED_INTEGER_WRAP
> + /*
> + * SanitizerKind::SignedIntegerOverflow emits
> + * SanitizerHandler::AddOverflow, SanitizerHandler::SubOverflow,
> + * or SanitizerHandler::MulOverflow.
> + */
> + case ubsan_add_overflow:
> + return "UBSAN: integer addition overflow";
> + case ubsan_sub_overflow:
> + return "UBSAN: integer subtraction overflow";
> + case ubsan_mul_overflow:
> + return "UBSAN: integer multiplication overflow";
> #endif
> default:
> return "UBSAN: unrecognized failure code";
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: Compile Error in Linux 6.9-rc4 with Clang 17.0.6
@ 2024-04-15 22:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-15 22:06 UTC (permalink / raw)
To: Memet Zx
Cc: Linux Kernel Mailing List, LLVM Mailing List,
GNU/Weeb Mailing List, Nick Desaulniers
On Tue, Apr 16, 2024 at 02:31:52AM +0700, Memet Zx wrote:
> Hello,
>
> I am writing to report a compile error that I encountered while
> building the latest Linux kernel (6.9-rc4) with Clang version 17.0.6.
> The error message is as follows:
>
> ```
> LD vmlinux.o
> vmlinux.o: warning: objtool: __svm_vcpu_run+0x13c: BP used as a scratch register
> vmlinux.o: warning: objtool: __svm_sev_es_vcpu_run+0x32: BP used as a scratch register
> vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__969_123_ip_vs_rr_init6()
> vmlinux.o: warning: objtool: .text.jffs2_erase_pending_blocks: unexpected end of section
> vmlinux.o: warning: objtool: .text.ocfs2_validate_and_adjust_move_goal: unexpected end of section
> vmlinux.o: warning: objtool: .text.__ocfs2_move_extents_range: unexpected end of section
> vmlinux.o: warning: objtool: .text.csio_ln_fdmi_rhba_cbfn: unexpected end of section
> vmlinux.o: warning: objtool: .text.jme_check_link: unexpected end of section
> vmlinux.o: warning: objtool: .text.vhci_coredump_hdr: unexpected end of section
> OBJCOPY modules.builtin.modinfo
> llvm-objcopy-17: error: SHT_STRTAB string table section [index 1173270] is non-null terminated
> make[5]: *** [scripts/Makefile.vmlinux_o:73: modules.builtin.modinfo] Error 1
> make[4]: *** [Makefile:1141: vmlinux_o] Error 2
> make[3]: *** [debian/rules:74: build-arch] Error 2
> dpkg-buildpackage: error: make -f debian/rules binary subprocess returned exit status 2
> make[2]: *** [scripts/Makefile.package:121: bindeb-pkg] Error 2
> make[1]: *** [/workspaces/greentea/linux/Makefile:1541: bindeb-pkg] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
> ```
>
> The build process was terminated with the above error message.
> I have also noticed several warnings related to objtool,
> which may be related to the issue.
>
> The compiler version I used:
>
> ```
> Ubuntu clang version 17.0.6 (++20231208085846+6009708b4367-1~exp1~20231208085949.74)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> ```
>
> The commit I used is:
>
> ```
> commit 0bbac3facb5d6cc0171c45c9873a2dc96bea9680 (grafted, HEAD -> master, origin/master, origin/HEAD)
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun Apr 14 13:38:39 2024 -0700
>
> Linux 6.9-rc4
> ```
>
> And the .config is attached at the end of this email.
>
> I would appreciate it if you could look into this issue and provide
> a fix or workaround.
>
> Thank you for your attention to this matter.
Thanks for the report. Unfortunately, I cannot reproduce this with your
configuration on 6.9-rc4 with either kernel.org LLVM 17.0.6 [1] or
Debian LLVM 17.0.6 [2]. Is this completely reproducible on your side? Is
this something that just started happening with the 6.9 cycle? What is
your build command, as I might just be missing something?
[1]: https://mirrors.edge.kernel.org/pub/tools/llvm/
[2]: ++20231208085813+6009708b4367-1~exp1~20231208085906.81, should be
the same source version and configuration you are using.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [pdx86-platform-drivers-x86:review-hans 40/59] drivers/platform/x86/amd/pmc/mp2_stb.c:94:2: error: call to undeclared function 'writeq'; ISO C99 and later do not support implicit function declarations
@ 2024-04-16 15:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-16 15:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: kernel test robot, Basavaraj Natikar, llvm, oe-kbuild-all,
Hans de Goede, Shyam Sundar S K, Kuppuswamy Sathyanarayanan
On Tue, Apr 16, 2024 at 04:06:23PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 16, 2024 at 10:35:55AM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git review-hans
> > head: 0aae4c44b032b5ede39405dfc62900adc467f362
> > commit: 2dc77993cb5eb311d6bb5584d30c3d1d42d9fa4a [40/59] platform/x86/amd/pmc: Add AMD MP2 STB functionality
> > config: i386-randconfig-011-20240416 (https://download.01.org/0day-ci/archive/20240416/202404161050.NSNJAxvX-lkp@intel.com/config)
> > compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240416/202404161050.NSNJAxvX-lkp@intel.com/reproduce)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <lkp@intel.com>
> > | Closes: https://lore.kernel.org/oe-kbuild-all/202404161050.NSNJAxvX-lkp@intel.com/
> >
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/platform/x86/amd/pmc/mp2_stb.c:94:2: error: call to undeclared function 'writeq'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 94 | writeq(mp2->dma_addr, mp2->mmio + AMD_C2P_MSG1);
> > | ^
> > drivers/platform/x86/amd/pmc/mp2_stb.c:267:45: warning: shift count >= width of type [-Wshift-count-overflow]
> > 267 | rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> > | ^~~~~~~~~~~~~~~~
> > include/linux/dma-mapping.h:77:54: note: expanded from macro 'DMA_BIT_MASK'
> > 77 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> > | ^ ~~~
> > 1 warning and 1 error generated.
>
> This is bogus, but can perhaps be 'fixed" with GENMASK((n) - 1, 0).
The second warning only appears because of the first error; if the first
error is fixed, I suspect the second one won't appear (although I have
not actually checked it).
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/2] Enable building of the devel RPM package from Kbuild
@ 2024-04-17 14:48 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-17 14:48 UTC (permalink / raw)
To: Pratham Patel
Cc: Masahiro Yamada, Nicolas Schier, Jonathan Corbet, linux-kbuild,
linux-doc, linux-kernel, thefirst1322
On Wed, Apr 17, 2024 at 04:37:32AM +0000, Pratham Patel wrote:
> This addresses a minor nit where I want a `-devel` RPM package to be
> built when I build a binary RPM package with either `binrpm-pkg`
> or `rpm-pkg` target(s).
>
> Pratham Patel (2):
> kbuild: allow toggling the `with_devel` RPM macro
> docs: kbuild: document KBUILD_RPM_WITH_DEVEL
>
> Documentation/kbuild/kbuild.rst | 6 ++++++
> scripts/Makefile.package | 5 ++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> --
> 2.42.0
>
Hmmm, when I execute
$ make -skj"$(nproc)" ARCH=x86_64 O=build mrproper defconfig binrpm-pkg
I end up with
$ ls -1 build/rpmbuild/RPMS/x86_64
kernel-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
kernel-devel-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
kernel-headers-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
so it seems like this is already happening?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* tools/testing/selftests/clone3/clone3_set_tid.c appears to always pass?
@ 2024-04-17 15:22 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-17 15:22 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-kselftest, linux-kernel
Hi Christian,
I am looking at tools/testing/selftests/clone3/clone3_set_tid.c as part
of a patch to clean up the uses of 'return ksft_exit_...();' throughout
the selftests (as they call exit() so they do not return) and I noticed
that it seems to always pass even when there may have been an error?
if (waitpid(ns_pid, &status, 0) < 0) {
ksft_print_msg("Child returned %s\n", strerror(errno));
ret = -errno;
goto out;
}
...
out:
ret = 0;
return !ret ? ksft_exit_pass() : ksft_exit_fail();
}
Should the ret and out label positions be switched? Alternatively, it
seems like ret and out do not have that many uses, perhaps it would just
be better to call the ksft_exit_...() directly in their respective
paths? I am not going to touch it as part of my patch but I felt it was
worth reporting since it appears to have been there since the
introduction of this test in commit 41585bbeeef9 ("selftests: add tests
for clone3() with *set_tid").
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/2] Enable building of the devel RPM package from Kbuild
@ 2024-04-17 15:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-17 15:47 UTC (permalink / raw)
To: Pratham Patel
Cc: Masahiro Yamada, Nicolas Schier, Jonathan Corbet, linux-kbuild,
linux-doc, linux-kernel, thefirst1322
On Wed, Apr 17, 2024 at 03:08:57PM +0000, Pratham Patel wrote:
> On Wed Apr 17, 2024 at 8:18 PM IST, Nathan Chancellor wrote:
> > On Wed, Apr 17, 2024 at 04:37:32AM +0000, Pratham Patel wrote:
> > > This addresses a minor nit where I want a `-devel` RPM package to be
> > > built when I build a binary RPM package with either `binrpm-pkg`
> > > or `rpm-pkg` target(s).
> > >
> > > Pratham Patel (2):
> > > kbuild: allow toggling the `with_devel` RPM macro
> > > docs: kbuild: document KBUILD_RPM_WITH_DEVEL
> > >
> > > Documentation/kbuild/kbuild.rst | 6 ++++++
> > > scripts/Makefile.package | 5 ++++-
> > > 2 files changed, 10 insertions(+), 1 deletion(-)
> > >
> > > --
> > > 2.42.0
> > >
> >
> > Hmmm, when I execute
> >
> > $ make -skj"$(nproc)" ARCH=x86_64 O=build mrproper defconfig binrpm-pkg
> >
> > I end up with
> >
> > $ ls -1 build/rpmbuild/RPMS/x86_64
> > kernel-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
> > kernel-devel-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
> > kernel-headers-6.9.0_rc4_00031_g96fca68c4fbf-1.x86_64.rpm
> >
> > so it seems like this is already happening?
> >
> > Cheers,
> > Nathan
>
> Ah sorry, that was a typo. I meant to say the following:
> "This addresses a minor nit where I **don't** want a `-devel` RPM
> package to be built when I build a binary RPM package with either
> `binrpm-pkg` or `rpm-pkg` target(s)."
>
> That is because on ARM systems where I just need to quickly test the
> upstream defconfig, I don't really need the `-devel` package.
>
> Also, I see that in a hurry, I did the opposite of what I wanted in the
> patches. This went unnoticed since I had KBUILD_RPM_WITH_DEVEL=0 for me
> during testing. Sorry about that!
>
> I'll send a v2 fixing this stupid mistake.
Ah, understood! I am not sure you actually need a v2 though because I
think you can already accomplish what you are looking for by adding
RPMOPTS='--without devel'
to your make command, at least that works for me. Commit 2a291fc315b6
("kbuild: rpm-pkg: introduce %{with_devel} switch to select devel
package") introduced this.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.4 uploaded
@ 2024-04-17 17:12 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-17 17:12 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.4 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/3] s390/vmlogrdr: Remove function pointer cast
@ 2024-04-18 14:51 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-18 14:51 UTC (permalink / raw)
To: Heiko Carstens
Cc: akpm, arnd, gor, agordeev, borntraeger, svens, wintera, twinkler,
linux-s390, netdev, llvm, patches
Hi Heiko,
On Thu, Apr 18, 2024 at 12:25:49PM +0200, Heiko Carstens wrote:
> On Thu, Apr 18, 2024 at 11:54:38AM +0200, Heiko Carstens wrote:
> > On Wed, Apr 17, 2024 at 11:24:35AM -0700, Nathan Chancellor wrote:
> > > Clang warns (or errors with CONFIG_WERROR) after enabling
> > > -Wcast-function-type-strict by default:
> > >
> > > drivers/s390/char/vmlogrdr.c:746:18: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
> > > 746 | dev->release = (void (*)(struct device *))kfree;
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 1 error generated.
> > >
> > > Add a standalone function to fix the warning properly, which addresses
> > > the root of the warning that these casts are not safe for kCFI. The
> > > comment is not really relevant after this change, so remove it.
> > >
> > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > ---
> > > drivers/s390/char/vmlogrdr.c | 13 +++++--------
> > > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > > @@ -736,14 +740,7 @@ static int vmlogrdr_register_device(struct vmlogrdr_priv_t *priv)
> > > dev->driver = &vmlogrdr_driver;
> > > dev->groups = vmlogrdr_attr_groups;
> > > dev_set_drvdata(dev, priv);
> > > - /*
> > > - * The release function could be called after the
> > > - * module has been unloaded. It's _only_ task is to
> > > - * free the struct. Therefore, we specify kfree()
> > > - * directly here. (Probably a little bit obfuscating
> > > - * but legitime ...).
> > > - */
> >
> > Why is the comment not relevant after this change? Or better: why is it not
> > valid before this change, which is why the code was introduced a very long
> > time ago? Any reference?
> >
> > I've seen the warning since quite some time, but didn't change the code
> > before sure that this doesn't introduce the bug described in the comment.
>
> From only 20 years ago:
>
> https://lore.kernel.org/all/20040316170812.GA14971@kroah.com/
>
> The particular code (zfcp) was changed, so it doesn't have this code
> (or never did?) anymore, but for the rest this may or may not still
> be valid.
I guess relevant may not have been the correct word. Maybe obvious? I
can keep the comment but I do not really see what it adds, although
reading the above thread, I suppose it was added as justification for
calling kfree() as ->release() for a 'struct device'? Kind of seems like
that ship has sailed since I see this all over the place as a
->release() function. I do not see how this patch could have a function
change beyond that but I may be misreading or misinterpreting your full
comment.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/3] s390/vmlogrdr: Remove function pointer cast
@ 2024-04-18 15:34 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-18 15:34 UTC (permalink / raw)
To: Heiko Carstens
Cc: akpm, arnd, gor, agordeev, borntraeger, svens, wintera, twinkler,
linux-s390, netdev, llvm, patches
On Thu, Apr 18, 2024 at 05:15:01PM +0200, Heiko Carstens wrote:
> Hi Nathan,
>
> > > > > - /*
> > > > > - * The release function could be called after the
> > > > > - * module has been unloaded. It's _only_ task is to
> > > > > - * free the struct. Therefore, we specify kfree()
> > > > > - * directly here. (Probably a little bit obfuscating
> > > > > - * but legitime ...).
> > > > > - */
> > > >
> > > > Why is the comment not relevant after this change? Or better: why is it not
> > > > valid before this change, which is why the code was introduced a very long
> > > > time ago? Any reference?
> > > >
> > > > I've seen the warning since quite some time, but didn't change the code
> > > > before sure that this doesn't introduce the bug described in the comment.
> > >
> > > From only 20 years ago:
> > >
> > > https://lore.kernel.org/all/20040316170812.GA14971@kroah.com/
> > >
> > > The particular code (zfcp) was changed, so it doesn't have this code
> > > (or never did?) anymore, but for the rest this may or may not still
> > > be valid.
> >
> > I guess relevant may not have been the correct word. Maybe obvious? I
> > can keep the comment but I do not really see what it adds, although
> > reading the above thread, I suppose it was added as justification for
> > calling kfree() as ->release() for a 'struct device'? Kind of seems like
> > that ship has sailed since I see this all over the place as a
> > ->release() function. I do not see how this patch could have a function
> > change beyond that but I may be misreading or misinterpreting your full
> > comment.
>
> That doesn't answer my question what prevents the release function
> from being called after the module has been unloaded.
>
> At least back then when the code was added it was a real bug.
I do not know the answer to that question (and I suspect there is
nothing preventing ->release() from being called after module unload),
so I'll just bring back the comment (although I'll need to adjust it
since kfree() is not being used there directly anymore). Andrew, would
you prefer a diff from what's in -mm or a v2?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 1/3] s390/vmlogrdr: Remove function pointer cast
@ 2024-04-18 20:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-18 20:32 UTC (permalink / raw)
To: Heiko Carstens
Cc: akpm, arnd, gor, agordeev, borntraeger, svens, wintera, twinkler,
linux-s390, netdev, llvm, patches
On Thu, Apr 18, 2024 at 09:21:00PM +0200, Heiko Carstens wrote:
> Hi Nathan,
>
> > > > > > > - /*
> > > > > > > - * The release function could be called after the
> > > > > > > - * module has been unloaded. It's _only_ task is to
> > > > > > > - * free the struct. Therefore, we specify kfree()
> > > > > > > - * directly here. (Probably a little bit obfuscating
> > > > > > > - * but legitime ...).
> > > > > > > - */
> > >
> > > That doesn't answer my question what prevents the release function
> > > from being called after the module has been unloaded.
> > >
> > > At least back then when the code was added it was a real bug.
> >
> > I do not know the answer to that question (and I suspect there is
> > nothing preventing ->release() from being called after module unload),
> > so I'll just bring back the comment (although I'll need to adjust it
> > since kfree() is not being used there directly anymore). Andrew, would
> > you prefer a diff from what's in -mm or a v2?
>
> I guess there is some confusion here :) My request was not to keep the
Heh, yes, my apologies for being rather dense, I was not interpreting
the comment or the thread you linked properly... :(
> comment. I'm much rather afraid that the comment is still valid; and if
> that is the case then your patch series adds three bugs, exactly what is
> described in the comment.
>
> Right now the release function is kfree which is always within the kernel
> image, and therefore always a valid branch target. If however the code is
> changed to what you propose, then the release function would be inside of
> the module, which potentially does not exist anymore when the release
> function is called, since the module was unloaded.
> So the branch target would be invalid.
That is super subtle :/ I can understand what the comment is warning
about with that extra context. I see Arnd's suggestion which may fix
this problem and get rid of the warning but if there are other ideas, I
am all ears. I guess we could just disable -Wcast-function-type-strict
for this code since s390 does not support kCFI right now but since it
could, it seems better to resolve it properly.
Thanks a lot for the quick review and catching my mistake, cheers!
Nathan
^ permalink raw reply [relevance 99%]
* 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 rdma-next v3 4/6] RDMA/mana_ib: enable RoCE on port 1
@ 2024-04-22 19:37 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-22 19:37 UTC (permalink / raw)
To: Konstantin Taranov
Cc: kotaranov, sharmaajay, longli, jgg, leon, linux-rdma, linux-kernel
Hi Konstantin,
On Wed, Apr 10, 2024 at 01:42:29AM -0700, Konstantin Taranov wrote:
> From: Konstantin Taranov <kotaranov@microsoft.com>
>
> Set netdev and RoCEv2 flag to enable GID population on port 1.
> Use GIDs of the master netdev. As mc->ports[] stores slave devices,
> use a helper to get the master netdev.
>
> Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
> ---
> drivers/infiniband/hw/mana/device.c | 15 +++++++++++++++
> drivers/infiniband/hw/mana/main.c | 15 +++++++++++----
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mana/device.c b/drivers/infiniband/hw/mana/device.c
> index 47547a962b19..e7981301d10b 100644
> --- a/drivers/infiniband/hw/mana/device.c
> +++ b/drivers/infiniband/hw/mana/device.c
> @@ -53,6 +53,7 @@ static int mana_ib_probe(struct auxiliary_device *adev,
> {
> struct mana_adev *madev = container_of(adev, struct mana_adev, adev);
> struct gdma_dev *mdev = madev->mdev;
> + struct net_device *upper_ndev;
> struct mana_context *mc;
> struct mana_ib_dev *dev;
> int ret;
> @@ -79,6 +80,20 @@ static int mana_ib_probe(struct auxiliary_device *adev,
> dev->ib_dev.num_comp_vectors = 1;
> dev->ib_dev.dev.parent = mdev->gdma_context->dev;
>
> + rcu_read_lock(); /* required to get upper dev */
> + upper_ndev = netdev_master_upper_dev_get_rcu(mc->ports[0]);
> + if (!upper_ndev) {
> + rcu_read_unlock();
> + ibdev_err(&dev->ib_dev, "Failed to get master netdev");
> + goto free_ib_device;
> + }
Clang now warns (or errors with CONFIG_WERROR):
drivers/infiniband/hw/mana/device.c:88:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
88 | if (!upper_ndev) {
| ^~~~~~~~~~~
drivers/infiniband/hw/mana/device.c:150:9: note: uninitialized use occurs here
150 | return ret;
| ^~~
drivers/infiniband/hw/mana/device.c:88:2: note: remove the 'if' if its condition is always false
88 | if (!upper_ndev) {
| ^~~~~~~~~~~~~~~~~~
89 | rcu_read_unlock();
| ~~~~~~~~~~~~~~~~~~
90 | ibdev_err(&dev->ib_dev, "Failed to get master netdev");
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
91 | goto free_ib_device;
| ~~~~~~~~~~~~~~~~~~~~
92 | }
| ~
drivers/infiniband/hw/mana/device.c:62:9: note: initialize the variable 'ret' to silence this warning
62 | int ret;
| ^
| = 0
1 error generated.
I could not really find a consistent return code for when
netdev_master_upper_dev_get_rcu() fails. -ENODEV?
Cheers,
Nathan
> + ret = ib_device_set_netdev(&dev->ib_dev, upper_ndev, 1);
> + rcu_read_unlock();
> + if (ret) {
> + ibdev_err(&dev->ib_dev, "Failed to set ib netdev, ret %d", ret);
> + goto free_ib_device;
> + }
> +
> ret = mana_gd_register_device(&mdev->gdma_context->mana_ib);
> if (ret) {
> ibdev_err(&dev->ib_dev, "Failed to register device, ret %d",
> diff --git a/drivers/infiniband/hw/mana/main.c b/drivers/infiniband/hw/mana/main.c
> index 29550f2173ff..7a9d7e13b7b1 100644
> --- a/drivers/infiniband/hw/mana/main.c
> +++ b/drivers/infiniband/hw/mana/main.c
> @@ -527,11 +527,18 @@ int mana_ib_mmap(struct ib_ucontext *ibcontext, struct vm_area_struct *vma)
> int mana_ib_get_port_immutable(struct ib_device *ibdev, u32 port_num,
> struct ib_port_immutable *immutable)
> {
> - /*
> - * This version only support RAW_PACKET
> - * other values need to be filled for other types
> - */
> + struct ib_port_attr attr;
> + int err;
> +
> + err = ib_query_port(ibdev, port_num, &attr);
> + if (err)
> + return err;
> +
> + immutable->pkey_tbl_len = attr.pkey_tbl_len;
> + immutable->gid_tbl_len = attr.gid_tbl_len;
> immutable->core_cap_flags = RDMA_CORE_PORT_RAW_PACKET;
> + if (port_num == 1)
> + immutable->core_cap_flags |= RDMA_CORE_PORT_IBA_ROCE_UDP_ENCAP;
>
> return 0;
> }
> --
> 2.43.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: buildtar: remove warning for the default case
@ 2024-04-22 20:45 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-22 20:45 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-kbuild, linux-kernel, Nicolas Schier
On Tue, Apr 23, 2024 at 12:46:10AM +0900, Masahiro Yamada wrote:
> Given KBUILD_IMAGE properly set in arch/*/Makefile, the default case
> should work in most scenarios. The only oddity is the naming of the
> copy destination, vmlinux-kbuild-${KERNELRELEASE}. Let's rename it
> to vmlinuz-${KERNELRELEASE} because the kernel is often compressed.
> Remove the warning to avoid unnecessary patch submissions when the
> default case suffices.
>
> Remove the x86 case, which is now identical to the default.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Sounds good to me, the script is extensible enough that if this does not
work by default for some architecture, a new case can be added, rather
than penalizing architectures for which it does work.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> scripts/package/buildtar | 12 +-----------
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> index ed8d9b496305..fe816f62a290 100755
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -59,9 +59,6 @@ cp -v -- "${objtree}/vmlinux" "${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
> # build tree.
> #
> case "${ARCH}" in
> - x86|i386|x86_64)
> - cp -v -- "${objtree}/arch/x86/boot/bzImage" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> - ;;
> alpha)
> cp -v -- "${objtree}/arch/alpha/boot/vmlinux.gz" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> ;;
> @@ -110,13 +107,6 @@ case "${ARCH}" in
> done
> ;;
> *)
> - cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
> - echo "" >&2
> - echo '** ** ** WARNING ** ** **' >&2
> - echo "" >&2
> - echo "Your architecture did not define any architecture-dependent files" >&2
> - echo "to be placed into the tarball. Please add those to ${0} ..." >&2
> - echo "" >&2
> - sleep 5
> + cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> ;;
> esac
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* 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] drivers: remoteproc: xlnx: Add Versal and Versal-NET support
@ 2024-04-23 16:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-23 16:06 UTC (permalink / raw)
To: Tanmay Shah
Cc: andersson, mathieu.poirier, linux-remoteproc, linux-kernel, llvm
Hi Tanmay,
On Thu, Apr 18, 2024 at 03:01:25PM -0700, Tanmay Shah wrote:
> AMD-Xilinx Versal platform is successor of ZynqMP platform.
> Real-time Processing Unit R5 cluster IP on Versal is same as
> of ZynqMP Platform. Power-domains ids for Versal platform is
> different than ZynqMP.
>
> AMD-Xilinx Versal-NET platform is successor of Versal platform.
> Versal-NET Real-Time Processing Unit has two clusters and each
> cluster contains dual core ARM Cortex-R52 processors. Each R52
> core is assigned 128KB of TCM memory.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 53 ++++++++-----------------
> 1 file changed, 17 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 7b1c12108bff..a6d8ac7394e7 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -300,36 +300,6 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> dev_warn(dev, "failed to send message\n");
> }
>
> -/*
> - * zynqmp_r5_set_mode()
> - *
> - * set RPU cluster and TCM operation mode
> - *
> - * @r5_core: pointer to zynqmp_r5_core type object
> - * @fw_reg_val: value expected by firmware to configure RPU cluster mode
> - * @tcm_mode: value expected by fw to configure TCM mode (lockstep or split)
> - *
> - * Return: 0 for success and < 0 for failure
> - */
> -static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
> - enum rpu_oper_mode fw_reg_val,
> - enum rpu_tcm_comb tcm_mode)
> -{
> - int ret;
> -
> - ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to set RPU mode\n");
> - return ret;
> - }
> -
> - ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
> - if (ret < 0)
> - dev_err(r5_core->dev, "failed to configure TCM\n");
> -
> - return ret;
> -}
> -
> /*
> * zynqmp_r5_rproc_start()
> * @rproc: single R5 core's corresponding rproc instance
> @@ -941,7 +911,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> /* Maintain backward compatibility for zynqmp by using hardcode TCM address. */
> if (of_find_property(r5_core->np, "reg", NULL))
> ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
> - else
> + else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
> ret = zynqmp_r5_get_tcm_node(cluster);
This change breaks the build with clang:
drivers/remoteproc/xlnx_r5_remoteproc.c:914:11: error: variable 'ret' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/remoteproc/xlnx_r5_remoteproc.c:917:6: note: uninitialized use occurs here
917 | if (ret) {
| ^~~
drivers/remoteproc/xlnx_r5_remoteproc.c:914:7: note: remove the 'if' if its condition is always true
914 | else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss"))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
915 | ret = zynqmp_r5_get_tcm_node(cluster);
drivers/remoteproc/xlnx_r5_remoteproc.c:907:9: note: initialize the variable 'ret' to silence this warning
907 | int ret, i;
| ^
| = 0
1 error generated.
Should ret be initialized to zero or should there be an else statement?
Cheers,
Nathan
>
> if (ret) {
> @@ -960,12 +930,21 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> return ret;
> }
>
> - ret = zynqmp_r5_set_mode(r5_core, fw_reg_val, tcm_mode);
> - if (ret) {
> - dev_err(dev, "failed to set r5 cluster mode %d, err %d\n",
> - cluster->mode, ret);
> + ret = zynqmp_pm_set_rpu_mode(r5_core->pm_domain_id, fw_reg_val);
> + if (ret < 0) {
> + dev_err(r5_core->dev, "failed to set RPU mode\n");
> return ret;
> }
> +
> + if (of_find_property(dev_of_node(dev), "xlnx,tcm-mode", NULL) ||
> + device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
> + ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id,
> + tcm_mode);
> + if (ret < 0) {
> + dev_err(r5_core->dev, "failed to configure TCM\n");
> + return ret;
> + }
> + }
> }
>
> return 0;
> @@ -1022,7 +1001,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> ret = of_property_read_u32(dev_node, "xlnx,tcm-mode", (u32 *)&tcm_mode);
> if (ret)
> return ret;
> - } else {
> + } else if (device_is_compatible(dev, "xlnx,zynqmp-r5fss")) {
> if (cluster_mode == LOCKSTEP_MODE)
> tcm_mode = PM_RPU_TCM_COMB;
> else
> @@ -1212,6 +1191,8 @@ static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
>
> /* Match table for OF platform binding */
> static const struct of_device_id zynqmp_r5_remoteproc_match[] = {
> + { .compatible = "xlnx,versal-net-r52fss", },
> + { .compatible = "xlnx,versal-r5fss", },
> { .compatible = "xlnx,zynqmp-r5fss", },
> { /* end of list */ },
> };
>
> base-commit: 912ebe48bec5927e2049e91b0e8a9cc682a709d2
> --
> 2.25.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] selftests: Make ksft_exit functions return void instead of int
@ 2024-04-24 15:05 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-24 15:05 UTC (permalink / raw)
To: Shuah Khan; +Cc: shuah, tglx, linux-kselftest, linux-kernel
On Wed, Apr 24, 2024 at 07:44:31AM -0600, Shuah Khan wrote:
> On 4/17/24 09:37, Nathan Chancellor wrote:
> > Commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
> > unconditionally call exit() as __noreturn") marked functions that call
> > exit() as __noreturn but it did not change the return type of these
> > functions from 'void' to 'int' like it should have (since a noreturn
> > function by definition cannot return an integer because it does not
> > return...) because there are many tests that return the result of the
> > ksft_exit function, even though it has never been used due to calling
> > exit().
> >
> > Prior to adding __noreturn, the compiler would not know that the functions
> > that call exit() will not return, so code like
> >
> > void ksft_exit_fail(void)
> > {
> > exit(1);
> > }
> >
> > void ksft_exit_pass(void)
> > {
> > exit(0);
> > }
> >
> > int main(void)
> > {
> > int ret;
> >
> > ret = foo();
> > if (ret)
> > ksft_exit_fail();
> > ksft_exit_pass();
> > }
> >
> > would cause the compiler to complain that main() does not return an
> > integer, even though when ksft_exit_pass() is called, exit() will cause
> > the program to terminate. So ksft_exit_...() returns int to make the
> > compiler happy.
> >
> > int ksft_exit_fail(void)
> > {
> > exit(1);
> > }
> >
> > int ksft_exit_pass(void)
> > {
> > exit(0);
> > }
> >
> > int main(void)
> > {
> > int ret;
> >
> > ret = foo();
> > if (ret)
> > return ksft_exit_fail();
> > return ksft_exit_pass();
> > }
> >
> > While this results in no warnings, it is weird semantically and it has
> > issues as noted in the aforementioned __noreturn change. Now that
> > __noreturn has been added to these functions, it is much cleaner to
> > change the functions to 'void' and eliminate the return statements, as
> > it has been made clear to the compiler that these functions terminate
> > the program. Drop the return before all instances of ksft_exit_...() in
> > a mechanical way. Only two manually changes were made to transform
> >
> > return !ret ? ksft_exit_pass() : ksft_exit_fail();
> >
> > into the more idiomatic
> >
> > if (ret)
> > ksft_exit_fail();
> > ksft_exit_pass();
> >
> > as well as a few style clean ups now that the code is shorter.
> >
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > tools/testing/selftests/clone3/clone3_clear_sighand.c | 2 +-
> > tools/testing/selftests/clone3/clone3_set_tid.c | 4 +++-
> > tools/testing/selftests/ipc/msgque.c | 11 +++++------
> > tools/testing/selftests/kselftest.h | 12 ++++++------
> > .../selftests/membarrier/membarrier_test_multi_thread.c | 2 +-
> > .../selftests/membarrier/membarrier_test_single_thread.c | 2 +-
> > tools/testing/selftests/mm/compaction_test.c | 6 +++---
> > tools/testing/selftests/mm/cow.c | 2 +-
> > tools/testing/selftests/mm/gup_longterm.c | 2 +-
> > tools/testing/selftests/mm/gup_test.c | 4 ++--
> > tools/testing/selftests/mm/ksm_functional_tests.c | 2 +-
> > tools/testing/selftests/mm/madv_populate.c | 2 +-
> > tools/testing/selftests/mm/mkdirty.c | 2 +-
> > tools/testing/selftests/mm/pagemap_ioctl.c | 4 ++--
> > tools/testing/selftests/mm/soft-dirty.c | 2 +-
> > tools/testing/selftests/pidfd/pidfd_fdinfo_test.c | 2 +-
> > tools/testing/selftests/pidfd/pidfd_open_test.c | 4 +++-
> > tools/testing/selftests/pidfd/pidfd_poll_test.c | 2 +-
> > tools/testing/selftests/pidfd/pidfd_test.c | 2 +-
> > tools/testing/selftests/resctrl/resctrl_tests.c | 6 +++---
> > tools/testing/selftests/sync/sync_test.c | 3 +--
> > tools/testing/selftests/timers/adjtick.c | 4 ++--
> > tools/testing/selftests/timers/alarmtimer-suspend.c | 4 ++--
> > tools/testing/selftests/timers/change_skew.c | 4 ++--
> > tools/testing/selftests/timers/freq-step.c | 4 ++--
> > tools/testing/selftests/timers/leap-a-day.c | 10 +++++-----
> > tools/testing/selftests/timers/leapcrash.c | 4 ++--
> > tools/testing/selftests/timers/mqueue-lat.c | 4 ++--
> > tools/testing/selftests/timers/posix_timers.c | 12 ++++++------
> > tools/testing/selftests/timers/raw_skew.c | 6 +++---
> > tools/testing/selftests/timers/set-2038.c | 4 ++--
> > tools/testing/selftests/timers/set-tai.c | 4 ++--
> > tools/testing/selftests/timers/set-timer-lat.c | 4 ++--
> > tools/testing/selftests/timers/set-tz.c | 4 ++--
> > tools/testing/selftests/timers/skew_consistency.c | 4 ++--
> > tools/testing/selftests/timers/threadtest.c | 2 +-
> > tools/testing/selftests/timers/valid-adjtimex.c | 6 +++---
> > tools/testing/selftests/x86/lam.c | 2 +-
> > 38 files changed, 81 insertions(+), 79 deletions(-)
> >
>
> Please generate separate patches for each test so it is easy to apply
> them and also reduce merge conflicts.
Is applying 30+ patches easier than applying just one? It is not a
trivial amount of work for me to break this series up into individual
patches but I will do so if you really want me to. I based this on the
kselftest tree directly so that it would apply cleanly.
How does breaking apart the changes reduce merge conflicts? The diff is
going to be the same and semantic conflicts can still occur due to the
kselftest.h changes.
> You are missing maintainers for clone3, mm, pidfd tests. I can take these
> through kselftest tree, but I need the changes split.
Fair enough, I should have CC'd them, although given this is a change to
the kselftest API, I was not sure they would care too much.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] selftests: Make ksft_exit functions return void instead of int
@ 2024-04-24 16:10 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-24 16:10 UTC (permalink / raw)
To: Shuah Khan; +Cc: shuah, tglx, linux-kselftest, linux-kernel
On Wed, Apr 24, 2024 at 10:00:12AM -0600, Shuah Khan wrote:
> On 4/24/24 09:05, Nathan Chancellor wrote:
> > On Wed, Apr 24, 2024 at 07:44:31AM -0600, Shuah Khan wrote:
> > > On 4/17/24 09:37, Nathan Chancellor wrote:
> > > > Commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
> > > > unconditionally call exit() as __noreturn") marked functions that call
> > > > exit() as __noreturn but it did not change the return type of these
> > > > functions from 'void' to 'int' like it should have (since a noreturn
> > > > function by definition cannot return an integer because it does not
> > > > return...) because there are many tests that return the result of the
> > > > ksft_exit function, even though it has never been used due to calling
> > > > exit().
> > > >
> > > > Prior to adding __noreturn, the compiler would not know that the functions
> > > > that call exit() will not return, so code like
> > > >
> > > > void ksft_exit_fail(void)
> > > > {
> > > > exit(1);
> > > > }
> > > >
> > > > void ksft_exit_pass(void)
> > > > {
> > > > exit(0);
> > > > }
> > > >
> > > > int main(void)
> > > > {
> > > > int ret;
> > > >
> > > > ret = foo();
> > > > if (ret)
> > > > ksft_exit_fail();
> > > > ksft_exit_pass();
> > > > }
> > > >
> > > > would cause the compiler to complain that main() does not return an
> > > > integer, even though when ksft_exit_pass() is called, exit() will cause
> > > > the program to terminate. So ksft_exit_...() returns int to make the
> > > > compiler happy.
> > > >
> > > > int ksft_exit_fail(void)
> > > > {
> > > > exit(1);
> > > > }
> > > >
> > > > int ksft_exit_pass(void)
> > > > {
> > > > exit(0);
> > > > }
> > > >
> > > > int main(void)
> > > > {
> > > > int ret;
> > > >
> > > > ret = foo();
> > > > if (ret)
> > > > return ksft_exit_fail();
> > > > return ksft_exit_pass();
> > > > }
> > > >
> > > > While this results in no warnings, it is weird semantically and it has
> > > > issues as noted in the aforementioned __noreturn change. Now that
> > > > __noreturn has been added to these functions, it is much cleaner to
> > > > change the functions to 'void' and eliminate the return statements, as
> > > > it has been made clear to the compiler that these functions terminate
> > > > the program. Drop the return before all instances of ksft_exit_...() in
> > > > a mechanical way. Only two manually changes were made to transform
> > > >
> > > > return !ret ? ksft_exit_pass() : ksft_exit_fail();
> > > >
> > > > into the more idiomatic
> > > >
> > > > if (ret)
> > > > ksft_exit_fail();
> > > > ksft_exit_pass();
> > > >
> > > > as well as a few style clean ups now that the code is shorter.
> > > >
> > > > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > > > ---
> > > > tools/testing/selftests/clone3/clone3_clear_sighand.c | 2 +-
> > > > tools/testing/selftests/clone3/clone3_set_tid.c | 4 +++-
> > > > tools/testing/selftests/ipc/msgque.c | 11 +++++------
> > > > tools/testing/selftests/kselftest.h | 12 ++++++------
> > > > .../selftests/membarrier/membarrier_test_multi_thread.c | 2 +-
> > > > .../selftests/membarrier/membarrier_test_single_thread.c | 2 +-
> > > > tools/testing/selftests/mm/compaction_test.c | 6 +++---
> > > > tools/testing/selftests/mm/cow.c | 2 +-
> > > > tools/testing/selftests/mm/gup_longterm.c | 2 +-
> > > > tools/testing/selftests/mm/gup_test.c | 4 ++--
> > > > tools/testing/selftests/mm/ksm_functional_tests.c | 2 +-
> > > > tools/testing/selftests/mm/madv_populate.c | 2 +-
> > > > tools/testing/selftests/mm/mkdirty.c | 2 +-
> > > > tools/testing/selftests/mm/pagemap_ioctl.c | 4 ++--
> > > > tools/testing/selftests/mm/soft-dirty.c | 2 +-
> > > > tools/testing/selftests/pidfd/pidfd_fdinfo_test.c | 2 +-
> > > > tools/testing/selftests/pidfd/pidfd_open_test.c | 4 +++-
> > > > tools/testing/selftests/pidfd/pidfd_poll_test.c | 2 +-
> > > > tools/testing/selftests/pidfd/pidfd_test.c | 2 +-
> > > > tools/testing/selftests/resctrl/resctrl_tests.c | 6 +++---
> > > > tools/testing/selftests/sync/sync_test.c | 3 +--
> > > > tools/testing/selftests/timers/adjtick.c | 4 ++--
> > > > tools/testing/selftests/timers/alarmtimer-suspend.c | 4 ++--
> > > > tools/testing/selftests/timers/change_skew.c | 4 ++--
> > > > tools/testing/selftests/timers/freq-step.c | 4 ++--
> > > > tools/testing/selftests/timers/leap-a-day.c | 10 +++++-----
> > > > tools/testing/selftests/timers/leapcrash.c | 4 ++--
> > > > tools/testing/selftests/timers/mqueue-lat.c | 4 ++--
> > > > tools/testing/selftests/timers/posix_timers.c | 12 ++++++------
> > > > tools/testing/selftests/timers/raw_skew.c | 6 +++---
> > > > tools/testing/selftests/timers/set-2038.c | 4 ++--
> > > > tools/testing/selftests/timers/set-tai.c | 4 ++--
> > > > tools/testing/selftests/timers/set-timer-lat.c | 4 ++--
> > > > tools/testing/selftests/timers/set-tz.c | 4 ++--
> > > > tools/testing/selftests/timers/skew_consistency.c | 4 ++--
> > > > tools/testing/selftests/timers/threadtest.c | 2 +-
> > > > tools/testing/selftests/timers/valid-adjtimex.c | 6 +++---
> > > > tools/testing/selftests/x86/lam.c | 2 +-
> > > > 38 files changed, 81 insertions(+), 79 deletions(-)
> > > >
> > >
> > > Please generate separate patches for each test so it is easy to apply
> > > them and also reduce merge conflicts.
> >
> > Is applying 30+ patches easier than applying just one? It is not a
> > trivial amount of work for me to break this series up into individual
> > patches but I will do so if you really want me to. I based this on the
> > kselftest tree directly so that it would apply cleanly.
> >
>
> I am not asking each file to be a separate patch.
What granularity would you like? One per folder in
tools/testing/selftest (i.e., clone3, ipc, membarrier, etc)?
> > How does breaking apart the changes reduce merge conflicts? The diff is
> > going to be the same and semantic conflicts can still occur due to the
> > kselftest.h changes.
>
> selftest patches go through various repos. With this patch touching
> several tests, there will be conflicts with multiple trees.
>
> If this patch can't be split due to dependency on kselftest.h, I will
> pull it in, but I do need you to include all the maintainers.
No, it can be split as long as the kselftest.h change is last. I just
did not see the value of that at the time but I am not out to make life
harder for maintainers so I will split it as you see fit.
> > > You are missing maintainers for clone3, mm, pidfd tests. I can take these
> > > through kselftest tree, but I need the changes split.
> >
> > Fair enough, I should have CC'd them, although given this is a change to
> > the kselftest API, I was not sure they would care too much.
> >
>
> The reason for cc'ing the maintainers is to keep them in the loop about this
> change that could result in merge conflicts between kselftest tree and theirs.
>
> Besides I would rather not have developers make calls on who should or shouldn't
> care about a change. :)
Sure, that makes sense.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH 0/2] drm/amd/display: Use frame_warn_flag consistently in dml2 Makefile
@ 2024-04-24 18:19 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-24 18:19 UTC (permalink / raw)
To: harry.wentland, sunpeng.li, Rodrigo.Siqueira, alexander.deucher,
christian.koenig, Xinhui.Pan
Cc: aurabindo.pillai, amd-gfx, dri-devel, llvm, patches, Nathan Chancellor
Hi all,
This series resolves a couple instances of -Wframe-larger-than from
the new display code that appear with newer versions of clang along
without another inconsistency I noticed while fixing this, which have
been accounted for with the $(frame_warn_flag) variable.
---
Nathan Chancellor (2):
drm/amd/display: Add frame_warn_flag to dml2_core_shared.o
drm/amd/display: Fix CFLAGS for dml2_core_dcn4_calcs.o
drivers/gpu/drm/amd/display/dc/dml2/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
---
base-commit: d60dc4dd72412d5d9566fdf391e4202b05f88912
change-id: 20240424-amdgpu-dml2-fix-frame-larger-than-dcn401-48ff7e1f51ea
Best regards,
--
Nathan Chancellor <nathan@kernel.org>
^ permalink raw reply [relevance 99%]
* Re: [RFC PATCH 2/9] x86/purgatory: Simplify stack handling
@ 2024-04-24 18:26 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-24 18:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, x86, Ard Biesheuvel, Arnd Bergmann, Eric Biederman,
kexec, Nick Desaulniers, Kees Cook, Bill Wendling, Justin Stitt,
Masahiro Yamada
On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The x86 purgatory, which does little more than verify a SHA-256 hash of
> the loaded segments, currently uses three different stacks:
> - one in .bss that is used to call the purgatory C code
> - one in .rodata that is only used to switch to an updated code segment
> descriptor in the GDT
> - one in .data, which allows it to be prepopulated from the kexec loader
> in theory, but this is not actually being taken advantage of.
>
> Simplify this, by dropping the latter two stacks, as well as the loader
> logic that programs RSP.
>
> Both the stacks in .bss and .data are 4k aligned, but 16 byte alignment
> is more than sufficient.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/x86/include/asm/kexec.h | 1 -
> arch/x86/kernel/kexec-bzimage64.c | 8 --------
> arch/x86/purgatory/entry64.S | 8 --------
> arch/x86/purgatory/setup-x86_64.S | 2 +-
> arch/x86/purgatory/stack.S | 18 ------------------
This needs a small fix up to build.
make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index acc09799af2a..2b6b2fb033d6 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
OBJECT_FILES_NON_STANDARD := y
-purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string.o
+purgatory-y := purgatory.o setup-x86_$(BITS).o sha256.o entry64.o string.o
targets += $(purgatory-y)
PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
^ permalink raw reply related [relevance 99%]
* Re: [RFC PATCH 2/9] x86/purgatory: Simplify stack handling
@ 2024-04-24 18:26 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-24 18:26 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-kernel, x86, Ard Biesheuvel, Arnd Bergmann, Eric Biederman,
kexec, Nick Desaulniers, Kees Cook, Bill Wendling, Justin Stitt,
Masahiro Yamada
On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The x86 purgatory, which does little more than verify a SHA-256 hash of
> the loaded segments, currently uses three different stacks:
> - one in .bss that is used to call the purgatory C code
> - one in .rodata that is only used to switch to an updated code segment
> descriptor in the GDT
> - one in .data, which allows it to be prepopulated from the kexec loader
> in theory, but this is not actually being taken advantage of.
>
> Simplify this, by dropping the latter two stacks, as well as the loader
> logic that programs RSP.
>
> Both the stacks in .bss and .data are 4k aligned, but 16 byte alignment
> is more than sufficient.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/x86/include/asm/kexec.h | 1 -
> arch/x86/kernel/kexec-bzimage64.c | 8 --------
> arch/x86/purgatory/entry64.S | 8 --------
> arch/x86/purgatory/setup-x86_64.S | 2 +-
> arch/x86/purgatory/stack.S | 18 ------------------
This needs a small fix up to build.
make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index acc09799af2a..2b6b2fb033d6 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
OBJECT_FILES_NON_STANDARD := y
-purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o string.o
+purgatory-y := purgatory.o setup-x86_$(BITS).o sha256.o entry64.o string.o
targets += $(purgatory-y)
PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [relevance 99%]
* Re: [PATCH] wifi: nl80211: Avoid address calculations via out of bounds array indexing
@ 2024-04-25 18:13 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-04-25 18:13 UTC (permalink / raw)
To: Kees Cook
Cc: Johannes Berg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wireless, netdev, Jeff Johnson,
Gustavo A. R. Silva, linux-kernel, linux-hardening
On Wed, Apr 24, 2024 at 03:01:01PM -0700, Kees Cook wrote:
> Before request->channels[] can be used, request->n_channels must be set.
> Additionally, address calculations for memory after the "channels" array
> need to be calculated from the allocation base ("request") rather than
> via the first "out of bounds" index of "channels", otherwise run-time
> bounds checking will throw a warning.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by")
> Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> net/wireless/nl80211.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index f391b4055944..f1ed0981147e 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -9163,6 +9163,7 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
> struct wiphy *wiphy;
> int err, tmp, n_ssids = 0, n_channels, i;
> size_t ie_len, size;
> + size_t ssids_offset, ie_offset;
>
> wiphy = &rdev->wiphy;
>
> @@ -9208,21 +9209,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
> return -EINVAL;
>
> size = struct_size(request, channels, n_channels);
> + ssids_offset = size;
> size = size_add(size, array_size(sizeof(*request->ssids), n_ssids));
> + ie_offset = size;
> size = size_add(size, ie_len);
> request = kzalloc(size, GFP_KERNEL);
> if (!request)
> return -ENOMEM;
> + request->n_channels = n_channels;
>
> if (n_ssids)
> - request->ssids = (void *)&request->channels[n_channels];
> + request->ssids = (void *)request + ssids_offset;
> request->n_ssids = n_ssids;
> - if (ie_len) {
> - if (n_ssids)
> - request->ie = (void *)(request->ssids + n_ssids);
> - else
> - request->ie = (void *)(request->channels + n_channels);
> - }
> + if (ie_len)
> + request->ie = (void *)request + ie_offset;
>
> i = 0;
> if (scan_freqs) {
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH rdma-next 1/1] RDMA/mana_ib: fix missing ret value
@ 2024-04-26 16:58 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-26 16:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jason Gunthorpe, Konstantin Taranov, kotaranov, sharmaajay,
longli, leon, linux-rdma, linux-kernel
On Fri, Apr 26, 2024 at 07:53:02PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 23, 2024 at 12:03:15PM -0300, Jason Gunthorpe wrote:
> > On Tue, Apr 23, 2024 at 07:15:51AM -0700, Konstantin Taranov wrote:
> > > From: Konstantin Taranov <kotaranov@microsoft.com>
> > >
> > > Set ret to -ENODEV when netdev_master_upper_dev_get_rcu
> > > returns NULL.
> > >
> > > Fixes: 8b184e4f1c32 ("RDMA/mana_ib: Enable RoCE on port 1")
> > > Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
> > > ---
> > > drivers/infiniband/hw/mana/device.c | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > Applied to for-next, thanks
>
> So, what's wrong with my patch that had been sent _before_ this one?
Was it?
This patch:
$ date -d 'Tue, 23 Apr 2024 07:15:51 -0700' -u
Tue Apr 23 02:15:51 PM UTC 2024
Your patch: https://lore.kernel.org/20240423204258.3669706-1-andriy.shevchenko@linux.intel.com/
$ date -d 'Tue, 23 Apr 2024 23:42:58 +0300' -u
Tue Apr 23 08:42:58 PM UTC 2024
Seems like this one beat yours by six hours?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] ubsan: Avoid i386 UBSAN handler crashes with Clang
@ 2024-04-26 17:38 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-26 17:38 UTC (permalink / raw)
To: Kees Cook
Cc: Marco Elver, Erhard Furtner, Andrey Konovalov, Andrey Ryabinin,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm, kasan-dev,
linux-hardening, Andrew Morton, linux-kernel
On Wed, Apr 24, 2024 at 03:40:29PM -0700, Kees Cook wrote:
> When generating Runtime Calls, Clang doesn't respect the -mregparm=3
> option used on i386. Hopefully this will be fixed correctly in Clang 19:
> https://github.com/llvm/llvm-project/pull/89707
> but we need to fix this for earlier Clang versions today. Force the
> calling convention to use non-register arguments.
>
> Reported-by: Erhard Furtner <erhard_f@mailbox.org>
> Closes: https://github.com/KSPP/linux/issues/350
> Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Marco Elver <elver@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> 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: llvm@lists.linux.dev
> Cc: kasan-dev@googlegroups.com
> Cc: linux-hardening@vger.kernel.org
> v2:
> - use email address in Reported-by
> - link to upstream llvm bug in ubsan.h comment
> - drop needless /**/
> - explicitly test Clang version
> v1: https://lore.kernel.org/lkml/20240424162942.work.341-kees@kernel.org/
> ---
> lib/ubsan.h | 41 +++++++++++++++++++++++++++--------------
> 1 file changed, 27 insertions(+), 14 deletions(-)
>
> diff --git a/lib/ubsan.h b/lib/ubsan.h
> index 50ef50811b7c..07e37d4429b4 100644
> --- a/lib/ubsan.h
> +++ b/lib/ubsan.h
> @@ -124,19 +124,32 @@ typedef s64 s_max;
> typedef u64 u_max;
> #endif
>
> -void __ubsan_handle_add_overflow(void *data, void *lhs, void *rhs);
> -void __ubsan_handle_sub_overflow(void *data, void *lhs, void *rhs);
> -void __ubsan_handle_mul_overflow(void *data, void *lhs, void *rhs);
> -void __ubsan_handle_negate_overflow(void *_data, void *old_val);
> -void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs);
> -void __ubsan_handle_type_mismatch(struct type_mismatch_data *data, void *ptr);
> -void __ubsan_handle_type_mismatch_v1(void *_data, void *ptr);
> -void __ubsan_handle_out_of_bounds(void *_data, void *index);
> -void __ubsan_handle_shift_out_of_bounds(void *_data, void *lhs, void *rhs);
> -void __ubsan_handle_builtin_unreachable(void *_data);
> -void __ubsan_handle_load_invalid_value(void *_data, void *val);
> -void __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
> - unsigned long align,
> - unsigned long offset);
> +/*
> + * When generating Runtime Calls, Clang doesn't respect the -mregparm=3
> + * option used on i386: https://github.com/llvm/llvm-project/issues/89670
> + * Fix this for earlier Clang versions by forcing the calling convention
> + * to use non-register arguments.
> + */
> +#if defined(CONFIG_X86_32) && \
> + defined(CONFIG_CC_IS_CLANG) && CONFIG_CLANG_VERSION < 190000
> +# define ubsan_linkage asmlinkage
> +#else
> +# define ubsan_linkage
> +#endif
> +
> +void ubsan_linkage __ubsan_handle_add_overflow(void *data, void *lhs, void *rhs);
> +void ubsan_linkage __ubsan_handle_sub_overflow(void *data, void *lhs, void *rhs);
> +void ubsan_linkage __ubsan_handle_mul_overflow(void *data, void *lhs, void *rhs);
> +void ubsan_linkage __ubsan_handle_negate_overflow(void *_data, void *old_val);
> +void ubsan_linkage __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs);
> +void ubsan_linkage __ubsan_handle_type_mismatch(struct type_mismatch_data *data, void *ptr);
> +void ubsan_linkage __ubsan_handle_type_mismatch_v1(void *_data, void *ptr);
> +void ubsan_linkage __ubsan_handle_out_of_bounds(void *_data, void *index);
> +void ubsan_linkage __ubsan_handle_shift_out_of_bounds(void *_data, void *lhs, void *rhs);
> +void ubsan_linkage __ubsan_handle_builtin_unreachable(void *_data);
> +void ubsan_linkage __ubsan_handle_load_invalid_value(void *_data, void *val);
> +void ubsan_linkage __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
> + unsigned long align,
> + unsigned long offset);
>
> #endif
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: [RFC PATCH 2/9] x86/purgatory: Simplify stack handling
@ 2024-04-26 21:53 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-26 21:53 UTC (permalink / raw)
To: Justin Stitt
Cc: Ard Biesheuvel, linux-kernel, x86, Ard Biesheuvel, Arnd Bergmann,
Eric Biederman, kexec, Nick Desaulniers, Kees Cook,
Bill Wendling, Masahiro Yamada
On Fri, Apr 26, 2024 at 09:32:52PM +0000, Justin Stitt wrote:
> Hi,
>
> On Wed, Apr 24, 2024 at 11:26:59AM -0700, Nathan Chancellor wrote:
> > On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> > > arch/x86/purgatory/stack.S | 18 ------------------
> >
> > This needs a small fix up to build.
> >
> > make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
> >
>
> I was trying to reproduce this build failure, but to no avail. I am
> curious what your build target / build command was.
>
> It is clear that stack.S has been removed so your change makes sense, I
> don't doubt that -- I just cannot get that specific error message you
Odd, I was using my distribution configuration for the test but it is
easily reproducible with allmodconfig:
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 allmodconfig arch/x86/purgatory/
make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
...
> encountered (what is a .ro file supposed to be, anyway?).
Read only? Relocatable object? *shrug*
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [RFC PATCH 2/9] x86/purgatory: Simplify stack handling
@ 2024-04-26 21:53 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-26 21:53 UTC (permalink / raw)
To: Justin Stitt
Cc: Ard Biesheuvel, linux-kernel, x86, Ard Biesheuvel, Arnd Bergmann,
Eric Biederman, kexec, Nick Desaulniers, Kees Cook,
Bill Wendling, Masahiro Yamada
On Fri, Apr 26, 2024 at 09:32:52PM +0000, Justin Stitt wrote:
> Hi,
>
> On Wed, Apr 24, 2024 at 11:26:59AM -0700, Nathan Chancellor wrote:
> > On Wed, Apr 24, 2024 at 05:53:12PM +0200, Ard Biesheuvel wrote:
> > > arch/x86/purgatory/stack.S | 18 ------------------
> >
> > This needs a small fix up to build.
> >
> > make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
> >
>
> I was trying to reproduce this build failure, but to no avail. I am
> curious what your build target / build command was.
>
> It is clear that stack.S has been removed so your change makes sense, I
> don't doubt that -- I just cannot get that specific error message you
Odd, I was using my distribution configuration for the test but it is
easily reproducible with allmodconfig:
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 allmodconfig arch/x86/purgatory/
make[6]: *** No rule to make target 'arch/x86/purgatory/stack.o', needed by 'arch/x86/purgatory/purgatory.ro'.
...
> encountered (what is a .ro file supposed to be, anyway?).
Read only? Relocatable object? *shrug*
Cheers,
Nathan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [relevance 99%]
* Re: [PATCH] hardening: Refresh KCFI options, add some more
@ 2024-04-29 22:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-29 22:16 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-hardening, linux-arm-kernel, llvm, linux-kernel
On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> Add some stuff that got missed along the way:
>
> - CONFIG_UNWIND_PATCH_PAC_INTO_SCS=y so SCS vs PAC is hardware
> selectable.
>
> - CONFIG_X86_KERNEL_IBT=y while a default, just be sure.
>
> - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
> it isn't as secure as straight KCFI.)
>
> - CONFIG_PAGE_TABLE_CHECK=y for userspace mapping sanity.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
One comment below.
> ---
> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> 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: linux-hardening@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: llvm@lists.linux.dev
> ---
> arch/arm64/configs/hardening.config | 5 +++++
> arch/x86/configs/hardening.config | 9 +++++++++
> kernel/configs/hardening.config | 4 ++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/arch/arm64/configs/hardening.config b/arch/arm64/configs/hardening.config
> index b0e795208998..e8a18fec7a3e 100644
> --- a/arch/arm64/configs/hardening.config
> +++ b/arch/arm64/configs/hardening.config
> @@ -5,6 +5,7 @@ CONFIG_ARM64_SW_TTBR0_PAN=y
>
> # Software Shadow Stack or PAC
> CONFIG_SHADOW_CALL_STACK=y
> +CONFIG_UNWIND_PATCH_PAC_INTO_SCS=y
>
> # Pointer authentication (ARMv8.3 and later). If hardware actually supports
> # it, one can turn off CONFIG_STACKPROTECTOR_STRONG with this enabled.
> @@ -20,3 +21,7 @@ CONFIG_ARM64_E0PD=y
>
> # Available in ARMv8.7 and later.
> CONFIG_ARM64_EPAN=y
> +
> +# Enable Kernel Control Flow Integrity (currently Clang only).
> +CONFIG_CFI_CLANG=y
> +# CONFIG_CFI_PERMISSIVE is not set
Should this be a part of kernel/configs/hardening.config because RISC-V
supports it (and 32-bit ARM will soon too)?
> diff --git a/arch/x86/configs/hardening.config b/arch/x86/configs/hardening.config
> index 7b497f3b7bc3..b47e5f411dd3 100644
> --- a/arch/x86/configs/hardening.config
> +++ b/arch/x86/configs/hardening.config
> @@ -10,5 +10,14 @@ CONFIG_INTEL_IOMMU_DEFAULT_ON=y
> CONFIG_INTEL_IOMMU_SVM=y
> CONFIG_AMD_IOMMU=y
>
> +# Enforce CET Indirect Branch Tracking in the kernel.
> +CONFIG_X86_KERNEL_IBT=y
> +
> +# Enable Kernel Control Flow Integrity (currently Clang only), but disable
> +# weaker FINEIBT landing pads.
> +CONFIG_CFI_CLANG=y
> +# CONFIG_CFI_PERMISSIVE is not set
> +# CONFIG_FINEIBT is not set
> +
> # Enable CET Shadow Stack for userspace.
> CONFIG_X86_USER_SHADOW_STACK=y
> diff --git a/kernel/configs/hardening.config b/kernel/configs/hardening.config
> index 7a5bbfc024b7..4be0de1f085c 100644
> --- a/kernel/configs/hardening.config
> +++ b/kernel/configs/hardening.config
> @@ -23,6 +23,10 @@ CONFIG_SLAB_FREELIST_HARDENED=y
> CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
> CONFIG_RANDOM_KMALLOC_CACHES=y
>
> +# Sanity check userspace page table mappings.
> +CONFIG_PAGE_TABLE_CHECK=y
> +CONFIG_PAGE_TABLE_CHECK_ENFORCED=y
> +
> # Randomize kernel stack offset on syscall entry.
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
>
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] hardening: Refresh KCFI options, add some more
@ 2024-04-29 22:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-29 22:16 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-hardening, linux-arm-kernel, llvm, linux-kernel
On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> Add some stuff that got missed along the way:
>
> - CONFIG_UNWIND_PATCH_PAC_INTO_SCS=y so SCS vs PAC is hardware
> selectable.
>
> - CONFIG_X86_KERNEL_IBT=y while a default, just be sure.
>
> - CONFIG_CFI_CLANG=y for x86 and arm64. (And disable FINEIBT since
> it isn't as secure as straight KCFI.)
>
> - CONFIG_PAGE_TABLE_CHECK=y for userspace mapping sanity.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
One comment below.
> ---
> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> 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: linux-hardening@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: llvm@lists.linux.dev
> ---
> arch/arm64/configs/hardening.config | 5 +++++
> arch/x86/configs/hardening.config | 9 +++++++++
> kernel/configs/hardening.config | 4 ++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/arch/arm64/configs/hardening.config b/arch/arm64/configs/hardening.config
> index b0e795208998..e8a18fec7a3e 100644
> --- a/arch/arm64/configs/hardening.config
> +++ b/arch/arm64/configs/hardening.config
> @@ -5,6 +5,7 @@ CONFIG_ARM64_SW_TTBR0_PAN=y
>
> # Software Shadow Stack or PAC
> CONFIG_SHADOW_CALL_STACK=y
> +CONFIG_UNWIND_PATCH_PAC_INTO_SCS=y
>
> # Pointer authentication (ARMv8.3 and later). If hardware actually supports
> # it, one can turn off CONFIG_STACKPROTECTOR_STRONG with this enabled.
> @@ -20,3 +21,7 @@ CONFIG_ARM64_E0PD=y
>
> # Available in ARMv8.7 and later.
> CONFIG_ARM64_EPAN=y
> +
> +# Enable Kernel Control Flow Integrity (currently Clang only).
> +CONFIG_CFI_CLANG=y
> +# CONFIG_CFI_PERMISSIVE is not set
Should this be a part of kernel/configs/hardening.config because RISC-V
supports it (and 32-bit ARM will soon too)?
> diff --git a/arch/x86/configs/hardening.config b/arch/x86/configs/hardening.config
> index 7b497f3b7bc3..b47e5f411dd3 100644
> --- a/arch/x86/configs/hardening.config
> +++ b/arch/x86/configs/hardening.config
> @@ -10,5 +10,14 @@ CONFIG_INTEL_IOMMU_DEFAULT_ON=y
> CONFIG_INTEL_IOMMU_SVM=y
> CONFIG_AMD_IOMMU=y
>
> +# Enforce CET Indirect Branch Tracking in the kernel.
> +CONFIG_X86_KERNEL_IBT=y
> +
> +# Enable Kernel Control Flow Integrity (currently Clang only), but disable
> +# weaker FINEIBT landing pads.
> +CONFIG_CFI_CLANG=y
> +# CONFIG_CFI_PERMISSIVE is not set
> +# CONFIG_FINEIBT is not set
> +
> # Enable CET Shadow Stack for userspace.
> CONFIG_X86_USER_SHADOW_STACK=y
> diff --git a/kernel/configs/hardening.config b/kernel/configs/hardening.config
> index 7a5bbfc024b7..4be0de1f085c 100644
> --- a/kernel/configs/hardening.config
> +++ b/kernel/configs/hardening.config
> @@ -23,6 +23,10 @@ CONFIG_SLAB_FREELIST_HARDENED=y
> CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
> CONFIG_RANDOM_KMALLOC_CACHES=y
>
> +# Sanity check userspace page table mappings.
> +CONFIG_PAGE_TABLE_CHECK=y
> +CONFIG_PAGE_TABLE_CHECK_ENFORCED=y
> +
> # Randomize kernel stack offset on syscall entry.
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
>
> --
> 2.34.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: [PATCH] hardening: Refresh KCFI options, add some more
@ 2024-04-30 15:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-30 15:12 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-hardening, linux-arm-kernel, llvm, linux-kernel
On Mon, Apr 29, 2024 at 10:35:03PM -0700, Kees Cook wrote:
> On Mon, Apr 29, 2024 at 03:16:50PM -0700, Nathan Chancellor wrote:
> > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> > [...]
> > > +# Enable Kernel Control Flow Integrity (currently Clang only).
> > > +CONFIG_CFI_CLANG=y
> > > +# CONFIG_CFI_PERMISSIVE is not set
> >
> > Should this be a part of kernel/configs/hardening.config because RISC-V
> > supports it (and 32-bit ARM will soon too)?
>
> Probably yes. I was worried it might be "noisy" for archs that don't
> support it, but frankly if someone is using "make hardening.config" they
> probably want to know about unsupported options. :)
It would be potentially noisy as it is currently written since someone
building with GCC for arm64 or x86_64 could merge hardening.config into
their configuration and they would see CONFIG_CFI_CLANG get enabled by
merge_config.sh but on oldconfig or olddefconfig, it would get flipped
off again because the toolchain dependencies are not met. Might as well
make it architecture agnostic at that point :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] hardening: Refresh KCFI options, add some more
@ 2024-04-30 15:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-04-30 15:12 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-hardening, linux-arm-kernel, llvm, linux-kernel
On Mon, Apr 29, 2024 at 10:35:03PM -0700, Kees Cook wrote:
> On Mon, Apr 29, 2024 at 03:16:50PM -0700, Nathan Chancellor wrote:
> > On Fri, Apr 26, 2024 at 03:29:44PM -0700, Kees Cook wrote:
> > [...]
> > > +# Enable Kernel Control Flow Integrity (currently Clang only).
> > > +CONFIG_CFI_CLANG=y
> > > +# CONFIG_CFI_PERMISSIVE is not set
> >
> > Should this be a part of kernel/configs/hardening.config because RISC-V
> > supports it (and 32-bit ARM will soon too)?
>
> Probably yes. I was worried it might be "noisy" for archs that don't
> support it, but frankly if someone is using "make hardening.config" they
> probably want to know about unsupported options. :)
It would be potentially noisy as it is currently written since someone
building with GCC for arm64 or x86_64 could merge hardening.config into
their configuration and they would see CONFIG_CFI_CLANG get enabled by
merge_config.sh but on oldconfig or olddefconfig, it would get flipped
off again because the toolchain dependencies are not met. Might as well
make it architecture agnostic at that point :)
Cheers,
Nathan
_______________________________________________
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: [PATCH] selftests/harness: fix many "format string is empty" warnings
@ 2024-05-01 15:13 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-01 15:13 UTC (permalink / raw)
To: John Hubbard
Cc: Shuah Khan, linux-kselftest, LKML, Valentin Obst, Kees Cook,
Nick Desaulniers, Justin Stitt, Bill Wendling
Hi John,
On Tue, Apr 30, 2024 at 07:08:13PM -0700, John Hubbard wrote:
> In order to build with clang at all, in order to see these symptoms, one
> must first apply Valentin Obst's build fix for LLVM [1]. Once that is
> done, then when building with clang, via:
>
> make LLVM=1 -C tools/testing/selftests
>
> ...clang emits a "format string is empty" warning. (gcc also emits a
> similar warning.)
The warning you are describing here sounds like the same exact one that
commit caed8eba2215 ("selftests: kselftest_harness: fix Clang warning
about zero-length format") should have addressed in 6.9-rc5. Is this
patch actually necessary?
> Fix by passing NULL, instead of "", for the msg argument to
Because this text is describing what was done in caed8eba2215...
> ksft_test_result_code(). This removes dozens of warnings and a few
> errors (some tests have -Werror set).
>
> [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
>
> Cc: Valentin Obst <kernel@valentinobst.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Justin Stitt <justinstitt@google.com>
> Cc: Bill Wendling <morbo@google.com>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> tools/testing/selftests/kselftest_harness.h | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h
> index d98702b6955d..456b8694e678 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -1207,8 +1207,10 @@ void __run_test(struct __fixture_metadata *f,
> else
> diagnostic = "unknown";
>
> - ksft_test_result_code(t->exit_code, test_name,
> - diagnostic ? "%s" : NULL, diagnostic);
> + if (diagnostic)
> + ksft_test_result_code(t->exit_code, test_name, "%s", diagnostic);
> + else
> + ksft_test_result_code(t->exit_code, test_name, NULL);
but this diff is not doing that because it is based on a tree that has
caed8eba2215; instead, it appears to be a completely identical
transformation?
Cheers,
Nathan
> free(test_name);
> }
>
>
> base-commit: 18daea77cca626f590fb140fc11e3a43c5d41354
> prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
> --
> 2.45.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] powerpc: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n
@ 2024-05-01 16:20 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-01 16:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: naresh.kamboju, linuxppc-dev, arnd
Hi Michael,
On Wed, May 01, 2024 at 12:04:40AM +1000, Michael Ellerman wrote:
> With -Wextra clang warns about pointer arithmetic using a null pointer.
> When building with CONFIG_PCI=n, that triggers a warning in the IO
> accessors, eg:
>
> In file included from linux/arch/powerpc/include/asm/io.h:672:
> linux/arch/powerpc/include/asm/io-defs.h:23:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> 23 | DEF_PCI_AC_RET(inb, u8, (unsigned long port), (port), pio, port)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ...
> linux/arch/powerpc/include/asm/io.h:591:53: note: expanded from macro '__do_inb'
> 591 | #define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port);
> | ~~~~~~~~~~~~~~~~~~~~~ ^
>
> That is because when CONFIG_PCI=n, _IO_BASE is defined as 0.
>
> There is code that builds with calls to IO accessors even when
> CONFIG_PCI=n, but the actual calls are guarded by runtime checks.
> If not those calls would be faulting, because the page at virtual
> address zero is (usually) not mapped into the kernel. As Arnd pointed
> out, it is possible a large port value could cause the address to be
> above mmap_min_addr which would then access userspace, which would be
> a bug.
>
> To avoid any such issues, and also fix the compiler warning, set the
> _IO_BASE to POISON_POINTER_DELTA. That is a value chosen to point into
> unmapped space between the kernel and userspace, so any access will
> always fault.
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Closes: https://lore.kernel.org/all/CA+G9fYtEh8zmq8k8wE-8RZwW-Qr927RLTn+KqGnq1F=ptaaNsA@mail.gmail.com
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/io.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> index 08c550ed49be..1cd6eb6c8101 100644
> --- a/arch/powerpc/include/asm/io.h
> +++ b/arch/powerpc/include/asm/io.h
> @@ -37,7 +37,7 @@ extern struct pci_dev *isa_bridge_pcidev;
> * define properly based on the platform
> */
> #ifndef CONFIG_PCI
> -#define _IO_BASE 0
> +#define _IO_BASE POISON_POINTER_DELTA
This works for CONFIG_PPC64 but not CONFIG_PPC32 (so tinyconfig and
allnoconfig like Naresh reported) because CONFIG_ILLEGAL_POINTER_VALUE
is defined as 0 in that case.
$ grep -P 'CONFIG_(ILLEGAL_POINTER_VALUE|PCI|PPC32)' .config
CONFIG_PPC32=y
CONFIG_ILLEGAL_POINTER_VALUE=0
> #define _ISA_MEM_BASE 0
> #define PCI_DRAM_OFFSET 0
> #elif defined(CONFIG_PPC32)
> --
> 2.44.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/alternatives: Make FineIBT mode Kconfig selectable
@ 2024-05-01 16:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-01 16:33 UTC (permalink / raw)
To: Kees Cook
Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Alexei Starovoitov,
Sami Tolvanen, Josh Poimboeuf, Juergen Gross, Breno Leitao,
linux-kernel, linux-hardening
On Tue, Apr 30, 2024 at 05:02:22PM -0700, Kees Cook wrote:
> Since FineIBT performs checking at the destination, it is weaker against
> attacks that can construct arbitrary executable memory contents. As such,
> some system builders want to run with FineIBT disabled by default. Allow
> the "cfi=kcfi" boot param mode to be selectable through Kconfig via the
> newly introduced CONFIG_CFI_AUTO_DEFAULT.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
I verified that flipping the configuration does indeed change the
default and that 'cfi=' could still be used to override whatever choice
was made at compile time. This patch was a perfect excuse to put my new
CET enabled test machine to work.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
CFI_DEFAULT_AUTO reads a little bit better to me personally but I am not
looking to get into painting today :)
> ---
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
> arch/x86/Kconfig | 9 +++++++++
> arch/x86/include/asm/cfi.h | 2 +-
> arch/x86/kernel/alternative.c | 8 ++++----
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 4fff6ed46e90..d5cf52d2f6a8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2424,6 +2424,15 @@ config STRICT_SIGALTSTACK_SIZE
>
> Say 'N' unless you want to really enforce this check.
>
> +config CFI_AUTO_DEFAULT
> + bool "Attempt to use FineIBT by default at boot time"
> + depends on FINEIBT
> + default y
> + help
> + Attempt to use FineIBT by default at boot time. If enabled,
> + this is the same as booting with "cfi=auto". If disabled,
> + this is the same as booting with "cfi=kcfi".
> +
> source "kernel/livepatch/Kconfig"
>
> endmenu
> diff --git a/arch/x86/include/asm/cfi.h b/arch/x86/include/asm/cfi.h
> index 7cd752557905..31d19c815f99 100644
> --- a/arch/x86/include/asm/cfi.h
> +++ b/arch/x86/include/asm/cfi.h
> @@ -93,7 +93,7 @@
> *
> */
> enum cfi_mode {
> - CFI_DEFAULT, /* FineIBT if hardware has IBT, otherwise kCFI */
> + CFI_AUTO, /* FineIBT if hardware has IBT, otherwise kCFI */
> CFI_OFF, /* Taditional / IBT depending on .config */
> CFI_KCFI, /* Optionally CALL_PADDING, IBT, RETPOLINE */
> CFI_FINEIBT, /* see arch/x86/kernel/alternative.c */
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 45a280f2161c..e8d0892d89cf 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -902,8 +902,8 @@ void __init_or_module apply_seal_endbr(s32 *start, s32 *end) { }
>
> #endif /* CONFIG_X86_KERNEL_IBT */
>
> -#ifdef CONFIG_FINEIBT
> -#define __CFI_DEFAULT CFI_DEFAULT
> +#ifdef CONFIG_CFI_AUTO_DEFAULT
> +#define __CFI_DEFAULT CFI_AUTO
> #elif defined(CONFIG_CFI_CLANG)
> #define __CFI_DEFAULT CFI_KCFI
> #else
> @@ -1011,7 +1011,7 @@ static __init int cfi_parse_cmdline(char *str)
> }
>
> if (!strcmp(str, "auto")) {
> - cfi_mode = CFI_DEFAULT;
> + cfi_mode = CFI_AUTO;
> } else if (!strcmp(str, "off")) {
> cfi_mode = CFI_OFF;
> cfi_rand = false;
> @@ -1271,7 +1271,7 @@ static void __apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> "FineIBT preamble wrong size: %ld", fineibt_preamble_size))
> return;
>
> - if (cfi_mode == CFI_DEFAULT) {
> + if (cfi_mode == CFI_AUTO) {
> cfi_mode = CFI_KCFI;
> if (HAS_KERNEL_IBT && cpu_feature_enabled(X86_FEATURE_IBT))
> cfi_mode = CFI_FINEIBT;
> --
> 2.34.1
>
^ permalink raw reply [relevance 99%]
* Prebuilt LLVM 18.1.5 uploaded
@ 2024-05-02 15:24 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-02 15:24 UTC (permalink / raw)
To: llvm, linux-kernel; +Cc: conor, ojeda
Hi all,
I have built and uploaded LLVM 18.1.5 to
https://mirrors.edge.kernel.org/pub/tools/llvm/.
If there are any issues found, please let us know via email or
https://github.com/ClangBuiltLinux/linux/issues/new, so that we have an
opportunity to get them fixed in main and backported before the 18.x
series is no longer supported.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
@ 2024-05-03 15:54 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-05-03 15:54 UTC (permalink / raw)
To: Kuan-Wei Chiu, yury.norov; +Cc: kernel test robot, llvm, oe-kbuild-all
On Fri, May 03, 2024 at 03:38:59PM +0800, Kuan-Wei Chiu wrote:
> On Fri, May 03, 2024 at 03:31:26PM +0800, Kuan-Wei Chiu wrote:
> > On Thu, May 02, 2024 at 09:17:01PM -0700, Nathan Chancellor wrote:
> > > Hi Kuan-Wei,
> > >
> > > On Fri, May 03, 2024 at 09:34:28AM +0800, Kuan-Wei Chiu wrote:
> > > > On Fri, May 03, 2024 at 08:49:00AM +0800, kernel test robot wrote:
> > > > > Hi Kuan-Wei,
> > > > >
> > > > > kernel test robot noticed the following build errors:
> > > > >
> > > > > [auto build test ERROR on linus/master]
> > > > > [also build test ERROR on v6.9-rc6 next-20240502]
> > > > > [cannot apply to akpm-mm/mm-everything akpm-mm/mm-nonmm-unstable]
> > > > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > > > And when submitting patch, we suggest to use '--base' as documented in
> > > > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > > > >
> > > > > url: https://github.com/intel-lab-lkp/linux/commits/Kuan-Wei-Chiu/lib-test_bitops-Add-benchmark-test-for-fns/20240502-172638
> > > > > base: linus/master
> > > > > patch link: https://lore.kernel.org/r/20240502092443.6845-2-visitorckw%40gmail.com
> > > > > patch subject: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
> > > > > config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240503/202405030808.UsoMKFNP-lkp@intel.com/config)
> > > > > compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
> > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240503/202405030808.UsoMKFNP-lkp@intel.com/reproduce)
> > > > >
> > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > the same patch/commit), kindly add following tags
> > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202405030808.UsoMKFNP-lkp@intel.com/
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > > >> lib/test_bitops.c:56:39: error: variable 'tmp' set but not used [-Werror,-Wunused-but-set-variable]
> > > > > 56 | static volatile __used unsigned long tmp __initdata;
> > > > > | ^
> > > > > 1 error generated.
> > > > >
> > > > >
> > > > > vim +/tmp +56 lib/test_bitops.c
> > > > >
> > > > > 52
> > > > > 53 static int __init test_fns(void)
> > > > > 54 {
> > > > > 55 static unsigned long buf[10000] __initdata;
> > > > > > 56 static volatile __used unsigned long tmp __initdata;
> > > >
> > > > I apologize for causing the compilation failure with clang. I'm not
> > > > very familiar with clang and I'm not sure why something marked as
> > > > __used would result in the warning mentioned above. Perhaps clang does
> > > > not support attribute((used))? Is there a way to work around this
> > > > issue?
> > >
> > > It looks like __attribute__((__used__)) is not enough to stop clang from
> > > warning, unlike GCC. I can likely fix that in clang if it is acceptable
> > > to the clang maintainers (although more below on why this might be
> > > intentional) but the warning will still need to be resolved for older
> > > versions. Looking at the current clang source code and tests, it looks
> > > like __attribute__((__unused__)) should silence the warning, which the
> > > kernel has available as __always_unused or __maybe_unused, depending on
> > > the context.
> > >
> > > $ cat test.c
> > > void foo(void)
> > > {
> > > int a;
> > > a = 1;
> > > }
> > >
> > > void bar(void)
> > > {
> > > static int b;
> > > b = 2;
> > > }
> > >
> > > void baz(void)
> > > {
> > > static int c __attribute__((__used__));
> > > c = 3;
> > > }
> > >
> > > void quux(void)
> > > {
> > > static int d __attribute__((__unused__));
> > > d = 4;
> > > }
> > >
> > > void foobar(void)
> > > {
> > > static int e __attribute__((__used__)) __attribute__((__unused__));
> > > e = 1;
> > > }
> > >
> > > $ gcc -Wunused-but-set-variable -c -o /dev/null test.c
> > > test.c: In function ‘foo’:
> > > test.c:3:13: warning: variable ‘a’ set but not used [-Wunused-but-set-variable]
> > > 3 | int a;
> > > | ^
> > > test.c: In function ‘bar’:
> > > test.c:9:20: warning: variable ‘b’ set but not used [-Wunused-but-set-variable]
> > > 9 | static int b;
> > > | ^
> > >
> > > $ clang -fsyntax-only -Wunused-but-set-variable test.c
> > > test.c:3:6: warning: variable 'a' set but not used [-Wunused-but-set-variable]
> > > 3 | int a;
> > > | ^
> > > test.c:9:13: warning: variable 'b' set but not used [-Wunused-but-set-variable]
> > > 9 | static int b;
> > > | ^
> > > test.c:15:13: warning: variable 'c' set but not used [-Wunused-but-set-variable]
> > > 15 | static int c __attribute__((__used__));
> > > | ^
> > > 3 warnings generated.
> > >
> > > I've attached a diff below that resolves the warning for me and it has
> > > no code generation differences based on objdump. While having used and
> > > unused attributes together might look unusual, reading the GCC attribute
> > > manual makes it seem like these attributes fulfill similar yet different
> > > roles, __unused__ prevents any unused warnings while __used__ forces the
> > > variable to be emitted:
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Variable-Attributes.html#index-unused-variable-attribute
> > >
> > > A strict reading of that does not make it seem like __used__ implies
> > > disabling unused warnings, so I can understand why clang's behavior is
> > > the way that it is.
> > >
> > Thank you for your explanation and providing the solution. I tested the
> > diff stat you provided, and it works well for me.
> >
> Should I submit an updated version of the patch to the bitmap
> maintainer, or should this be a separate patch since the patch causing
> build failure has already been accepted? My instinct is the latter, but
> I'm concerned it might make git bisection more challenging.
Yury would be the best person to answer these questions since each
maintainer is different, some never rebase their trees while others will
squash simple fixes in to avoid bisection issues and such. I've added
him to the thread now to chime in (somehow he got dropped? the thread
starts at https://lore.kernel.org/202405030808.UsoMKFNP-lkp@intel.com/).
I think the diff in my email should be directly applicable on top of
your change with no conflicts so he could just squash that in if you are
both happy with that.
Cheers,
Nathan
> > > diff --git a/lib/test_bitops.c b/lib/test_bitops.c
> > > index 5c627b525a48..28c91072cf85 100644
> > > --- a/lib/test_bitops.c
> > > +++ b/lib/test_bitops.c
> > > @@ -53,7 +53,7 @@ static unsigned long order_comb_long[][2] = {
> > > static int __init test_fns(void)
> > > {
> > > static unsigned long buf[10000] __initdata;
> > > - static volatile __used unsigned long tmp __initdata;
> > > + static volatile __always_unused __used unsigned long tmp __initdata;
> > > unsigned int i, n;
> > > ktime_t time;
> > >
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 0/2] Fix Kernel CI issues
@ 2024-05-03 16:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-03 16:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Anatoliy Klymenko, dri-devel, linux-arm-kernel, linux-kernel,
kernel test robot, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Michal Simek
Hi Tomi,
On Sat, Apr 27, 2024 at 10:48:16AM +0300, Tomi Valkeinen wrote:
> On 26/04/2024 22:27, Anatoliy Klymenko wrote:
> > Fix number of CI reported W=1 build issues.
> >
> > Patch 1/2: Fix function arguments description.
> > Closes: https://lore.kernel.org/oe-kbuild-all/202404260616.KFGDpCDN-lkp@intel.com/
> >
> > Patch 2/2: Fix clang compilation error.
> > Closes: https://lore.kernel.org/oe-kbuild-all/202404260946.4oZXvHD2-lkp@intel.com/
> >
> > Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
> > ---
> > Changes in v3:
> > - Add Signed-off-by tag.
> >
> > - Link to v2: https://lore.kernel.org/r/20240425-dp-live-fmt-fix-v2-0-6048e81211de@amd.com
> >
> > Changes in v2:
> > - Compilation error fix added.
> >
> > - Link to v1: https://lore.kernel.org/r/20240425-dp-live-fmt-fix-v1-1-405f352d3485@amd.com
> >
> > ---
> > Anatoliy Klymenko (2):
> > drm: xlnx: zynqmp_dpsub: Fix few function comments
> > drm: xlnx: zynqmp_dpsub: Fix compilation error
> >
> > drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> > ---
> > base-commit: 2bdb481bf7a93c22b9fea8daefa2834aab23a70f
> > change-id: 20240425-dp-live-fmt-fix-a10bf7973596
> >
> > Best regards,
>
> Thanks, pushed to drm-misc-next.
I think the second patch also needs to go to drm-misc-next-fixes? The
clang warning fixed by it has returned in next-20240503 because it
appears that for-linux-next was switch from drm-misc-next to
drm-misc-next-fixes, as I see for-linux-next was pointing to commit
235e60653f8d ("drm/debugfs: Drop conditionals around of_node pointers")
on drm-misc-next in next-20240502 but it is now pointing to commit
be3f3042391d ("drm: zynqmp_dpsub: Always register bridge") on
drm-misc-next-fixes in next-20240503.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 0/2] Fix Kernel CI issues
@ 2024-05-03 16:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-03 16:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Anatoliy Klymenko, dri-devel, linux-arm-kernel, linux-kernel,
kernel test robot, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Michal Simek
Hi Tomi,
On Sat, Apr 27, 2024 at 10:48:16AM +0300, Tomi Valkeinen wrote:
> On 26/04/2024 22:27, Anatoliy Klymenko wrote:
> > Fix number of CI reported W=1 build issues.
> >
> > Patch 1/2: Fix function arguments description.
> > Closes: https://lore.kernel.org/oe-kbuild-all/202404260616.KFGDpCDN-lkp@intel.com/
> >
> > Patch 2/2: Fix clang compilation error.
> > Closes: https://lore.kernel.org/oe-kbuild-all/202404260946.4oZXvHD2-lkp@intel.com/
> >
> > Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@amd.com>
> > ---
> > Changes in v3:
> > - Add Signed-off-by tag.
> >
> > - Link to v2: https://lore.kernel.org/r/20240425-dp-live-fmt-fix-v2-0-6048e81211de@amd.com
> >
> > Changes in v2:
> > - Compilation error fix added.
> >
> > - Link to v1: https://lore.kernel.org/r/20240425-dp-live-fmt-fix-v1-1-405f352d3485@amd.com
> >
> > ---
> > Anatoliy Klymenko (2):
> > drm: xlnx: zynqmp_dpsub: Fix few function comments
> > drm: xlnx: zynqmp_dpsub: Fix compilation error
> >
> > drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> > ---
> > base-commit: 2bdb481bf7a93c22b9fea8daefa2834aab23a70f
> > change-id: 20240425-dp-live-fmt-fix-a10bf7973596
> >
> > Best regards,
>
> Thanks, pushed to drm-misc-next.
I think the second patch also needs to go to drm-misc-next-fixes? The
clang warning fixed by it has returned in next-20240503 because it
appears that for-linux-next was switch from drm-misc-next to
drm-misc-next-fixes, as I see for-linux-next was pointing to commit
235e60653f8d ("drm/debugfs: Drop conditionals around of_node pointers")
on drm-misc-next in next-20240502 but it is now pointing to commit
be3f3042391d ("drm: zynqmp_dpsub: Always register bridge") on
drm-misc-next-fixes in next-20240503.
Cheers,
Nathan
_______________________________________________
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: [PATCH] drm/msm/gen_header: allow skipping the validation
@ 2024-05-03 16:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-03 16:48 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten,
David Airlie, Daniel Vetter, linux-arm-msm, dri-devel, freedreno,
linux-kernel, Stephen Rothwell
Hi Dmitry,
On Tue, Apr 09, 2024 at 05:22:54PM +0300, Dmitry Baryshkov wrote:
> We don't need to run the validation of the XML files if we are just
> compiling the kernel. Skip the validation unless the user enables
> corresponding Kconfig option. This removes a warning from gen_header.py
> about lxml being not installed.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Closes: https://lore.kernel.org/all/20240409120108.2303d0bd@canb.auug.org.au/
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> drivers/gpu/drm/msm/Kconfig | 8 ++++++++
> drivers/gpu/drm/msm/Makefile | 9 ++++++++-
> drivers/gpu/drm/msm/registers/gen_header.py | 14 +++++++++++---
> 3 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index f202f26adab2..4c9bf237d4a2 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -54,6 +54,14 @@ config DRM_MSM_GPU_SUDO
> Only use this if you are a driver developer. This should *not*
> be enabled for production kernels. If unsure, say N.
>
> +config DRM_MSM_VALIDATE_XML
> + bool "Validate XML register files against schema"
> + depends on DRM_MSM && EXPERT
> + depends on $(success,$(PYTHON3) -c "import lxml")
> + help
> + Validate XML files with register definitions against rules-fd schema.
> + This option is mostly targeting DRM MSM developers. If unsure, say N.
Is this change going to be applied? I have gotten a little tired of
seeing "lxml not found, skipping validation" in all of my builds :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
@ 2024-05-03 22:23 99% ` Nathan Chancellor
1 sibling, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-05-03 22:23 UTC (permalink / raw)
To: Yury Norov, Miguel Ojeda
Cc: Kuan-Wei Chiu, kernel test robot, llvm, oe-kbuild-all,
Miguel Ojeda, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-kernel
On Fri, May 03, 2024 at 02:55:57PM -0700, Yury Norov wrote:
> On Fri, May 03, 2024 at 08:54:01AM -0700, Nathan Chancellor wrote:
> > On Fri, May 03, 2024 at 03:38:59PM +0800, Kuan-Wei Chiu wrote:
> > > On Fri, May 03, 2024 at 03:31:26PM +0800, Kuan-Wei Chiu wrote:
> > > > On Thu, May 02, 2024 at 09:17:01PM -0700, Nathan Chancellor wrote:
> > > > > Hi Kuan-Wei,
> > > > >
> > > > > On Fri, May 03, 2024 at 09:34:28AM +0800, Kuan-Wei Chiu wrote:
> > > > > > On Fri, May 03, 2024 at 08:49:00AM +0800, kernel test robot wrote:
> > > > > > > Hi Kuan-Wei,
> > > > > > >
> > > > > > > kernel test robot noticed the following build errors:
> > > > > > >
> > > > > > > [auto build test ERROR on linus/master]
> > > > > > > [also build test ERROR on v6.9-rc6 next-20240502]
> > > > > > > [cannot apply to akpm-mm/mm-everything akpm-mm/mm-nonmm-unstable]
> > > > > > > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > > > > > > And when submitting patch, we suggest to use '--base' as documented in
> > > > > > > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> > > > > > >
> > > > > > > url: https://github.com/intel-lab-lkp/linux/commits/Kuan-Wei-Chiu/lib-test_bitops-Add-benchmark-test-for-fns/20240502-172638
> > > > > > > base: linus/master
> > > > > > > patch link: https://lore.kernel.org/r/20240502092443.6845-2-visitorckw%40gmail.com
> > > > > > > patch subject: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
> > > > > > > config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240503/202405030808.UsoMKFNP-lkp@intel.com/config)
> > > > > > > compiler: clang version 18.1.4 (https://github.com/llvm/llvm-project e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
> > > > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240503/202405030808.UsoMKFNP-lkp@intel.com/reproduce)
> > > > > > >
> > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > > > the same patch/commit), kindly add following tags
> > > > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202405030808.UsoMKFNP-lkp@intel.com/
> > > > > > >
> > > > > > > All errors (new ones prefixed by >>):
> > > > > > >
> > > > > > > >> lib/test_bitops.c:56:39: error: variable 'tmp' set but not used [-Werror,-Wunused-but-set-variable]
> > > > > > > 56 | static volatile __used unsigned long tmp __initdata;
> > > > > > > | ^
> > > > > > > 1 error generated.
> > > > > > >
> > > > > > >
> > > > > > > vim +/tmp +56 lib/test_bitops.c
> > > > > > >
> > > > > > > 52
> > > > > > > 53 static int __init test_fns(void)
> > > > > > > 54 {
> > > > > > > 55 static unsigned long buf[10000] __initdata;
> > > > > > > > 56 static volatile __used unsigned long tmp __initdata;
> > > > > >
> > > > > > I apologize for causing the compilation failure with clang. I'm not
> > > > > > very familiar with clang and I'm not sure why something marked as
> > > > > > __used would result in the warning mentioned above. Perhaps clang does
> > > > > > not support attribute((used))? Is there a way to work around this
> > > > > > issue?
> > > > >
> > > > > It looks like __attribute__((__used__)) is not enough to stop clang from
> > > > > warning, unlike GCC. I can likely fix that in clang if it is acceptable
> > > > > to the clang maintainers (although more below on why this might be
> > > > > intentional) but the warning will still need to be resolved for older
> > > > > versions. Looking at the current clang source code and tests, it looks
> > > > > like __attribute__((__unused__)) should silence the warning, which the
> > > > > kernel has available as __always_unused or __maybe_unused, depending on
> > > > > the context.
> > > > >
> > > > > $ cat test.c
> > > > > void foo(void)
> > > > > {
> > > > > int a;
> > > > > a = 1;
> > > > > }
> > > > >
> > > > > void bar(void)
> > > > > {
> > > > > static int b;
> > > > > b = 2;
> > > > > }
> > > > >
> > > > > void baz(void)
> > > > > {
> > > > > static int c __attribute__((__used__));
> > > > > c = 3;
> > > > > }
> > > > >
> > > > > void quux(void)
> > > > > {
> > > > > static int d __attribute__((__unused__));
> > > > > d = 4;
> > > > > }
> > > > >
> > > > > void foobar(void)
> > > > > {
> > > > > static int e __attribute__((__used__)) __attribute__((__unused__));
> > > > > e = 1;
> > > > > }
> > > > >
> > > > > $ gcc -Wunused-but-set-variable -c -o /dev/null test.c
> > > > > test.c: In function ‘foo’:
> > > > > test.c:3:13: warning: variable ‘a’ set but not used [-Wunused-but-set-variable]
> > > > > 3 | int a;
> > > > > | ^
> > > > > test.c: In function ‘bar’:
> > > > > test.c:9:20: warning: variable ‘b’ set but not used [-Wunused-but-set-variable]
> > > > > 9 | static int b;
> > > > > | ^
> > > > >
> > > > > $ clang -fsyntax-only -Wunused-but-set-variable test.c
> > > > > test.c:3:6: warning: variable 'a' set but not used [-Wunused-but-set-variable]
> > > > > 3 | int a;
> > > > > | ^
> > > > > test.c:9:13: warning: variable 'b' set but not used [-Wunused-but-set-variable]
> > > > > 9 | static int b;
> > > > > | ^
> > > > > test.c:15:13: warning: variable 'c' set but not used [-Wunused-but-set-variable]
> > > > > 15 | static int c __attribute__((__used__));
> > > > > | ^
> > > > > 3 warnings generated.
> > > > >
> > > > > I've attached a diff below that resolves the warning for me and it has
> > > > > no code generation differences based on objdump. While having used and
> > > > > unused attributes together might look unusual, reading the GCC attribute
> > > > > manual makes it seem like these attributes fulfill similar yet different
> > > > > roles, __unused__ prevents any unused warnings while __used__ forces the
> > > > > variable to be emitted:
> > > > >
> > > > > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Variable-Attributes.html#index-unused-variable-attribute
> > > > >
> > > > > A strict reading of that does not make it seem like __used__ implies
> > > > > disabling unused warnings, so I can understand why clang's behavior is
> > > > > the way that it is.
> > > > >
> > > > Thank you for your explanation and providing the solution. I tested the
> > > > diff stat you provided, and it works well for me.
> > > >
> > > Should I submit an updated version of the patch to the bitmap
> > > maintainer, or should this be a separate patch since the patch causing
> > > build failure has already been accepted? My instinct is the latter, but
> > > I'm concerned it might make git bisection more challenging.
> >
> > Yury would be the best person to answer these questions since each
> > maintainer is different, some never rebase their trees while others will
> > squash simple fixes in to avoid bisection issues and such. I've added
> > him to the thread now to chime in (somehow he got dropped? the thread
> > starts at https://lore.kernel.org/202405030808.UsoMKFNP-lkp@intel.com/).
> >
> > I think the diff in my email should be directly applicable on top of
> > your change with no conflicts so he could just squash that in if you are
> > both happy with that.
> >
> > Cheers,
> > Nathan
> >
> > > > > diff --git a/lib/test_bitops.c b/lib/test_bitops.c
> > > > > index 5c627b525a48..28c91072cf85 100644
> > > > > --- a/lib/test_bitops.c
> > > > > +++ b/lib/test_bitops.c
> > > > > @@ -53,7 +53,7 @@ static unsigned long order_comb_long[][2] = {
> > > > > static int __init test_fns(void)
> > > > > {
> > > > > static unsigned long buf[10000] __initdata;
> > > > > - static volatile __used unsigned long tmp __initdata;
> > > > > + static volatile __always_unused __used unsigned long tmp __initdata;
> > > > > unsigned int i, n;
> > > > > ktime_t time;
>
> Hi Nathan,
>
> Thank you for sharing this.
>
> I think this __used __unused thing may confuse readers when spotted in
> a random test code. What do you think if we make it a new macro and
> comment properly to avoid confusion?
>
> I did that in the patch below. If you like it, I can prepend the
> Kuan-Wei's series and fix the test inplace.
>
> Thanks,
> Yury
>
> From 987a021cc76495b32f680507e0c55a105e8edff3 Mon Sep 17 00:00:00 2001
> From: Yury Norov <yury.norov@gmail.com>
> Date: Fri, 3 May 2024 12:12:00 -0700
> Subject: [PATCH] Compiler Attributes: Add __always_used macro
>
> In some cases like performance benchmarking, we need to call a
> function, but don't need to read the returned value. If compiler
> recognizes the function as pure or const, it can remove the function
> invocation, which is not what we want.
>
> To prevent that, the common practice is assigning the return value to
> a temporary static volatile __used variable. This works with GCC, but
> clang still emits Wunused-but-set-variable. To suppress that warning,
> we need to teach clang to do that with the 'unused' attribute.
>
> Nathan Chancellor explained that in details:
>
> While having used and unused attributes together might look unusual,
> reading the GCC attribute manual makes it seem like these attributes
> fulfill similar yet different roles, __unused__ prevents any unused
> warnings while __used__ forces the variable to be emitted. A strict
> reading of that does not make it seem like __used__ implies disabling
> unused warnings
>
> The compiler documentation makes it clear what happens behind the used
> and unused attributes, but the chosen names may confuse readers if such
> combination catches an eye in a random code.
>
> This patch adds __always_used macro, which combines both attributes
> and comments on what happens for those interested in details.
>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202405030808.UsoMKFNP-lkp@intel.com/
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
Yeah I think this is reasonable to make this a macro, I am sure there
are other places where this might be useful.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Adding Miguel as compiler attributes maintainer to make him aware of the
change. I think it would be reasonable to have you take it through the
bitops tree with your ack so that the test patch can make use of this as
the fix for the robot's issue.
One gotcha that might be worth mentioning is that this combination only
works on functions and non-local variables (i.e., static or global).
> ---
> include/linux/compiler_attributes.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index 8bdf6e0918c1..957b2d914119 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -361,6 +361,18 @@
> */
> #define __used __attribute__((__used__))
>
> +/*
> + * The __used attribute guarantees that the attributed variable will be
> + * always emitted by a compiler. It doesn't prevent the compiler from
> + * throwing the 'unused' warnings when it can't detect how the variable
> + * is actually used. It's a compiler implementation details either emit
> + * the warning in that case or not.
> + *
> + * The combination of both 'used' and 'unused' attributes ensures that
> + * the variable would be emitted, and will not trigger 'unused' warnings.
> + */
> +#define __always_used __used __maybe_unused
> +
> /*
> * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-warn_005funused_005fresult-function-attribute
> * clang: https://clang.llvm.org/docs/AttributeReference.html#nodiscard-warn-unused-result
> --
> 2.40.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
@ 2024-05-06 17:52 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2024-05-06 17:52 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Yury Norov, Miguel Ojeda, Kuan-Wei Chiu, kernel test robot, llvm,
oe-kbuild-all, Nick Desaulniers, Bill Wendling, Justin Stitt,
linux-kernel
On Sun, May 05, 2024 at 12:42:50PM +0200, Miguel Ojeda wrote:
> On Sat, May 4, 2024 at 12:23 AM Nathan Chancellor <nathan@kernel.org> wrote:
> > One gotcha that might be worth mentioning is that this combination only
> > works on functions and non-local variables (i.e., static or global).
>
> Yeah, since the `unused` one only applies to that, right?
No, unused can be used with local variables, used cannot.
https://godbolt.org/z/1hroMGzb1
Cheers,
Nathatn
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
@ 2024-05-06 17:56 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-06 17:56 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Yury Norov, Kuan-Wei Chiu, kernel test robot, llvm,
oe-kbuild-all, Miguel Ojeda, Nick Desaulniers, Bill Wendling,
Justin Stitt, linux-kernel
On Sun, May 05, 2024 at 12:42:53PM +0200, Miguel Ojeda wrote:
> On Fri, May 3, 2024 at 11:56 PM Yury Norov <yury.norov@gmail.com> wrote:
> >
> > + * The __used attribute guarantees that the attributed variable will be
>
> We should probably mention functions as Nathan said (unless it does
> not work for some reason).
Yeah, it should work for functions. I think clarifying it will not work
for local variables would probably be good as well, since __used__ does
not work on those like I replied in my other email, but it is not that
big of a deal.
> > + * is actually used. It's a compiler implementation details either emit
> > + * the warning in that case or not.
>
> Is it an implementation detail or rather that they took different
> alternatives/options on purpose (even if not documented)? If we think
> it is just a consequence of their implementation, perhaps we should
> mention that and what GCC/Clang do today in their latest version, in
> case it changes (so that we know whether we need to remove the macro,
> for instance).
Yeah it is entirely possible that this is not intentional but when
-Wunused-but-set-variable was introduced in Clang, I know there was a
lot of discussion around making the warning match GCC in certain ways as
well as breaking from GCC in others. I have not tried to dig up those
discussions to confirm though.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns()
@ 2024-05-07 14:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-07 14:19 UTC (permalink / raw)
To: Yury Norov
Cc: Miguel Ojeda, Miguel Ojeda, Kuan-Wei Chiu, kernel test robot,
llvm, oe-kbuild-all, Nick Desaulniers, Bill Wendling,
Justin Stitt, linux-kernel
On Mon, May 06, 2024 at 03:47:24PM -0700, Yury Norov wrote:
> On Mon, May 06, 2024 at 08:08:41PM +0200, Miguel Ojeda wrote:
> > On Mon, May 6, 2024 at 7:52 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > No, unused can be used with local variables, used cannot.
> >
> > Yeah, sorry, I meant `used`, i.e. it is that one the one that
> > constraints the combination rather than `unused`.
> >
> > >From a quick look at the links in `compiler_attributes.h`, `unused`
> > can also be applied to types, while `used` cannot -- it is another
> > difference, but your sentence above already implies it anyway. :)
> >
> > Thanks for the correction!
>
> I have applied the patch in bitmap-for-next this weekend.
>
> https://github.com/norov/linux/commit/eb21fc0c96b48d1e779a0ab16f9165a3e0cd76ad
>
> Can you guys please take a look at it wrt the last comments? I think
> it's OK. But if not, I will resend it.
Yeah, I think it looks reasonable.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] wifi: nl80211: Avoid address calculations via out of bounds array indexing
@ 2024-05-07 14:21 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-07 14:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Kees Cook, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wireless, netdev, Jeff Johnson,
Gustavo A. R. Silva, linux-kernel, linux-hardening
On Tue, May 07, 2024 at 12:46:46PM +0200, Johannes Berg wrote:
> On Thu, 2024-04-25 at 11:13 -0700, Nathan Chancellor wrote:
> > On Wed, Apr 24, 2024 at 03:01:01PM -0700, Kees Cook wrote:
> > > Before request->channels[] can be used, request->n_channels must be set.
> > > Additionally, address calculations for memory after the "channels" array
> > > need to be calculated from the allocation base ("request") rather than
> > > via the first "out of bounds" index of "channels", otherwise run-time
> > > bounds checking will throw a warning.
> > >
> > > Reported-by: Nathan Chancellor <nathan@kernel.org>
> > > Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by")
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> >
> > Tested-by: Nathan Chancellor <nathan@kernel.org>
> >
>
> How do you get this tested? We have the same, and more, bugs in
> cfg80211_scan_6ghz() which I'm fixing right now, but no idea how to
> actually get the checks done?
You'll need a toolchain with __counted_by support, which I believe is
only clang 18+ at this point (I have prebuilts available at [1]), and
CONFIG_UBSAN_BOUNDS enabled, then they should just pop up in dmesg.
[1]: https://mirrors.edge.kernel.org/pub/tools/llvm/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/6] s390: Unify IUCV device allocation
@ 2024-05-07 14:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-07 14:33 UTC (permalink / raw)
To: Heiko Carstens
Cc: Arnd Bergmann, Thomas Huth, Alexandra Winter, Thorsten Winkler,
Andrew Morton, Jiri Slaby, Greg Kroah-Hartman, linux-kernel,
linux-s390, Vasily Gorbik, Alexander Gordeev, netdev, llvm,
patches, Sven Schnelle, Christian Borntraeger
On Tue, May 07, 2024 at 02:32:20PM +0200, Heiko Carstens wrote:
> On Mon, May 06, 2024 at 09:44:48PM +0200, Heiko Carstens wrote:
> > Unify IUCV device allocation as suggested by Arnd Bergmann in order
> > to get rid of code duplication in various device drivers.
> >
> > This also removes various warnings caused by
> > -Wcast-function-type-strict as reported by Nathan Lynch.
> ^^^^^^^^^^^^
>
> Ahem :)
>
> This should have been Nathan Chancellor, of course. Sorry for this!
Heh, at least you got it right on the patches :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/3] soc: ti: knav_qmss_queue: do device_node auto cleanup
@ 2024-05-13 6:44 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-13 6:44 UTC (permalink / raw)
To: Kousik Sanagavarapu
Cc: kernel test robot, Nishanth Menon, Santosh Shilimkar,
Julia Lawall, llvm, oe-kbuild-all, Shuah Khan, Javier Carrasco,
linux-kernel, linux-arm-kernel
On Sun, May 12, 2024 at 03:56:22PM +0530, Kousik Sanagavarapu wrote:
> On Sat, May 11, 2024 at 06:12:39PM +0800, kernel test robot wrote:
> > Hi Kousik,
> >
> > kernel test robot noticed the following build errors:
> >
>
> [...]
>
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/soc/ti/knav_qmss_queue.c:1853:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1840:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1835:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1831:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1822:4: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1818:4: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1810:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1806:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1795:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1801:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *qmgrs __free(device_node) =
> > ^
> > 9 errors generated.
>
> Seems like gcc didn't catch this when I compiled locally.
FWIW, you may notice this as you do more conversions. The fact that GCC
does not warn at all is a GCC bug as far as I am aware (i.e., clang's
error is correct):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
which has come up in other places:
https://lore.kernel.org/20240425174732.GA270911@dev-arch.thelio-3990X/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/3] soc: ti: knav_qmss_queue: do device_node auto cleanup
@ 2024-05-13 6:44 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-13 6:44 UTC (permalink / raw)
To: Kousik Sanagavarapu
Cc: kernel test robot, Nishanth Menon, Santosh Shilimkar,
Julia Lawall, llvm, oe-kbuild-all, Shuah Khan, Javier Carrasco,
linux-kernel, linux-arm-kernel
On Sun, May 12, 2024 at 03:56:22PM +0530, Kousik Sanagavarapu wrote:
> On Sat, May 11, 2024 at 06:12:39PM +0800, kernel test robot wrote:
> > Hi Kousik,
> >
> > kernel test robot noticed the following build errors:
> >
>
> [...]
>
> > All errors (new ones prefixed by >>):
> >
> > >> drivers/soc/ti/knav_qmss_queue.c:1853:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1840:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1835:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1831:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1822:4: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1818:4: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1810:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1806:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1795:3: error: cannot jump from this goto statement to its label
> > goto err;
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1855:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *regions __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1826:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *queue_pools __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1813:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *pdsps __free(device_node) =
> > ^
> > drivers/soc/ti/knav_qmss_queue.c:1801:22: note: jump bypasses initialization of variable with __attribute__((cleanup))
> > struct device_node *qmgrs __free(device_node) =
> > ^
> > 9 errors generated.
>
> Seems like gcc didn't catch this when I compiled locally.
FWIW, you may notice this as you do more conversions. The fact that GCC
does not warn at all is a GCC bug as far as I am aware (i.e., clang's
error is correct):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91951
which has come up in other places:
https://lore.kernel.org/20240425174732.GA270911@dev-arch.thelio-3990X/
Cheers,
Nathan
_______________________________________________
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: [PULL 18/19] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event
@ 2024-05-13 15:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-13 15:19 UTC (permalink / raw)
To: Michael Roth; +Cc: Paolo Bonzini, kvm, linux-kernel, Sean Christopherson, llvm
Hi Michael,
On Fri, May 10, 2024 at 04:10:23PM -0500, Michael Roth wrote:
> Version 2 of GHCB specification added support for the SNP Extended Guest
> Request Message NAE event. This event serves a nearly identical purpose
> to the previously-added SNP_GUEST_REQUEST event, but allows for
> additional certificate data to be supplied via an additional
> guest-supplied buffer to be used mainly for verifying the signature of
> an attestation report as returned by firmware.
>
> This certificate data is supplied by userspace, so unlike with
> SNP_GUEST_REQUEST events, SNP_EXTENDED_GUEST_REQUEST events are first
> forwarded to userspace via a KVM_EXIT_VMGEXIT exit structure, and then
> the firmware request is made after the certificate data has been fetched
> from userspace.
>
> Since there is a potential for race conditions where the
> userspace-supplied certificate data may be out-of-sync relative to the
> reported TCB or VLEK that firmware will use when signing attestation
> reports, a hook is also provided so that userspace can be informed once
> the attestation request is actually completed. See the updates to
> Documentation/ for more details on these aspects.
>
> Signed-off-by: Michael Roth <michael.roth@amd.com>
> Message-ID: <20240501085210.2213060-20-michael.roth@amd.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
...
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 00d29d278f6e..398266bef2ca 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
...
> +static int snp_begin_ext_guest_req(struct kvm_vcpu *vcpu)
> +{
> + int vmm_ret = SNP_GUEST_VMM_ERR_GENERIC;
> + struct vcpu_svm *svm = to_svm(vcpu);
> + unsigned long data_npages;
> + sev_ret_code fw_err;
> + gpa_t data_gpa;
> +
> + if (!sev_snp_guest(vcpu->kvm))
> + goto abort_request;
> +
> + data_gpa = vcpu->arch.regs[VCPU_REGS_RAX];
> + data_npages = vcpu->arch.regs[VCPU_REGS_RBX];
> +
> + if (!IS_ALIGNED(data_gpa, PAGE_SIZE))
> + goto abort_request;
> +
> + /*
> + * Grab the certificates from userspace so that can be bundled with
> + * attestation/guest requests.
> + */
> + vcpu->run->exit_reason = KVM_EXIT_VMGEXIT;
> + vcpu->run->vmgexit.type = KVM_USER_VMGEXIT_REQ_CERTS;
> + vcpu->run->vmgexit.req_certs.data_gpa = data_gpa;
> + vcpu->run->vmgexit.req_certs.data_npages = data_npages;
> + vcpu->run->vmgexit.req_certs.flags = 0;
> + vcpu->run->vmgexit.req_certs.status = KVM_USER_VMGEXIT_REQ_CERTS_STATUS_PENDING;
> + vcpu->arch.complete_userspace_io = snp_complete_ext_guest_req;
> +
> + return 0; /* forward request to userspace */
> +
> +abort_request:
> + ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, SNP_GUEST_ERR(vmm_ret, fw_err));
> + return 1; /* resume guest */
> +}
This patch is now in -next as commit 32fde9e18b3f ("KVM: SEV: Provide
support for SNP_EXTENDED_GUEST_REQUEST NAE event"), where it causes a
clang warning (or hard error when CONFIG_WERROR is enabled):
arch/x86/kvm/svm/sev.c:4078:67: error: variable 'fw_err' is uninitialized when used here [-Werror,-Wuninitialized]
4078 | ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, SNP_GUEST_ERR(vmm_ret, fw_err));
| ^~~~~~
include/uapi/linux/sev-guest.h:94:24: note: expanded from macro 'SNP_GUEST_ERR'
94 | SNP_GUEST_FW_ERR(fw_err))
| ^~~~~~
include/uapi/linux/sev-guest.h:92:32: note: expanded from macro 'SNP_GUEST_FW_ERR'
92 | #define SNP_GUEST_FW_ERR(x) ((x) & SNP_GUEST_FW_ERR_MASK)
| ^
arch/x86/kvm/svm/sev.c:4051:2: note: variable 'fw_err' is declared here
4051 | sev_ret_code fw_err;
| ^
1 error generated.
Seems legitimate to me. What was the intention here?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: SEV: Fix uninitialized firmware error code
@ 2024-05-15 22:02 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-15 22:02 UTC (permalink / raw)
To: Michael Roth
Cc: kvm, linux-kernel, Paolo Bonzini, linux-coco, Sean Christopherson
On Mon, May 13, 2024 at 12:27:04PM -0500, Michael Roth wrote:
> The current code triggers a clang warning due to passing back an
> uninitialized firmware return code in cases where an attestation request
> is aborted before getting sent to userspace. Since firmware has not been
> involved at this point the appropriate value is 0.
>
> Reported-by: Nathan Chancellor <nathan@kernel.org>
> Closes: https://lore.kernel.org/kvm/20240513151920.GA3061950@thelio-3990X/
> Fixes: 32fde9e18b3f ("KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event")
> Signed-off-by: Michael Roth <michael.roth@amd.com>
This obviously resolves the warning:
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
> ---
> arch/x86/kvm/svm/sev.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 57c2c8025547..59c0d89a4d52 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -4048,7 +4048,6 @@ static int snp_begin_ext_guest_req(struct kvm_vcpu *vcpu)
> int vmm_ret = SNP_GUEST_VMM_ERR_GENERIC;
> struct vcpu_svm *svm = to_svm(vcpu);
> unsigned long data_npages;
> - sev_ret_code fw_err;
> gpa_t data_gpa;
>
> if (!sev_snp_guest(vcpu->kvm))
> @@ -4075,7 +4074,7 @@ static int snp_begin_ext_guest_req(struct kvm_vcpu *vcpu)
> return 0; /* forward request to userspace */
>
> abort_request:
> - ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, SNP_GUEST_ERR(vmm_ret, fw_err));
> + ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, SNP_GUEST_ERR(vmm_ret, 0));
> return 1; /* resume guest */
> }
>
> --
> 2.25.1
>
^ permalink raw reply [relevance 99%]
* Re: clang: arch/x86/boot/printf.c:257:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
@ 2024-05-17 14:56 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-17 14:56 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, lkft-triage, clang-built-linux, Nick Desaulniers,
Anders Roxell, Dan Carpenter, Borislav Petkov, Borislav Petkov,
Ingo Molnar
Hi Naresh,
On Fri, May 17, 2024 at 01:00:25PM +0200, Naresh Kamboju wrote:
> The following x86 build failed on Linux next-20240517 tag due to following
> warnings / errors only seen with clang builds.
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> Build errors:
> ----
> arch/x86/boot/printf.c:257:3: error: unannotated fall-through between
> switch labels [-Werror,-Wimplicit-fallthrough]
> 257 | case 'u':
> | ^
> arch/x86/boot/printf.c:257:3: note: insert 'break;' to avoid fall-through
> 257 | case 'u':
> | ^
> | break;
> 1 error generated.
>
> The suspected patch,
> x86/boot: Add a fallthrough annotation
Thanks for the report, this has been addressed:
https://git.kernel.org/tip/82110ae235e0560d1f952f74f9fd991587b0e3a7
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/boot: Address clang -Wimplicit-fallthrough in vsprintf()
@ 2024-05-17 15:18 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-17 15:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: Thomas Gleixner, Ingo Molnar, Dave Hansen, x86, Bill Wendling,
Justin Stitt, linux-kernel, llvm, patches, kernel test robot,
Kees Cook
On Fri, May 17, 2024 at 11:51:10AM +0200, Borislav Petkov wrote:
> On Thu, May 16, 2024 at 07:03:41AM -0700, Nathan Chancellor wrote:
> > After enabling -Wimplicit-fallthrough for the x86 boot code, clang
> > warns:
> >
> > arch/x86/boot/printf.c:257:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
> > 257 | case 'u':
> > | ^
> >
> > Clang is a little more pedantic than GCC, which does not warn when
> > falling through to a case that is just break or return.
>
> Is anyone fixing Clang?
>
> :-P
There was a patch to make Clang match GCC's behavior a few years ago but
I think Kees made a good argument that GCC's behavior leaves potential
bugs on the table, so that was not pursued further.
https://reviews.llvm.org/D91895#2417170
It was brought up to GCC as well but they did not want to change their
behavior:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [trace:probes/for-next 17/17] kernel/kprobes.c:1141:24: error: a function declaration without a prototype is deprecated in all versions of C
@ 2024-05-17 16:40 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-17 16:40 UTC (permalink / raw)
To: Stephen Brennan
Cc: kernel test robot, llvm, oe-kbuild-all, Masami Hiramatsu (Google),
Steven Rostedt (Google)
Hi Stephen,
On Thu, May 16, 2024 at 01:50:31PM -0700, Stephen Brennan wrote:
> kernel test robot <lkp@intel.com> writes:
> >>> kernel/kprobes.c:1141:24: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
> > 1141 | void kprobe_ftrace_kill()
> > | ^
> > | void
> > 5 warnings and 1 error generated.
...
> I'm guessing that what's happening here is that Clang is categorizing
> the old-style declaration as a different function for which there was no
> prior declaration. When I add the "void" here, the clang error goes
> away.
I believe you are right.
> In any case, the warning is right, and I should have used the correct
> declaration here. The below patch will shut this up. If there's any
> possibility of improving the error message clang gives us here, it would
> be appreciated though.
I think Aaron Ballman, one of the clang code owners, commented on this
exact situation recently, in the larger context of addressing some of
the wording issues with this warning if I am understanding that issue
correctly:
https://github.com/llvm/llvm-project/issues/90596#issuecomment-2096081580
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kunit: tool: Build compile_commands.json
@ 2024-05-17 18:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2024-05-17 18:32 UTC (permalink / raw)
To: Brendan Jackman
Cc: Brendan Higgins, David Gow, Rae Moar, Nick Desaulniers,
Bill Wendling, Justin Stitt, linux-kselftest, kunit-dev,
linux-kernel, llvm
Hi Brendan,
On Thu, May 16, 2024 at 07:40:53PM +0000, Brendan Jackman wrote:
> compile_commands.json is used by clangd[1] to provide code navigation
> and completion functionality to editors. See [2] for an example
> configuration that includes this functionality for VSCode.
>
> It can currently be built manually when using kunit.py, by running:
>
> ./scripts/clang-tools/gen_compile_commands.py -d .kunit
>
> With this change however, it's built automatically so you don't need to
> manually keep it up to date.
>
> Unlike the manual approach, having make build the compile_commands.json
> means that it appears in the build output tree instead of at the root of
> the source tree, so you'll need to add --compile-commands-dir=.kunit to
> your clangd args for it to be found. This might turn out to be pretty
> annoying, I'm not sure yet. If so maybe we can later add some hackery to
> kunit.py to work around it.
>
> [1] https://clangd.llvm.org/
> [2] https://github.com/FlorentRevest/linux-kernel-vscode
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
This makes sense to do automatically in my opinion, as Python will
already be available (which is the only dependency of
gen_compile_commands.py as far as I am aware) and it should not take
that long to generate.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> tools/testing/kunit/kunit_kernel.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py
> index 7254c110ff23..61931c4926fd 100644
> --- a/tools/testing/kunit/kunit_kernel.py
> +++ b/tools/testing/kunit/kunit_kernel.py
> @@ -72,7 +72,8 @@ class LinuxSourceTreeOperations:
> raise ConfigError(e.output.decode())
>
> def make(self, jobs: int, build_dir: str, make_options: Optional[List[str]]) -> None:
> - command = ['make', 'ARCH=' + self._linux_arch, 'O=' + build_dir, '--jobs=' + str(jobs)]
> + command = ['make', 'all', 'compile_commands.json', 'ARCH=' + self._linux_arch,
> + 'O=' + build_dir, '--jobs=' + str(jobs)]
> if make_options:
> command.extend(make_options)
> if self._cross_compile:
>
> ---
> base-commit: 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4
> change-id: 20240516-kunit-compile-commands-d994074fc2be
>
> Best regards,
> --
> Brendan Jackman <jackmanb@google.com>
>
>
^ permalink raw reply [relevance 99%]
Results 1-200 of ~3000 next [<= 99%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2024-04-05 19:31 99% [PATCH] powerpc: Fix fatal warnings flag for LLVM's integrated assembler Nathan Chancellor
2024-03-20 22:11 99% New meeting link Nathan Chancellor
2024-02-08 0:28 99% Prebuilt LLVM 18.1.0-rc2 uploaded Nathan Chancellor
2024-02-10 16:36 ` Miguel Ojeda
2024-02-12 23:48 99% ` Nathan Chancellor
2024-02-13 2:53 99% ` Nathan Chancellor
2024-02-13 20:37 ` Miguel Ojeda
2024-02-27 12:32 ` Miguel Ojeda
2024-02-27 15:37 99% ` Nathan Chancellor
2024-02-27 16:51 ` Miguel Ojeda
2024-02-27 21:56 99% ` Nathan Chancellor
2024-02-28 18:43 99% ` Nathan Chancellor
2024-03-18 15:18 99% [PATCH 0/2] clk: qcom: Fix two driver Kconfig dependencies Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 1/2] clk: qcom: Fix SC_CAMCC_8280XP dependencies Nathan Chancellor
2024-03-18 15:18 99% ` [PATCH 2/2] clk: qcom: Fix SM_GPUCC_8650 dependencies Nathan Chancellor
2024-02-28 1:45 99% Please apply commit 5b750b22530fe53bf7fd6a30baacd53ada26911b to linux-6.1.y Nathan Chancellor
2024-04-17 17:12 99% Prebuilt LLVM 18.1.4 uploaded Nathan Chancellor
[not found] <20240421171119.1444407-1-sashal@kernel.org>
2024-04-22 18:54 ` 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-01-31 17:44 99% LLVM 18 -> 19 transition missing from apt.llvm.org unstable Nathan Chancellor
2024-04-17 15:22 99% tools/testing/selftests/clone3/clone3_set_tid.c appears to always pass? Nathan Chancellor
2024-03-21 20:18 99% [PATCH] lkdtm/bugs: Improve warning message for compilers without counted_by support Nathan Chancellor
2024-04-04 18:46 99% Prebuilt LLVM 18.1.3 Nathan Chancellor
2023-12-13 0:03 99% Apply b8ec60e1186cdcfce41e7db4c827cb107e459002 to linux-6.6.y Nathan Chancellor
[not found] <2024021953-shrimp-trilogy-590a@gregkh>
2024-02-19 19:23 99% ` Patch "um: Fix adding '-no-pie' for clang" has been added to the 6.1-stable tree Nathan Chancellor
2024-03-20 15:50 99% Prebuilt LLVM 18.1.2 uploaded Nathan Chancellor
2024-02-25 19:47 99% Please apply 56778b49c9a2cbc32c6b0fbd3ba1a9d64192d3af to linux-6.7.y Nathan Chancellor
2024-03-15 14:26 99% Prebuilt LLVM 18.1.1 uploaded Nathan Chancellor
2024-01-30 14:57 99% Prebuilt LLVM 18.1.0-rc1 uploaded Nathan Chancellor
2024-02-21 19:36 99% Prebuilt LLVM 18.1.0-rc3 uploaded Nathan Chancellor
[not found] <2024021932-overpass-stinger-b897@gregkh>
2024-02-19 19:04 99% ` Patch "modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS" has been added to the 6.6-stable tree Nathan Chancellor
2024-02-28 18:46 99% Prebuilt LLVM 18.1.0-rc4 uploaded Nathan Chancellor
2023-12-22 18:27 99% [PATCH 0/2] platform/x86/intel/pmc: Fix recent instances of -Wmissing-prototypes Nathan Chancellor
2024-05-02 15:24 99% Prebuilt LLVM 18.1.5 uploaded Nathan Chancellor
2024-04-24 18:19 99% [PATCH 0/2] drm/amd/display: Use frame_warn_flag consistently in dml2 Makefile Nathan Chancellor
2023-12-22 18:06 99% [PATCH 0/2] dmaengine: xilinx: xdma: Fix two clang warnings Nathan Chancellor
2023-12-22 18:06 99% ` Nathan Chancellor
[not found] <2024021939-dullness-calculate-a293@gregkh>
2024-02-19 19:28 99% ` Patch "um: Fix adding '-no-pie' for clang" has been added to the 5.15-stable tree Nathan Chancellor
2024-03-07 0:08 99% Prebuilt LLVM 18.1.0 uploaded 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
2023-12-15 12:47 [PATCH] docs: rust: remove `CC=clang` mentions Miguel Ojeda
2023-12-18 16:55 99% ` Nathan Chancellor
2023-12-11 12:16 [PATCH v3] docs: rust: Add rusttest info Dirk Behme
2023-12-12 3:12 ` John Hubbard
2023-12-12 12:43 ` Miguel Ojeda
2023-12-12 18:11 99% ` Nathan Chancellor
2024-01-11 12:11 [PATCH 1/1] Fix a wrong value passed to __find_vmap_area() Uladzislau Rezki (Sony)
2024-01-11 15:55 99% ` Nathan Chancellor
2024-04-09 17:17 [PATCH] kbuild: buildtar: Add arm support Calvin Owens
2024-04-10 17:04 ` Nathan Chancellor
2024-04-10 22:56 ` Calvin Owens
2024-04-12 19:23 ` Calvin Owens
2024-04-12 21:47 99% ` Nathan Chancellor
2024-04-12 19:26 ` [PATCH v2] kbuild: buildtar: Add explicit 32-bit " Calvin Owens
2024-04-12 21:48 99% ` Nathan Chancellor
2024-02-16 20:26 [PATCH] [RFC] xfrm: work around a clang-19 fortifiy-string false-positive Arnd Bergmann
2024-02-16 20:42 99% ` Nathan Chancellor
2024-02-16 21:19 ` Kees Cook
2024-04-08 7:06 ` Arnd Bergmann
2024-04-09 16:15 99% ` Nathan Chancellor
2024-01-29 13:50 [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope Baoquan He
2024-02-03 0:17 99% ` Nathan Chancellor
2024-02-03 0:17 99% ` Nathan Chancellor
2024-02-03 0:17 99% ` Nathan Chancellor
2024-02-03 0:17 99% ` Nathan Chancellor
2024-05-01 2:08 [PATCH] selftests/harness: fix many "format string is empty" warnings John Hubbard
2024-05-01 15:13 99% ` Nathan Chancellor
2024-05-06 19:44 [PATCH 0/6] s390: Unify IUCV device allocation Heiko Carstens
2024-05-07 12:32 ` Heiko Carstens
2024-05-07 14:33 99% ` Nathan Chancellor
2024-05-17 11:00 clang: arch/x86/boot/printf.c:257:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] Naresh Kamboju
2024-05-17 14:56 99% ` Nathan Chancellor
2024-03-14 7:54 [PATCH-next] arm: fix clang build warning in include/asm/memory.h Yipeng Zou
2024-03-15 0:43 99% ` Nathan Chancellor
2024-03-19 3:16 ` Yipeng Zou
2024-03-19 3:38 ` Yipeng Zou
2024-03-19 14:46 99% ` Nathan Chancellor
2024-04-24 22:40 [PATCH v2] ubsan: Avoid i386 UBSAN handler crashes with Clang Kees Cook
2024-04-26 17:38 99% ` Nathan Chancellor
2023-12-16 19:28 [drm-xe:drm-xe-next 989/1016] drivers/gpu/drm/xe/xe_wait_user_fence.c:46:2: warning: variable 'passed' is used uninitialized whenever switch default is taken kernel test robot
2023-12-18 18:57 99% ` 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-27 18:07 [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS Nathan Chancellor
2024-03-05 22:43 99% ` 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-03-06 16:48 99% ` Nathan Chancellor
2024-05-16 19:40 [PATCH] kunit: tool: Build compile_commands.json Brendan Jackman
2024-05-17 18:32 99% ` Nathan Chancellor
2024-03-26 14:47 [PATCH 00/12] kbuild: enable some -Wextra warnings by default Arnd Bergmann
2024-03-26 14:51 ` [PATCH 05/12] firmware: dmi-id: add a release callback function Arnd Bergmann
2024-03-29 12:49 ` Jean Delvare
2024-03-29 16:12 99% ` Nathan Chancellor
2024-03-13 0:13 [PATCH] ssb: use "break" on default case to prevent warning Randy Dunlap
2024-03-13 15:32 99% ` Nathan Chancellor
2024-01-25 20:20 [Linaro-TCWG-CI] llvmorg-19-init-59-g90ba33099cbb: Failure on aarch64 ci_notify
2024-01-25 23:00 99% ` Nathan Chancellor
2024-03-29 4:27 [akpm-mm:mm-nonmm-unstable 53/62] lib/raid6/recov_neon_inner.c:7:10: fatal error: 'arm_neon.h' file not found kernel test robot
2024-03-29 15:20 99% ` Nathan Chancellor
2024-04-22 15:46 [PATCH] kbuild: buildtar: remove warning for the default case Masahiro Yamada
2024-04-22 20:45 99% ` Nathan Chancellor
2024-01-30 11:27 [PATCH] crypto: virtio/akcipher - Fix stack overflow on memcpy zhenwei pi
2024-01-31 19:10 99% ` Nathan Chancellor
2024-05-02 9:24 [PATCH v5 1/2] lib/test_bitops: Add benchmark test for fns() Kuan-Wei Chiu
2024-05-03 0:49 ` kernel test robot
2024-05-03 1:34 ` Kuan-Wei Chiu
2024-05-03 4:17 ` Nathan Chancellor
2024-05-03 7:31 ` Kuan-Wei Chiu
2024-05-03 7:38 ` Kuan-Wei Chiu
2024-05-03 15:54 99% ` Nathan Chancellor
2024-05-03 21:55 ` Yury Norov
2024-05-03 22:23 99% ` Nathan Chancellor
2024-05-05 10:42 ` Miguel Ojeda
2024-05-06 17:52 99% ` Nathan Chancellor
2024-05-06 18:08 ` Miguel Ojeda
2024-05-06 22:47 ` Yury Norov
2024-05-07 14:19 99% ` Nathan Chancellor
2024-05-05 10:42 ` Miguel Ojeda
2024-05-06 17:56 99% ` Nathan Chancellor
2024-03-18 15:30 [GIT PULL v2] tracing: Updates for v6.9 Steven Rostedt
2024-03-19 16:23 ` Linus Torvalds
2024-03-19 17:06 ` Steven Rostedt
2024-03-19 17:13 ` Steven Rostedt
2024-03-19 21:03 ` Nathan Chancellor
2024-03-19 21:22 ` Linus Torvalds
2024-03-19 21:27 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
2024-04-24 15:53 [RFC PATCH 0/9] kexec x86 purgatory cleanup Ard Biesheuvel
2024-04-24 15:53 ` [RFC PATCH 2/9] x86/purgatory: Simplify stack handling Ard Biesheuvel
2024-04-24 18:26 99% ` Nathan Chancellor
2024-04-24 18:26 99% ` Nathan Chancellor
2024-04-26 21:32 ` Justin Stitt
2024-04-26 21:53 99% ` Nathan Chancellor
2024-04-26 21:53 99% ` 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-02-12 14:53 [PATCH] kbuild: Use -fmin-function-alignment when available Petr Pavlu
2024-02-13 0:27 99% ` Nathan Chancellor
2024-01-10 14:55 drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1833:4: warning: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94 kernel test robot
2024-01-12 19:47 99% ` Nathan Chancellor
2024-03-07 11:02 Migration to Debian Bookworm and compiler updates for KernelCI Denys Fedoryshchenko
2024-03-07 17:05 99% ` Nathan Chancellor
2024-03-11 19:10 ` Guillaume Tucker
2024-03-13 17:56 99% ` Nathan Chancellor
2024-03-01 11:21 [PATCH] kbuild: fix inconsistent indentation in top Makefile Masahiro Yamada
2024-03-01 22:16 99% ` Nathan Chancellor
2024-03-21 1:35 [PATCH v2] arm: fix clang build warning in include/asm/memory.h Yipeng Zou
2024-03-26 23:55 99% ` Nathan Chancellor
2024-03-21 11:58 [PATCH] scripts/package: buildtar: Output as vmlinuz for riscv Matt Coster
2024-03-21 15:43 99% ` Nathan Chancellor
2024-03-21 15:43 99% ` Nathan Chancellor
2024-03-06 12:47 [PATCH] kbuild: remove GCC's default -Wpacked-bitfield-compat flag Masahiro Yamada
2024-03-06 16:49 99% ` Nathan Chancellor
2023-12-12 21:46 [PATCH] power: reset: at91: mark at91_wakeup_status non-__init Arnd Bergmann
2023-12-12 21:50 99% ` Nathan Chancellor
2023-12-12 21:50 99% ` Nathan Chancellor
2024-01-29 11:43 CBL issue 1984 - AMD64 segfault during LTO building linux-6.7.0 with clang-17.0.6 Sedat Dilek
2024-01-29 20:35 99% ` Nathan Chancellor
2024-04-15 18:28 [PATCH] ubsan: Add awareness of signed integer overflow traps Kees Cook
2024-04-15 18:34 99% ` Nathan Chancellor
2024-01-15 20:43 [GIT PULL] power-supply changes for 6.8 Sebastian Reichel
2024-01-17 18:00 99% ` Nathan Chancellor
2024-01-08 3:31 [PATCH] scripts/min-tool-version.sh: Raise min clang version to 18.0.0 for loongarch WANG Rui
2024-01-08 16:37 99% ` Nathan Chancellor
2024-04-09 14:22 [PATCH] drm/msm/gen_header: allow skipping the validation Dmitry Baryshkov
2024-05-03 16:48 99% ` Nathan Chancellor
2024-04-17 15:37 [PATCH] selftests: Make ksft_exit functions return void instead of int Nathan Chancellor
2024-04-24 13:44 ` Shuah Khan
2024-04-24 15:05 99% ` Nathan Chancellor
2024-04-24 16:00 ` Shuah Khan
2024-04-24 16:10 99% ` Nathan Chancellor
2024-03-12 15:30 [PATCH] tracing: Use strcmp() in __assign_str() WARN_ON() check Steven Rostedt
2024-03-13 16:59 99% ` Nathan Chancellor
2024-01-13 17:40 [akpm-mm:mm-nonmm-unstable 22/23] lib/group_cpus.c:352:16: error: array initializer must be an initializer list kernel test robot
2024-01-16 22:55 99% ` Nathan Chancellor
2024-02-28 14:47 [Linaro-TCWG-CI] llvmorg-19-init-3481-g8c2ae42b3e1c: Failure on aarch64 ci_notify
2024-02-28 17:05 99% ` Nathan Chancellor
2023-12-25 18:52 [PATCH] scripts/decode_stacktrace.sh: Support LLVM addr2line Bjorn Andersson
2023-12-26 16:38 99% ` Nathan Chancellor
2024-04-23 14:15 [PATCH rdma-next 1/1] RDMA/mana_ib: fix missing ret value Konstantin Taranov
2024-04-23 15:03 ` Jason Gunthorpe
2024-04-26 16:53 ` Andy Shevchenko
2024-04-26 16:58 99% ` Nathan Chancellor
2024-05-16 14:03 [PATCH] x86/boot: Address clang -Wimplicit-fallthrough in vsprintf() Nathan Chancellor
2024-05-17 9:51 ` Borislav Petkov
2024-05-17 15:18 99% ` Nathan Chancellor
2024-02-28 13:46 [PATCH] power: supply: move power_supply_attr_group into #ifdef block Ricardo B. Marliere
2024-02-28 17:10 99% ` Nathan Chancellor
2024-01-22 3:48 [PATCH v2 2/4] modpost: inform compilers that fatal() never returns Aiden Leong
2024-01-22 13:29 ` Masahiro Yamada
2024-01-22 23:02 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 ` Nathan Chancellor
2024-01-26 21:01 ` Guenter Roeck
2024-01-26 22:35 ` Nathan Chancellor
2024-01-26 23:55 ` Guenter Roeck
2024-01-27 0:03 99% ` Nathan Chancellor
2024-01-25 22:55 [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1 Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 11/11] compiler-clang.h: Update __diag_clang() macros for minimum version bump Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 10/11] lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV Nathan Chancellor
2024-01-25 22:55 99% ` [PATCH 09/11] fortify: Drop Clang version check for 12.0.1 or newer Nathan Chancellor
2024-01-25 22:55 ` [PATCH 05/11] arm64: Kconfig: Clean up tautological LLVM version checks Nathan Chancellor
2024-01-26 12:59 ` Mark Rutland
2024-01-26 16:10 99% ` Nathan Chancellor
2024-01-26 16:10 99% ` Nathan Chancellor
2024-01-12 12:58 [PATCH] docs: kbuild/kconfig: reformat/cleanup Vegard Nossum
2024-01-12 19:43 99% ` Nathan Chancellor
2024-02-05 19:49 [PATCH] wifi: ath12k: Fix uninitialized use of ret in ath12k_mac_allocate() Nathan Chancellor
2024-02-07 15:08 ` Kalle Valo
2024-02-21 18:00 99% ` Nathan Chancellor
2024-03-21 13:02 [GIT PULL] Char/Misc driver changes for 6.9-rc1 Greg KH
2024-03-21 13:48 99% ` Nathan Chancellor
2024-02-15 15:16 [PATCH v2] kbuild: Use -fmin-function-alignment when available Petr Pavlu
2024-02-17 0:07 99% ` Nathan Chancellor
2024-01-25 17:05 [PATCHSET v3 wq/for-6.9] workqueue: Implement system-wide max_active for unbound workqueues Tejun Heo
2024-01-25 17:06 ` [PATCH 09/10] workqueue: Implement system-wide nr_active enforcement " Tejun Heo
2024-01-29 16:00 ` Lai Jiangshan
2024-01-29 18:14 ` [PATCH v4 " Tejun Heo
[not found] ` <CGME20240130223021eucas1p1172b060d53847b8b77f6455d6257528e@eucas1p1.samsung.com>
2024-01-30 22:30 ` Marek Szyprowski
2024-01-31 4:02 ` Tejun Heo
2024-01-31 4:12 99% ` Nathan Chancellor
2024-01-31 4:13 ` Tejun Heo
2024-01-31 4:20 ` Nathan Chancellor
2024-01-31 4:24 ` Tejun Heo
2024-01-31 4:42 99% ` Nathan Chancellor
2024-02-05 15:48 [PATCH 0/2] Compiler Attributes, s390: Provide and use __uninitialized macro Heiko Carstens
2024-02-05 15:48 ` [PATCH 1/2] Compiler Attributes: Add " Heiko Carstens
2024-02-06 1:28 99% ` Nathan Chancellor
2024-02-05 15:48 ` [PATCH 2/2] s390/fpu: make use of " Heiko Carstens
2024-02-06 1:31 99% ` Nathan Chancellor
2024-01-12 0:40 [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-18 17:24 [GIT PULL]: dmaengine updates for v6.8 Vinod Koul
2024-01-18 19:11 99% ` Nathan Chancellor
2024-04-10 8:42 [PATCH rdma-next v3 0/6] RDMA/mana_ib: Enable RNIC adapter and populate it with GIDs Konstantin Taranov
2024-04-10 8:42 ` [PATCH rdma-next v3 4/6] RDMA/mana_ib: enable RoCE on port 1 Konstantin Taranov
2024-04-22 19:37 99% ` Nathan Chancellor
2024-02-20 20:44 [PATCH] s390/boot: Workaround current 'llvm-objdump -t -j ...' behavior Nathan Chancellor
2024-02-21 9:16 ` Heiko Carstens
2024-02-21 16:48 99% ` Nathan Chancellor
2023-12-18 16:33 [PATCH] drm/xe: Fix warning on impossible condition Lucas De Marchi
2024-01-03 16:07 99% ` Nathan Chancellor
2024-01-03 16:07 99% ` Nathan Chancellor
2024-01-28 2:12 [PATCH 0/3] media: Fix warnings building with LLVM=1 Ricardo Ribalda
2024-01-28 2:12 ` [PATCH 2/3] media: usb: pvrusb2: Fix Wcast-function-type-strict warnings Ricardo Ribalda
2024-02-01 22:09 99% ` Nathan Chancellor
2024-02-01 22:09 99% ` Nathan Chancellor
2024-01-28 2:12 ` [PATCH 1/3] media: pci: sta2x11: " Ricardo Ribalda
2024-02-01 22:08 99% ` Nathan Chancellor
2024-02-01 22:08 99% ` Nathan Chancellor
2023-11-08 0:07 [PATCH] rpm-pkg: simplify installkernel %post Nathan Chancellor
2023-12-12 17:10 ` [PATCH v2] " Jose Ignacio Tornos Martinez
2023-12-12 19:19 99% ` Nathan Chancellor
2024-03-05 17:42 [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 ` Nathan Chancellor
2024-03-05 21:52 ` Arnd Bergmann
2024-03-05 22:14 99% ` Nathan Chancellor
2024-05-16 19:15 [trace:probes/for-next 17/17] kernel/kprobes.c:1141:24: error: a function declaration without a prototype is deprecated in all versions of C kernel test robot
2024-05-16 20:50 ` Stephen Brennan
2024-05-17 16:40 99% ` Nathan Chancellor
2024-04-16 2:35 [pdx86-platform-drivers-x86:review-hans 40/59] drivers/platform/x86/amd/pmc/mp2_stb.c:94:2: error: call to undeclared function 'writeq'; ISO C99 and later do not support implicit function declarations kernel test robot
2024-04-16 13:06 ` Andy Shevchenko
2024-04-16 15:09 99% ` Nathan Chancellor
2024-05-01 0:02 [PATCH] x86/alternatives: Make FineIBT mode Kconfig selectable Kees Cook
2024-05-01 16:33 99% ` Nathan Chancellor
2024-04-24 22:01 [PATCH] wifi: nl80211: Avoid address calculations via out of bounds array indexing Kees Cook
2024-04-25 18:13 99% ` Nathan Chancellor
2024-05-07 10:46 ` Johannes Berg
2024-05-07 14:21 99% ` 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-04-10 23:26 [PATCH 1/3] selftests: timers: Fix posix_timers ksft_print_msg warning John Stultz
2024-04-10 23:26 ` [PATCH 2/3] selftests: timers: Fix uninitialized variable warning in ksft_min_kernel_version John Stultz
2024-04-11 15:39 ` Nathan Chancellor
2024-04-11 18:11 ` John Stultz
2024-04-11 18:47 99% ` Nathan Chancellor
2024-02-27 8:52 [PATCH v3 00/24] Clean up locking with guard() in ALSA core Takashi Iwai
2024-02-27 8:52 ` [PATCH v3 05/24] ALSA: hwdep: Use guard() for locking Takashi Iwai
2024-02-29 21:00 ` Nathan Chancellor
2024-03-01 7:27 ` Takashi Iwai
2024-03-01 17:10 99% ` Nathan Chancellor
2023-12-16 2:47 [PATCH 00/50] big header dependency cleanup targeting sched.h Kent Overstreet
2023-12-16 3:26 ` [PATCH 11/50] nodemask: Split out include/linux/nodemask_types.h Kent Overstreet
2023-12-16 3:26 ` [PATCH 15/50] kernel/numa.c: Move logging out of numa.h Kent Overstreet
2023-12-19 16:36 99% ` Nathan Chancellor
2024-04-09 11:38 [PATCH] ARM: Add a memory clobber to the fmrx instruction zhuqiuer
2024-04-09 16:46 99% ` Nathan Chancellor
2024-04-09 16:46 99% ` Nathan Chancellor
2024-04-10 2:41 ` zhuqiuer
2024-04-10 2:41 ` [PATCH v2] " zhuqiuer
2024-04-10 12:31 ` Ard Biesheuvel
2024-04-10 15:35 99% ` Nathan Chancellor
2024-04-10 15:35 99% ` Nathan Chancellor
2024-05-13 17:27 [PATCH] KVM: SEV: Fix uninitialized firmware error code Michael Roth
2024-05-15 22:02 99% ` Nathan Chancellor
2024-03-09 14:24 [PATCH] kbuild: rpm-pkg: add dtb files in kernel rpm Masahiro Yamada
2024-03-11 16:22 ` [PATCH V2] " Jose Ignacio Tornos Martinez
2024-03-15 19:00 99% ` Nathan Chancellor
2024-01-08 9:57 [PATCH v4 2/4] arch/x86: Move internal setup_data structures into setup_data.h Thomas Zimmermann
2024-01-09 0:28 ` kernel test robot
2024-01-09 17:58 ` Nathan Chancellor
2024-01-11 9:50 ` Thomas Zimmermann
2024-01-11 22:41 99% ` Nathan Chancellor
2024-04-30 14:04 [PATCH] powerpc: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n Michael Ellerman
2024-05-01 16:20 99% ` Nathan Chancellor
2024-02-23 6:40 [PATCH] arm64: ftrace: Don't forbid CALL_OPS+CC_OPTIMIZE_FOR_SIZE with Clang Stephen Boyd
2024-02-25 19:54 99% ` Nathan Chancellor
2024-02-25 19:54 99% ` Nathan Chancellor
2023-12-19 13:40 [bcachefs:header_cleanup 21/51] /bin/bash: line 1: 19420 Segmentation fault LLVM_OBJCOPY="llvm-objcopy" pahole -J --btf_gen_floats -j --lang_exclude=rust --skip_encoding_btf_inconsistent_proto --btf_gen_optimized --btf_base vmlinux drivers/misc/eeprom/at24.ko kernel test robot
2023-12-19 20:53 ` Kent Overstreet
2023-12-19 20:58 ` Nick Desaulniers
2023-12-19 21:04 99% ` Nathan Chancellor
2023-12-20 7:24 ` Yujie Liu
2023-12-27 22:43 ` Nathan Chancellor
2023-12-28 14:21 ` Arnaldo Carvalho de Melo
2023-12-28 17:34 99% ` Nathan Chancellor
2024-02-27 0:54 [PATCH] thermal: core: Move initial num_trips assignment before memcpy() Nathan Chancellor
2024-02-27 10:14 ` Daniel Lezcano
2024-02-27 11:09 ` Rafael J. Wysocki
2024-02-27 15:37 ` Daniel Lezcano
2024-02-27 16:26 ` Kees Cook
2024-02-27 16:47 ` Daniel Lezcano
2024-02-27 17:00 ` Kees Cook
2024-02-28 8:41 ` Lukasz Luba
2024-02-28 16:56 99% ` Nathan Chancellor
2024-02-29 13:35 [trace:trace/for-next 28/29] include/trace/events/sunrpc.h:703:4: warning: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) kernel test robot
2024-02-29 23:06 ` Steven Rostedt
2024-02-29 23:44 99% ` Nathan Chancellor
2024-02-29 23:55 ` Steven Rostedt
2024-03-01 4:11 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-09 13:36 [PATCH] Compiler Attributes: counted_by: bump compiler versions Sergey Senozhatsky
2024-01-09 15:32 99% ` Nathan Chancellor
2024-04-26 19:27 [PATCH v3 0/2] Fix Kernel CI issues Anatoliy Klymenko
2024-04-27 7:48 ` Tomi Valkeinen
2024-05-03 16:27 99% ` Nathan Chancellor
2024-05-03 16:27 99% ` Nathan Chancellor
2024-02-27 20:34 [PATCH] power: supply: core: Fix power_supply_init_attrs() stub Nathan Chancellor
2024-02-27 20:39 ` Ricardo B. Marliere
2024-02-27 21:49 99% ` Nathan Chancellor
2024-04-18 22:01 [PATCH] drivers: remoteproc: xlnx: Add Versal and Versal-NET support Tanmay Shah
2024-04-23 16:06 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-04-26 22:29 [PATCH] hardening: Refresh KCFI options, add some more Kees Cook
2024-04-29 22:16 99% ` Nathan Chancellor
2024-04-29 22:16 99% ` Nathan Chancellor
2024-04-30 5:35 ` Kees Cook
2024-04-30 15:12 99% ` Nathan Chancellor
2024-04-30 15:12 99% ` Nathan Chancellor
2024-03-18 9:30 [PATCH] ARM: vfp: use asm volatile for FP control register accesses Ard Biesheuvel
2024-03-26 23:55 99% ` Nathan Chancellor
2024-03-27 7:05 ` Ard Biesheuvel
2024-03-27 14:41 99% ` Nathan Chancellor
2024-01-27 9:00 [PATCH] RISC-V: fix check for zvkb with tip-of-tree clang Eric Biggers
2024-01-27 19:52 99% ` Nathan Chancellor
2024-01-27 19:52 99% ` Nathan Chancellor
2024-02-02 13:35 [PATCH 1/4] kbuild: rpm-pkg: do not include depmod-generated files Masahiro Yamada
2024-02-06 1:35 99% ` Nathan Chancellor
2024-02-02 13:35 ` [PATCH 2/4] kbuild: rpm-pkg: mark installed files in /boot as %ghost Masahiro Yamada
2024-02-06 1:35 99% ` Nathan Chancellor
2023-12-17 9:44 [Intel-wired-lan] [PATCH iwl-next] i40e: Avoid unnecessary use of comma operator Simon Horman
2023-12-18 16:32 ` Nick Desaulniers
2023-12-18 19:00 99% ` Nathan Chancellor
2023-12-18 19:00 99% ` Nathan Chancellor
2024-04-15 19:31 Compile Error in Linux 6.9-rc4 with Clang 17.0.6 Memet Zx
2024-04-15 22:06 99% ` Nathan Chancellor
2024-02-28 12:04 pinctrl: single: Cannot disable bias - PIN_CONFIG_BIAS_DISABLE not handled Matthijs Kooijman
2024-02-29 7:32 ` Tony Lindgren
2024-02-29 18:31 99% ` Nathan Chancellor
2024-05-10 21:10 [PULL 00/19] KVM: Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Michael Roth
2024-05-10 21:10 ` [PULL 18/19] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event Michael Roth
2024-05-13 15:19 99% ` Nathan Chancellor
2024-01-04 22:59 [PATCH] platform/x86: intel-uncore-freq: Fix types in sysfs callbacks Nathan Chancellor
2024-01-08 7:25 ` srinivas pandruvada
2024-01-08 16:47 99% ` Nathan Chancellor
2024-02-08 0:14 [PATCH 00/11] s390: Support linking with ld.lld Nathan Chancellor
2024-02-08 0:15 99% ` [PATCH 10/11] s390: Select CONFIG_ARCH_WANT_LD_ORPHAN_WARN Nathan Chancellor
2024-02-08 0:14 ` [PATCH 03/11] s390: vmlinux.lds.S: Explicitly handle '.got' and '.plt' sections Nathan Chancellor
2024-02-13 5:31 ` Fangrui Song
2024-02-14 12:20 ` Heiko Carstens
2024-02-14 19:48 99% ` Nathan Chancellor
2024-02-08 0:14 ` [PATCH 04/11] s390: vmlinux.lds.S: Discard unnecessary sections Nathan Chancellor
2024-02-12 13:55 ` Heiko Carstens
2024-02-13 0:15 99% ` Nathan Chancellor
2024-02-09 11:20 ` [PATCH 00/11] s390: Support linking with ld.lld Heiko Carstens
2024-02-09 15:08 99% ` Nathan Chancellor
2024-05-10 7:13 [PATCH 2/3] soc: ti: knav_qmss_queue: do device_node auto cleanup Kousik Sanagavarapu
2024-05-11 10:12 ` kernel test robot
2024-05-12 10:26 ` Kousik Sanagavarapu
2024-05-13 6:44 99% ` Nathan Chancellor
2024-05-13 6:44 99% ` Nathan Chancellor
2024-04-17 18:24 [PATCH 0/3] drivers/s390: Fix instances of -Wcast-function-type-strict Nathan Chancellor
2024-04-17 18:24 ` [PATCH 1/3] s390/vmlogrdr: Remove function pointer cast Nathan Chancellor
2024-04-18 9:54 ` Heiko Carstens
2024-04-18 10:25 ` Heiko Carstens
2024-04-18 14:51 99% ` Nathan Chancellor
2024-04-18 15:15 ` Heiko Carstens
2024-04-18 15:34 99% ` Nathan Chancellor
2024-04-18 19:21 ` Heiko Carstens
2024-04-18 20:32 99% ` Nathan Chancellor
2024-01-10 2:58 [PATCHv2 1/2] Compiler Attributes: counted_by: bump min gcc version Sergey Senozhatsky
2024-01-10 3:01 99% ` Nathan Chancellor
2024-01-10 2:58 ` [PATCHv2 2/2] Compiler Attributes: counted_by: fixup clang URL Sergey Senozhatsky
2024-01-10 3:02 99% ` Nathan Chancellor
2024-04-14 6:26 [PATCH] selftests: Mark ksft_exit_fail_perror() as __noreturn Muhammad Usama Anjum
2024-04-15 15:41 99% ` Nathan Chancellor
2024-03-19 16:07 [PATCH 0/2] tracing: Fully silence instance of -Wstring-compare Nathan Chancellor
2024-03-19 22:15 ` Steven Rostedt
2024-03-19 22:27 99% ` Nathan Chancellor
2024-04-17 4:37 [PATCH 0/2] Enable building of the devel RPM package from Kbuild Pratham Patel
2024-04-17 14:48 99% ` Nathan Chancellor
2024-04-17 15:08 ` Pratham Patel
2024-04-17 15:47 99% ` Nathan Chancellor
2023-12-05 19:53 [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump Nathan Chancellor
2024-01-03 18:15 99% ` Nathan Chancellor
2024-01-03 18:18 ` Borislav Petkov
2024-01-03 20:55 99% ` Nathan Chancellor
2024-01-03 21:26 ` Borislav Petkov
2024-01-03 21:48 99% ` Nathan Chancellor
2024-01-03 21:51 99% ` Nathan Chancellor
2024-03-01 0:57 net/netfilter/nf_bpf_link.c:186:33: warning: bitwise operation between different enumeration types ('enum bpf_reg_type' and 'enum bpf_type_flag') kernel test robot
2024-03-01 3:50 99% ` Nathan Chancellor
2024-03-28 8:19 [PATCH v4 0/8] CFI for ARM32 using LLVM Linus Walleij
2024-04-12 7:38 ` Linus Walleij
2024-04-12 22:07 99% ` Nathan Chancellor
2024-04-12 22:07 99% ` Nathan Chancellor
2024-02-02 23:53 [PATCH] x86/coco: Define cc_vendor without CONFIG_ARCH_HAS_CC_PLATFORM Nathan Chancellor
2024-02-03 10:29 ` Borislav Petkov
2024-02-03 16:08 ` Nathan Chancellor
2024-02-03 19:07 ` Borislav Petkov
2024-02-03 19:35 99% ` Nathan Chancellor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.