Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping
On Mon, Aug 19, 2024 at 12:29:34PM -0700, Linus Torvalds wrote:
> On Mon, 19 Aug 2024 at 11:53, Nathan Chancellor wrote:
> >
> >
> > Modules linked in:
> > Pid: 24, comm: mount Not tainted 6.11.0-rc4-next-20240819
> > RIP: 0033:0x68006f6c
> > RSP: 6c8bfc68 EFLAGS: 00010206
> > RAX: 68006f6c RBX: 68a0aa18 RCX: 600d8b09
> > RDX: RSI: 68a0aa18 RDI: 68805120
> > RBP: 6c8bfc70 R08: 0001 R09: 68ae0308
> > R10: 000e R11: R12: 0001
> > R13: 68a0aa18 R14: 0015 R15: 68944a88
> > Kernel panic - not syncing: Segfault with no mm
> > CPU: 0 UID: 0 PID: 24 Comm: mount Not tainted 6.11.0-rc4-next-20240819 #1
> > Stack:
> > 600caeff 6c8bfc90 600d8b2a 68944a80
> > 0047 6c8bfda0 600cbfd9 6c8bfd50
> > 68944ad0 68944a88 7f7000 7f7fff
> > Call Trace:
> > [<600caeff>] ? special_mapping_close+0x16/0x19
>
> Hmm. No "Code:" line? Did you just edit that out, or maybe UML doesn't
> print one out?
Nope, no editing, it is straight from my terminal. I guess UML just doesn't
print one.
> Anyway, for me that special_mapping_close() disassembles to
>
>
> <+0>: mov%rdi,%rsi
> <+3>: mov0x78(%rdi),%rdi
> <+7>: mov0x20(%rdi),%rax
> <+11>: test %rax,%rax
> <+14>: je 0x600caa11
> <+16>: push %rbp
> <+17>: mov%rsp,%rbp
> <+20>: call *%rax
> <+22>: pop%rbp
> <+23>: ret
> <+24>: ret
>
> which may just match yours, because special_mapping_close+0x16 is
> obviously that +22, and it's the return point for that call.
Yeah seems like it, objdump -dr shows:
0027 :
27: 48 89 femov%rdi,%rsi
2a: 48 8b 7f 78 mov0x78(%rdi),%rdi
2e: 48 8b 47 20 mov0x20(%rdi),%rax
32: 48 85 c0test %rax,%rax
35: 74 08 je 3f
37: 55 push %rbp
38: 48 89 e5mov%rsp,%rbp
3b: ff d0 call *%rax
3d: 5d pop%rbp
3e: c3 ret
3f: c3 ret
> And your %rax value does match that invalid %rip value of 0x68006f6c.
>
> So it does look like it's jumping off to la-la-land, and the problem is the
> code
>
> const struct vm_special_mapping *sm = vma->vm_private_data;
>
> if (sm->close)
> sm->close(sm, vma);
>
> where presumably 'vm_private_data' isn't a "struct vm_special_mapping *" at
> all.
>
> And I think I see the problem.
>
> When we have that 'legacy_special_mapping_vmops', then the
> vm_private_data field actually points to 'pages'.
>
> So the 'legacy_special_mapping_vmops' can *only* contain the '.fault'
> handler, not the other handlers.
>
> IOW, does something like this fix it?
>
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2095,7 +2095,6 @@ static const struct vm_operations_struct
> special_mapping_vmops = {
>};
>
>static const struct vm_operations_struct legacy_special_mapping_vmops = {
> - .close = special_mapping_close,
> .fault = special_mapping_fault,
>};
Yes, that appears to fix it for me. I don't have much to say about the
rest but others might :)
Cheers,
Nathan
Re: [PATCH v2 1/4] mm: Add optional close() to struct vm_special_mapping
Hi Michael,
On Mon, Aug 12, 2024 at 06:26:02PM +1000, Michael Ellerman wrote:
> Add an optional close() callback to struct vm_special_mapping. It will
> be used, by powerpc at least, to handle unmapping of the VDSO.
>
> Although support for unmapping the VDSO was initially added
> for CRIU[1], it is not desirable to guard that support behind
> CONFIG_CHECKPOINT_RESTORE.
>
> There are other known users of unmapping the VDSO which are not related
> to CRIU, eg. Valgrind [2] and void-ship [3].
>
> The powerpc arch_unmap() hook has been in place for ~9 years, with no
> ifdef, so there may be other unknown users that have come to rely on
> unmapping the VDSO. Even if the code was behind an ifdef, major distros
> enable CHECKPOINT_RESTORE so users may not realise unmapping the VDSO
> depends on that configuration option.
>
> It's also undesirable to have such core mm behaviour behind a relatively
> obscure CONFIG option.
>
> Longer term the unmap behaviour should be standardised across
> architectures, however that is complicated by the fact the VDSO pointer
> is stored differently across architectures. There was a previous attempt
> to unify that handling [4], which could be revived.
>
> See [5] for further discussion.
>
> [1]: commit 83d3f0e90c6c ("powerpc/mm: tracking vDSO remap")
> [2]:
> https://sourceware.org/git/?p=valgrind.git;a=commit;h=3a004915a2cbdcdebafc1612427576bf3321eef5
> [3]: https://github.com/insanitybit/void-ship
> [4]: https://lore.kernel.org/lkml/20210611180242.711399-17-d...@arista.com/
> [5]:
> https://lore.kernel.org/linuxppc-dev/shiq5v3jrmyi6ncwke7wgl76ojysgbhrchsk32q4lbx2hadqqc@kzyy2igem256
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Michael Ellerman
> Reviewed-by: David Hildenbrand
> ---
> include/linux/mm_types.h | 3 +++
> mm/mmap.c| 6 ++
> 2 files changed, 9 insertions(+)
>
> v2:
> - Add some blank lines as requested.
> - Expand special_mapping_close() comment.
> - Add David's reviewed-by.
> - Expand change log to capture review discussion.
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 485424979254..78bdfc59abe5 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1313,6 +1313,9 @@ struct vm_special_mapping {
>
> int (*mremap)(const struct vm_special_mapping *sm,
>struct vm_area_struct *new_vma);
> +
> + void (*close)(const struct vm_special_mapping *sm,
> + struct vm_area_struct *vma);
> };
>
> enum tlb_flush_reason {
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d0dfc85b209b..af4dbf0d3bd4 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3620,10 +3620,16 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t
> flags, long npages)
> static vm_fault_t special_mapping_fault(struct vm_fault *vmf);
>
> /*
> + * Close hook, called for unmap() and on the old vma for mremap().
> + *
> * Having a close hook prevents vma merging regardless of flags.
> */
> static void special_mapping_close(struct vm_area_struct *vma)
> {
> + const struct vm_special_mapping *sm = vma->vm_private_data;
> +
> + if (sm->close)
> + sm->close(sm, vma);
> }
>
> static const char *special_mapping_name(struct vm_area_struct *vma)
> --
> 2.45.2
>
This change is now in -next and I bisected a crash that our CI sees with
ARCH=um to it:
$ make -skj"$(nproc)" ARCH=um CROSS_COMPILE=x86_64-linux- defconfig linux
$ ./linux ubd0=$PWD/rootfs.ext4
...
Linux version 6.11.0-rc4-next-20240819 (nathan@thelio-3990X) (x86_64-linux-gcc
(GCC) 14.2.0, GNU ld (GNU Binutils) 2.42) #1 Mon Aug 19 11:42:20 MST 2024
...
Run /sbin/init as init process
Modules linked in:
Pid: 24, comm: mount Not tainted 6.11.0-rc4-next-20240819
RIP: 0033:0x68006f6c
RSP: 6c8bfc68 EFLAGS: 00010206
RAX: 68006f6c RBX: 68a0aa18 RCX: 600d8b09
RDX: RSI: 68a0aa18 RDI: 68805120
RBP: 6c8bfc70 R08: 0001 R09: 68ae0308
R10: 000e R11: R12: 0001
R13: 68a0aa18 R14: 0015 R15: 68944a88
Kernel panic - not syncing: Segfault with no mm
CPU: 0 UID: 0 PID: 24 Comm: mount Not tainted 6.11.0-rc4-next-20240819 #1
Stack:
600caeff 6c8bfc90 600d8b2a 68944a80
0047 6c8bfda0 600cbfd9 6c8bfd50
68944ad0 68944a88 7f7000 7f7fff
Call Trace:
[<600caeff>] ? special_mapping_close+0x16/0x19
[<600d8b2a>] remove_vma+0x21/0x59
[<600cbfd9>] exit_mmap+0x1f3/0x2bc
[<60032a0c>] ? unblock_signals+0x0/0xbd
[<600329fd>] ? block_signals+0x0/0xf
[<6003831c>] __mmput+0x24/0x94
[<60067262>] ? up_read+0x0/0x2c
[<600383a1>] mmput+0x15/0x18
[<6003ce97>] do_exit+0x381/0x9b8
[<600e4b8d>] ? kfree+0x107/0x11b
[<6003d752>] sys_exit_group+0x0/0x16
[<6003d768>] pid_child_should_wake+0x0/0x42
[<60022e7a>] handle_syscall+0x79/0xa7
[<600358de>] userspace+0x4d3/0x505
[<60020927>] fork_handler+0x84/0x8b
Passing this through scripts/decode_stackt
Re: [PATCH v3 2/3] dma-mapping: replace zone_dma_bits by zone_dma_limit
On Thu, Aug 01, 2024 at 03:44:54PM +0200, Christoph Hellwig wrote: > On Wed, Jul 31, 2024 at 06:24:24PM -0700, Nathan Chancellor wrote: > > Unfortunately, I am not sure either... I do not see anything obviously, > > so perhaps it could just be avoided with the __diag() infrastructure? > > > > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > > index 3dbc0b89d6fb..b58e7eb9c8f1 100644 > > --- a/kernel/dma/direct.c > > +++ b/kernel/dma/direct.c > > @@ -20,7 +20,12 @@ > > * it for entirely different regions. In that case the arch code needs to > > * override the variable below for dma-direct to work properly. > > */ > > +__diag_push(); > > +__diag_ignore(clang, 13, "-Wconstant-conversion", > > + "Clang incorrectly thinks the n == 64 case in DMA_BIT_MASK() can > > happen here," > > + "which would truncate with a 32-bit phys_addr_t"); > > phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24); > > So.. The code above is clearly wrong, as DMA_BIT_MASK always returns a > u64, and phys_addr_t can be smaller than that. So at least in this case > the warning seems perfectly valid and the code has issues because it is > mixing different concepts. Sure, that seems like a reasonable way to look at things even if the warning itself is a false positive. > Where do you see warnings like this upstream? I don't see this upstream, this is from patch 2 of this series: https://lore.kernel.org/053fa4806a2c63efcde80caca473a8b670a2701c.1722249878.git.bar...@tkos.co.il/ Cheers, Nathan
Re: [PATCH v3 2/3] dma-mapping: replace zone_dma_bits by zone_dma_limit
On Tue, Jul 30, 2024 at 05:34:50PM +0200, Christoph Hellwig wrote: > On Mon, Jul 29, 2024 at 07:12:08PM -0700, Nathan Chancellor wrote: > > > | ~~ ^~~~ > > >include/linux/dma-mapping.h:77:40: note: expanded from macro > > > 'DMA_BIT_MASK' > > > 77 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) > > > |^ > > >2 warnings generated. > > > > FWIW, this is likely a false positive due to an issue in Clang with the > > control flow graph for global variables: > > > > https://github.com/ClangBuiltLinux/linux/issues/92 > > > > DMA_BIT_MASK() has been the biggest offender :/ If there is any way to > > refactor this code to avoid this, that would be great (as that has been > > one of our longest outstanding issues and getting it fixed in the > > compiler does not seem super easy at this point). > > I have no idea what you'd want changed here, but I'll happily take > patches. Unfortunately, I am not sure either... I do not see anything obviously, so perhaps it could just be avoided with the __diag() infrastructure? diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 3dbc0b89d6fb..b58e7eb9c8f1 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -20,7 +20,12 @@ * it for entirely different regions. In that case the arch code needs to * override the variable below for dma-direct to work properly. */ +__diag_push(); +__diag_ignore(clang, 13, "-Wconstant-conversion", + "Clang incorrectly thinks the n == 64 case in DMA_BIT_MASK() can happen here," + "which would truncate with a 32-bit phys_addr_t"); phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24); +__diag_pop(); static inline dma_addr_t phys_to_dma_direct(struct device *dev, phys_addr_t phys)
Re: [PATCH v3 2/3] dma-mapping: replace zone_dma_bits by zone_dma_limit
On Tue, Jul 30, 2024 at 04:20:51AM +0800, kernel test robot wrote:
> Hi Baruch,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on powerpc/next powerpc/fixes s390/features
> linus/master v6.11-rc1 next-20240729]
> [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/Baruch-Siach/dma-mapping-improve-DMA-zone-selection/20240729-211018
> base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> for-next/core
> patch link:
> https://lore.kernel.org/r/053fa4806a2c63efcde80caca473a8b670a2701c.1722249878.git.baruch%40tkos.co.il
> patch subject: [PATCH v3 2/3] dma-mapping: replace zone_dma_bits by
> zone_dma_limit
> config: arm-allnoconfig
> (https://download.01.org/0day-ci/archive/20240730/202407300338.oauo6jtb-...@intel.com/config)
> compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project
> ccae7b461be339e717d02f99ac857cf0bc7d17fc)
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240730/202407300338.oauo6jtb-...@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
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202407300338.oauo6jtb-...@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>In file included from kernel/dma/direct.c:7:
>In file included from include/linux/memblock.h:12:
>In file included from include/linux/mm.h:2253:
>include/linux/vmstat.h:514:36: warning: arithmetic between different
> enumeration types ('enum node_stat_item' and 'enum lru_list')
> [-Wenum-enum-conversion]
> 514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
> | ~~~ ^ ~~~
> >> kernel/dma/direct.c:23:46: warning: implicit conversion from 'unsigned
> >> long long' to 'phys_addr_t' (aka 'unsigned int') changes value from
> >> 18446744073709551615 to 4294967295 [-Wconstant-conversion]
> 23 | phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
> | ~~ ^~~~
>include/linux/dma-mapping.h:77:40: note: expanded from macro 'DMA_BIT_MASK'
> 77 | #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> |^
>2 warnings generated.
FWIW, this is likely a false positive due to an issue in Clang with the
control flow graph for global variables:
https://github.com/ClangBuiltLinux/linux/issues/92
DMA_BIT_MASK() has been the biggest offender :/ If there is any way to
refactor this code to avoid this, that would be great (as that has been
one of our longest outstanding issues and getting it fixed in the
compiler does not seem super easy at this point).
Cheers,
Nathan
> vim +23 kernel/dma/direct.c
>
>> 7#include
> 8#include
> 9#include
> 10#include
> 11#include
> 12#include
> 13#include
> 14#include
> 15#include
> 16#include "direct.h"
> 17
> 18/*
> 19 * Most architectures use ZONE_DMA for the first 16 Megabytes,
> but some use
> 20 * it for entirely different regions. In that case the arch
> code needs to
> 21 * override the variable below for dma-direct to work properly.
> 22 */
> > 23phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
> 24
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
[PATCH] ASoC: fsl: lpc3xxx-i2s: Include bitfield.h for FIELD_PREP
bitfield.h is not explicitly included but it is required for FIELD_PREP
to be expanded by the preprocessor. If it is not implicitly included,
there will be a compiler error (as seen with ARCH=hexagon allmodconfig):
sound/soc/fsl/lpc3xxx-i2s.c:169:10: error: call to undeclared function
'FIELD_PREP'; ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
169 | tmp |= LPC3XXX_I2S_WW8 |
LPC3XXX_I2S_WS_HP(LPC3XXX_I2S_WW8_HP);
|^
sound/soc/fsl/lpc3xxx-i2s.h:42:30: note: expanded from macro 'LPC3XXX_I2S_WW8'
42 | #define LPC3XXX_I2S_WW8 FIELD_PREP(0x3, 0) /* Word width is 8bit
*/
| ^
sound/soc/fsl/lpc3xxx-i2s.c:205:34: error: call to undeclared function
'FIELD_PREP'; ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
205 | LPC3XXX_I2S_DMA1_TX_EN |
LPC3XXX_I2S_DMA0_TX_DEPTH(4));
| ^
sound/soc/fsl/lpc3xxx-i2s.h:65:38: note: expanded from macro
'LPC3XXX_I2S_DMA0_TX_DEPTH'
65 | #define LPC3XXX_I2S_DMA0_TX_DEPTH(s) FIELD_PREP(0xF, s) /* Set
the DMA1 TX Request level */
| ^
sound/soc/fsl/lpc3xxx-i2s.c:210:34: error: call to undeclared function
'FIELD_PREP'; ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
210 | LPC3XXX_I2S_DMA0_RX_EN |
LPC3XXX_I2S_DMA1_RX_DEPTH(4));
| ^
sound/soc/fsl/lpc3xxx-i2s.h:70:38: note: expanded from macro
'LPC3XXX_I2S_DMA1_RX_DEPTH'
70 | #define LPC3XXX_I2S_DMA1_RX_DEPTH(s) FIELD_PREP(0x700, s) /* Set the
DMA1 RX Request level */
| ^
Include bitfield.h explicitly, so that FIELD_PREP is always expanded,
clearing up the compiler error.
Fixes: 0959de657a10 ("ASoC: fsl: Add i2s and pcm drivers for LPC32xx CPUs")
Signed-off-by: Nathan Chancellor
---
sound/soc/fsl/lpc3xxx-i2s.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/lpc3xxx-i2s.h b/sound/soc/fsl/lpc3xxx-i2s.h
index eec755448478..b6657853017a 100644
--- a/sound/soc/fsl/lpc3xxx-i2s.h
+++ b/sound/soc/fsl/lpc3xxx-i2s.h
@@ -9,6 +9,7 @@
#ifndef __SOUND_SOC_LPC3XXX_I2S_H
#define __SOUND_SOC_LPC3XXX_I2S_H
+#include
#include
#include
---
base-commit: 55f0a1fa6ea4e339c797e9a3292ca0caa4ab3885
change-id: 20240701-lpc32xx-asoc-fix-include-for-field_prep-140db845a209
Best regards,
--
Nathan Chancellor
[PATCH] ASoC: fsl: lpc3xxx-i2s: Avoid using ret uninitialized in lpc32xx_i2s_probe()
clang points out that ret may be used uninitialized in
lpc32xx_i2s_probe() in an error pointer path (which becomes fatal with
CONFIG_WERROR):
sound/soc/fsl/lpc3xxx-i2s.c:326:47: error: variable 'ret' is uninitialized
when used here [-Werror,-Wuninitialized]
326 | "failed to init register map:
%d\n", ret);
|
^~~
sound/soc/fsl/lpc3xxx-i2s.c:310:9: note: initialize the variable 'ret' to
silence this warning
310 | int ret;
|^
| = 0
1 error generated.
One solution would be a small refactoring of the second parameter in
dev_err_probe(), PTR_ERR(i2s_info_p->regs), to be the value of ret in
the if statement. However, a nicer solution for debugging purposes,
which is the point of this statement, would be to use the '%pe'
specifier to symbolically print the error pointer value. Do so, which
eliminates the uninitialized use of ret, clearing up the warning.
Fixes: 0959de657a10 ("ASoC: fsl: Add i2s and pcm drivers for LPC32xx CPUs")
Signed-off-by: Nathan Chancellor
---
sound/soc/fsl/lpc3xxx-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/lpc3xxx-i2s.c b/sound/soc/fsl/lpc3xxx-i2s.c
index 0e5b4d5202ff..af995ca081a3 100644
--- a/sound/soc/fsl/lpc3xxx-i2s.c
+++ b/sound/soc/fsl/lpc3xxx-i2s.c
@@ -323,7 +323,7 @@ static int lpc32xx_i2s_probe(struct platform_device *pdev)
i2s_info_p->regs = devm_regmap_init_mmio(dev, iomem,
&lpc32xx_i2s_regconfig);
if (IS_ERR(i2s_info_p->regs))
return dev_err_probe(dev, PTR_ERR(i2s_info_p->regs),
-"failed to init register map: %d\n", ret);
+"failed to init register map: %pe\n",
i2s_info_p->regs);
i2s_info_p->clk = devm_clk_get(dev, NULL);
if (IS_ERR(i2s_info_p->clk))
---
base-commit: 878f4c36f9235e8a15fe0c2ecde066d92c50c8ff
change-id: 20240701-lpc32xx-asoc-fix-uninitialized-ret-4700d6d556c1
Best regards,
--
Nathan Chancellor
Re: [PATCH] powerpc: vdso: fix building with wrong-endian toolchain
On Fri, Jun 07, 2024 at 04:11:25PM +0200, Arnd Bergmann wrote:
> This patch seems to work as well for me, and is a little
> more logical, but it's also more invasive and has a
> higher regression risk:
Commit feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS")
did something similar for clang for the same reason, so I would say it
is worth pursuing this direction. It also avoids including KBUILD_CFLAGS
twice when generating .i files.
Cheers,
Nathan
> 8<-
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 65261cbe5bfd..9ad4ca318e34 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -62,14 +62,14 @@ KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> endif
>
> ifdef CONFIG_CPU_LITTLE_ENDIAN
> -KBUILD_CFLAGS += -mlittle-endian
> +KBUILD_CPPFLAGS+= -mlittle-endian
> KBUILD_LDFLAGS += -EL
> LDEMULATION:= lppc
> GNUTARGET := powerpcle
> MULTIPLEWORD := -mno-multiple
> KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
> else
> -KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
> +KBUILD_CPPFLAGS += $(call cc-option,-mbig-endian)
> KBUILD_LDFLAGS += -EB
> LDEMULATION:= ppc
> GNUTARGET := powerpc
> @@ -95,7 +95,7 @@ aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call
> cc-option,-mbig-endian)
> aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
>
> ifeq ($(HAS_BIARCH),y)
> -KBUILD_CFLAGS += -m$(BITS)
> +KBUILD_CPPFLAGS+= -m$(BITS)
> KBUILD_AFLAGS += -m$(BITS)
> KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
> endif
> @@ -176,7 +176,6 @@ KBUILD_CPPFLAGS += -I $(srctree)/arch/powerpc
> $(asinstr)
> KBUILD_AFLAGS += $(AFLAGS-y)
> KBUILD_CFLAGS += $(call cc-option,-msoft-float)
> KBUILD_CFLAGS += $(CFLAGS-y)
> -CPP= $(CC) -E $(KBUILD_CFLAGS)
>
> CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
> ifdef CONFIG_CPU_BIG_ENDIAN
> diff --git a/arch/powerpc/kernel/vdso/Makefile
> b/arch/powerpc/kernel/vdso/Makefile
> index 1b93655c2857..3516e71926e5 100644
> --- a/arch/powerpc/kernel/vdso/Makefile
> +++ b/arch/powerpc/kernel/vdso/Makefile
> @@ -59,7 +59,7 @@ ldflags-$(CONFIG_LD_IS_LLD) += $(call
> cc-option,--ld-path=$(LD),-fuse-ld=lld)
> ldflags-$(CONFIG_LD_ORPHAN_WARN) +=
> -Wl,--orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
>
> # Filter flags that clang will warn are unused for linking
> -ldflags-y += $(filter-out $(CC_AUTO_VAR_INIT_ZERO_ENABLER)
> $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CFLAGS))
> +ldflags-y += $(filter-out $(CC_AUTO_VAR_INIT_ZERO_ENABLER)
> $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
>
> CC32FLAGS := -m32
> LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
> ->8
>
> Arnd
Re: [PATCH] powerpc: Set _IO_BASE to POISON_POINTER_DELTA not 0 for CONFIG_PCI=n
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 > Closes: > https://lore.kernel.org/all/CA+G9fYtEh8zmq8k8wE-8RZwW-Qr927RLTn+KqGnq1F=ptaa...@mail.gmail.com > Signed-off-by: Michael Ellerman > --- > 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_BASE0 > #define PCI_DRAM_OFFSET 0 > #elif defined(CONFIG_PPC32) > -- > 2.44.0 >
Re: [RFC PATCH 2/2] objtool/powerpc: Enhance objtool to fixup alternate feature relative addresses
Hi Sathvika, On Mon, Apr 22, 2024 at 02:52:06PM +0530, Sathvika Vasireddy wrote: > Implement build-time fixup of alternate feature relative addresses for > the out-of-line (else) patch code. Initial posting to achieve the same > using another tool can be found at [1]. Idea is to implement this using > objtool instead of introducing another tool since it already has elf > parsing and processing covered. > > Introduce --ftr-fixup as an option to objtool to do feature fixup at > build-time. > > Couple of issues and warnings encountered while implementing feature > fixup using objtool are as follows: > > 1. libelf is creating corrupted vmlinux file after writing necessary > changes to the file. Due to this, kexec is not able to load new > kernel. > > It gives the following error: > ELF Note corrupted ! > Cannot determine the file type of vmlinux > > To fix this issue, after opening vmlinux file, make a call to > elf_flagelf (e, ELF_C_SET, ELF_F_LAYOUT). This instructs libelf not > to touch the segment and section layout. It informs the library > that the application will take responsibility for the layout of the > file and that the library should not insert any padding between > sections. > > 2. Fix can't find starting instruction warnings when run on vmlinux > > Objtool throws a lot of can't find starting instruction warnings > when run on vmlinux with --ftr-fixup option. > > These warnings are seen because find_insn() function looks for > instructions at offsets that are relative to the start of the section. > In case of individual object files (.o), there are no can't find > starting instruction warnings seen because the actual offset > associated with an instruction is itself a relative offset since the > sections start at offset 0x0. > > However, in case of vmlinux, find_insn() function fails to find > instructions at the actual offset associated with an instruction > since the sections in vmlinux do not start at offset 0x0. Due to > this, find_insn() will look for absolute offset and not the relative > offset. This is resulting in a lot of can't find starting instruction > warnings when objtool is run on vmlinux. > > To fix this, pass offset that is relative to the start of the section > to find_insn(). > > find_insn() is also looking for symbols of size 0. But, objtool does > not store empty STT_NOTYPE symbols in the rbtree. Due to this, > for empty symbols, objtool is throwing can't find starting > instruction warnings. Fix this by ignoring symbols that are of > size 0 since objtool does not add them to the rbtree. > > 3. Objtool is throwing unannotated intra-function call warnings > when run on vmlinux with --ftr-fixup option. > > One such example: > > vmlinux: warning: objtool: .text+0x3d94: > unannotated intra-function call > > .text + 0x3d94 = c0008000 + 3d94 = c00081d4 > > c00081d4: 45 24 02 48 bl c002a618 > > > c002a610 : > c002a610: 0e 01 4c 3c addis r2,r12,270 > c002a610: R_PPC64_REL16_HA.TOC. > c002a614: f0 6c 42 38 addir2,r2,27888 > c002a614: R_PPC64_REL16_LO.TOC.+0x4 > c002a618: a6 02 08 7c mflrr0 > > This is happening because we should be looking for destination > symbols that are at absolute offsets instead of relative offsets. > After fixing dest_off to point to absolute offset, there are still > a lot of these warnings shown. > > In the above example, objtool is computing the destination > offset to be c002a618, which points to a completely > different instruction. find_call_destination() is looking for this > offset and failing. Instead, we should be looking for destination > offset c002a610 which points to system_reset_exception > function. > > Even after fixing the way destination offset is computed, and > after looking for dest_off - 0x8 in cases where the original offset > is not found, there are still a lot of unannotated intra-function > call warnings generated. This is due to symbols that are not > properly annotated. > > So, for now, as a hack to curb these warnings, do not emit > unannotated intra-function call warnings when objtool is run > with --ftr-fixup option. > > TODO: > This patch enables build time feature fixup only for powerpc little > endian configs. There are boot failures with big endian configs. > Posting this as an initial RFC to get some review comments while I work > on big endian issues. > > [1] > https://lore.kernel.org/linuxppc-dev/20170521010130.13552-1-npig...@gmail.com/ > > Co-developed-by: Nicholas Piggin > Signed-off-by: Nicholas Piggin > Signed-off-by: Sathvika Vasireddy When I build this series with LLVM 14 [1] (due to an issue I report below), I am getting a crash when CONFIG_FTR_FIXUP_SELFTEST is disabled. diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defc
[PATCH] powerpc: Fix fatal warnings flag for LLVM's integrated assembler
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
---
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
Re: [PATCH v4 05/13] mm/arch: Provide pud_pfn() fallback
Hi Peter (and LoongArch folks),
On Wed, Mar 27, 2024 at 11:23:24AM -0400, pet...@redhat.com wrote:
> From: Peter Xu
>
> The comment in the code explains the reasons. We took a different approach
> comparing to pmd_pfn() by providing a fallback function.
>
> Another option is to provide some lower level config options (compare to
> HUGETLB_PAGE or THP) to identify which layer an arch can support for such
> huge mappings. However that can be an overkill.
>
> Cc: Mike Rapoport (IBM)
> Cc: Matthew Wilcox
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
> ---
> arch/riscv/include/asm/pgtable.h| 1 +
> arch/s390/include/asm/pgtable.h | 1 +
> arch/sparc/include/asm/pgtable_64.h | 1 +
> arch/x86/include/asm/pgtable.h | 1 +
> include/linux/pgtable.h | 10 ++
> 5 files changed, 14 insertions(+)
>
> diff --git a/arch/riscv/include/asm/pgtable.h
> b/arch/riscv/include/asm/pgtable.h
> index 20242402fc11..0ca28cc8e3fa 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -646,6 +646,7 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
>
> #define __pud_to_phys(pud) (__page_val_to_pfn(pud_val(pud)) << PAGE_SHIFT)
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> return ((__pud_to_phys(pud) & PUD_MASK) >> PAGE_SHIFT);
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 1a71cb19c089..6cbbe473f680 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -1414,6 +1414,7 @@ static inline unsigned long pud_deref(pud_t pud)
> return (unsigned long)__va(pud_val(pud) & origin_mask);
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> return __pa(pud_deref(pud)) >> PAGE_SHIFT;
> diff --git a/arch/sparc/include/asm/pgtable_64.h
> b/arch/sparc/include/asm/pgtable_64.h
> index 4d1bafaba942..26efc9bb644a 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -875,6 +875,7 @@ static inline bool pud_leaf(pud_t pud)
> return pte_val(pte) & _PAGE_PMD_HUGE;
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> pte_t pte = __pte(pud_val(pud));
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index cefc7a84f7a4..273f7557218c 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -234,6 +234,7 @@ static inline unsigned long pmd_pfn(pmd_t pmd)
> return (pfn & pmd_pfn_mask(pmd)) >> PAGE_SHIFT;
> }
>
> +#define pud_pfn pud_pfn
> static inline unsigned long pud_pfn(pud_t pud)
> {
> phys_addr_t pfn = pud_val(pud);
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 600e17d03659..75fe309a4e10 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1817,6 +1817,16 @@ typedef unsigned int pgtbl_mod_mask;
> #define pte_leaf_size(x) PAGE_SIZE
> #endif
>
> +/*
> + * We always define pmd_pfn for all archs as it's used in lots of generic
> + * code. Now it happens too for pud_pfn (and can happen for larger
> + * mappings too in the future; we're not there yet). Instead of defining
> + * it for all archs (like pmd_pfn), provide a fallback.
> + */
> +#ifndef pud_pfn
> +#define pud_pfn(x) ({ BUILD_BUG(); 0; })
> +#endif
> +
> /*
> * Some architectures have MMUs that are configurable or selectable at boot
> * time. These lead to variable PTRS_PER_x. For statically allocated arrays
> it
> --
> 2.44.0
>
This BUILD_BUG() triggers for LoongArch with their defconfig, so it
seems like they need to provide an implementation of pud_pfn()?
In function 'follow_huge_pud',
inlined from 'follow_pud_mask' at mm/gup.c:1075:10,
inlined from 'follow_p4d_mask' at mm/gup.c:1105:9,
inlined from 'follow_page_mask' at mm/gup.c:1151:10:
include/linux/compiler_types.h:460:45: error: call to
'__compiletime_assert_382' declared with attribute error: BUILD_BUG failed
460 | _compiletime_assert(condition, msg, __compiletime_assert_,
__COUNTER__)
| ^
include/linux/compiler_types.h:441:25: note: in definition of macro
'__compiletime_assert'
441 | prefix ## suffix();
\
| ^~
include/linux/compiler_types.h:460:9: note: in expansion of macro
'_compiletime_assert'
460 | _compiletime_assert(condition, msg, __compiletime_assert_,
__COUNTER__)
| ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/build_bug.h:59:21: note: in expansion of macro
'BUILD_BUG_ON_MSG'
59 | #
Re: FAILED: Patch "powerpc: xor_vmx: Add '-mhard-float' to CFLAGS" failed to apply to 5.10-stable tree
On Wed, Mar 27, 2024 at 08:20:07AM -0400, Sasha Levin wrote: > The patch below does not apply to the 5.10-stable tree. > If someone wants it applied there, or to any other stable or longterm > tree, then please email the backport, including the original git commit > id to . ... > -- original commit in Linus's tree -- > > From 35f20786c481d5ced9283ff42de5c69b65e5ed13 Mon Sep 17 00:00:00 2001 > From: Nathan Chancellor > Date: Sat, 27 Jan 2024 11:07:43 -0700 > Subject: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS I have attached a backport that will work for 5.15 and earlier. I think you worked around this conflict in 5.15 by taking 04e85bbf71c9 but I am not sure that is a smart idea. I think it might just be better to drop that dependency and apply this version in 5.15. Cheers, Nathan >From c6cb80d94871cbb4ff151f7eb2586cadeb364ef7 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor Date: Sat, 27 Jan 2024 11:07:43 -0700 Subject: [PATCH 4.19 to 5.15] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS commit 35f20786c481d5ced9283ff42de5c69b65e5ed13 upstream. arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an error when building with clang after a recent change in main: error: option '-msoft-float' cannot be specified with '-maltivec' make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1 Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS to override the previous inclusion of '-msoft-float' (as the last option wins), which matches how other areas of the kernel use '-maltivec', such as AMDGPU. Cc: sta...@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 Signed-off-by: Michael Ellerman Link: https://msgid.link/20240127-ppc-xor_vmx-drop-msoft-float-v1-1-f24140e81...@kernel.org [nathan: Fixed conflicts due to lack of 04e85bbf71c9 in older trees] Signed-off-by: Nathan Chancellor --- arch/powerpc/lib/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 321cab5c3ea0..bd5012aa94e3 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -67,6 +67,6 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o obj-$(CONFIG_ALTIVEC) += xor_vmx.o xor_vmx_glue.o -CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec) +CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec) obj-$(CONFIG_PPC64) += $(obj64-y) -- 2.44.0
Re: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
On Wed, Mar 06, 2024 at 12:01:42PM +1100, Michael Ellerman wrote: > Nathan Chancellor 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: sta...@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 > >> --- > >> 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 > >> 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 > >> >
Re: [PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
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: sta...@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 > --- > 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 > 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 >
Re: [PATCH linux-next 1/3] x86, crash: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope
This series resolves the build issues I was seeing. Please feel free to
carry
Tested-by: Nathan Chancellor # 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/sn6pr02mb4157931105fa68d72e3d3db8d4...@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
> ---
> 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
>
[PATCH] powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
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: sta...@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 --- 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 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
[PATCH 5.4] powerpc: Use always instead of always-y in for crtsavres.o
This commit is for linux-5.4.y only, it has no direct upstream
equivalent.
Prior to commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to
hostprogs/always-y"), always-y did not exist, making the backport of
mainline commit 1b1e38002648 ("powerpc: add crtsavres.o to always-y
instead of extra-y") to linux-5.4.y as commit 245da9eebba0 ("powerpc:
add crtsavres.o to always-y instead of extra-y") incorrect, breaking the
build with linkers that need crtsavres.o:
ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or
directory
Backporting the aforementioned kbuild commit is not suitable for stable
due to its size and number of conflicts, so transform the always-y usage
to an equivalent form using always, which resolves the build issues.
Fixes: 245da9eebba0 ("powerpc: add crtsavres.o to always-y instead of extra-y")
Signed-off-by: Nathan Chancellor
---
arch/powerpc/lib/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 7c603839fe28..841e6ed30f13 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -34,8 +34,8 @@ obj-$(CONFIG_FUNCTION_ERROR_INJECTION)+=
error-inject.o
# 64-bit linker creates .sfpr on demand for final link (vmlinux),
# so it is only needed for modules, and only for older linkers which
# do not support --save-restore-funcs
-ifeq ($(call ld-ifversion, -lt, 22500, y),y)
-always-$(CONFIG_PPC64) += crtsavres.o
+ifeq ($(call ld-ifversion, -lt, 22500, y)$(CONFIG_PPC64),yy)
+always += crtsavres.o
endif
obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \
---
base-commit: f0602893f43a54097fcf22bd8c2f7b8e75ca643e
change-id: 20240126-5-4-fix-lib-powerpc-backport-9d577643dcfc
Best regards,
--
Nathan Chancellor
[PATCH 4.19] powerpc: Use always instead of always-y in for crtsavres.o
This commit is for linux-4.19.y only, it has no direct upstream
equivalent.
Prior to commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to
hostprogs/always-y"), always-y did not exist, making the backport of
mainline commit 1b1e38002648 ("powerpc: add crtsavres.o to always-y
instead of extra-y") to linux-4.19.y as commit b7b85ec5ec15 ("powerpc:
add crtsavres.o to always-y instead of extra-y") incorrect, breaking the
build with linkers that need crtsavres.o:
ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or
directory
Backporting the aforementioned kbuild commit is not suitable for stable
due to its size and number of conflicts, so transform the always-y usage
to an equivalent form using always, which resolves the build issues.
Fixes: b7b85ec5ec15 ("powerpc: add crtsavres.o to always-y instead of extra-y")
Signed-off-by: Nathan Chancellor
---
arch/powerpc/lib/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 6f1e57182876..f0aa6fc8c6b2 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -21,8 +21,8 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o crtsavres.o
strlen_32.o
# 64-bit linker creates .sfpr on demand for final link (vmlinux),
# so it is only needed for modules, and only for older linkers which
# do not support --save-restore-funcs
-ifeq ($(call ld-ifversion, -lt, 22500, y),y)
-always-$(CONFIG_PPC64) += crtsavres.o
+ifeq ($(call ld-ifversion, -lt, 22500, y)$(CONFIG_PPC64),yy)
+always += crtsavres.o
endif
obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \
---
base-commit: b060cfd3f707ad3c8ae8322e1b149ba7e2cf33e0
change-id: 20240126-4-19-fix-lib-powerpc-backport-6f4a823adf1a
Best regards,
--
Nathan Chancellor
Re: [PATCH linux-next v3 00/14] Split crash out from kexec and clean up related config items
Hi Baoquan, On Wed, Jan 24, 2024 at 01:12:40PM +0800, Baoquan He wrote: > Motivation: > = > Previously, LKP reported a building error. When investigating, it can't > be resolved reasonablly with the present messy kdump config items. > > https://lore.kernel.org/oe-kbuild-all/202312182200.ka7mzifq-...@intel.com/ > > The kdump (crash dumping) related config items could causes confusions: > > Firstly, > --- > CRASH_CORE enables codes including > - crashkernel reservation; > - elfcorehdr updating; > - vmcoreinfo exporting; > - crash hotplug handling; > > Now fadump of powerpc, kcore dynamic debugging and kdump all selects > CRASH_CORE, while fadump > - fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing >global variable 'elfcorehdr_addr'; > - kcore only needs vmcoreinfo exporting; > - kdump needs all of the current kernel/crash_core.c. > > So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this > mislead people that we enable crash dumping, actual it's not. > > Secondly, > --- > It's not reasonable to allow KEXEC_CORE select CRASH_CORE. > > Because KEXEC_CORE enables codes which allocate control pages, copy > kexec/kdump segments, and prepare for switching. These codes are > shared by both kexec reboot and kdump. We could want kexec reboot, > but disable kdump. In that case, CRASH_CORE should not be selected. > > > CONFIG_CRASH_CORE=y > CONFIG_KEXEC_CORE=y > CONFIG_KEXEC=y > CONFIG_KEXEC_FILE=y > - > > Thirdly, > --- > It's not reasonable to allow CRASH_DUMP select KEXEC_CORE. > > That could make KEXEC_CORE, CRASH_DUMP are enabled independently from > KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE > code built in doesn't make any sense because no kernel loading or > switching will happen to utilize the KEXEC_CORE code. > - > CONFIG_CRASH_CORE=y > CONFIG_KEXEC_CORE=y > CONFIG_CRASH_DUMP=y > - > > In this case, what is worse, on arch sh and arm, KEXEC relies on MMU, > while CRASH_DUMP can still be enabled when !MMU, then compiling error is > seen as the lkp test robot reported in above link. > > --arch/sh/Kconfig-- > config ARCH_SUPPORTS_KEXEC > def_bool MMU > > config ARCH_SUPPORTS_CRASH_DUMP > def_bool BROKEN_ON_SMP > --- > > Changes: > === > 1, split out crash_reserve.c from crash_core.c; > 2, split out vmcore_infoc. from crash_core.c; > 3, move crash related codes in kexec_core.c into crash_core.c; > 4, remove dependency of FA_DUMP on CRASH_DUMP; > 5, clean up kdump related config items; > 6, wrap up crash codes in crash related ifdefs on all 8 arch-es >which support crash dumping, except of ppc; > > Achievement: > === > With above changes, I can rearrange the config item logic as below (the right > item depends on or is selected by the left item): > > PROC_KCORE ---> VMCORE_INFO > >|--> VMCORE_INFO > FA_DUMP| >|--> CRASH_RESERVE > > >VMCORE_INFO >/ >|>CRASH_RESERVE > KEXEC --|/| > |--> KEXEC_CORE--> CRASH_DUMP-->/-|>PROC_VMCORE > KEXEC_FILE --| \ | >\>CRASH_HOTPLUG > > > KEXEC --| > |--> KEXEC_CORE (for kexec reboot only) > KEXEC_FILE --| > > Test > > On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips, > riscv, loongarch, I did below three cases of config item setting and > building all passed. Take configs on x86_64 as exampmle here: > > (1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump > items are unset automatically: > # Kexec and crash features > # CONFIG_KEXEC is not set > # CONFIG_KEXEC_FILE is not set > # end of Kexec and crash features > > (2) set CONFIG_KEXEC_FILE and 'make olddefconfig': > --- > # Kexec and crash features > CONFIG_CRASH_RESERVE=y > CONFIG_VMCORE_INFO=y > CONFIG_KEXEC_CORE=y > CONFIG_KEXEC_FILE=y > CONFIG_CRASH_DUMP=y > CONFIG_CRASH_HOTPLUG=y > CONFIG_CRASH_MAX_MEMORY_RANGES=8192 > # end of Kexec and crash features > --- > > (3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig': > > # Kexec and crash features > CONFIG_KEXEC_CORE=y > CONFIG_KEXEC_FILE=y > # end of Kexec and crash features > > > Note: > For ppc, it needs investigation to make clear how to split out crash > code in arch folder. Hope Hari and Pingfan can help have a look, see if > it's doable. Now, I make it either have both kexec and crash enabled, or > disable both of them altogether. I am seeing a few build failur
[PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
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
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: aneesh.ku...@kernel.org
Cc: naveen.n@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 >= 12
default y if !CPU_LITTLE_ENDIAN
select ARCH_WANT_OLD_COMPAT_IPC
select COMPAT_OLD_SIGACTION
--
2.43.0
[PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
Hi all, This series bumps the minimum supported version of LLVM for building the kernel to 13.0.1. The first patch does the bump and all subsequent patches clean up all the various workarounds and checks for earlier versions. Quoting the first patch's commit message for those that were only on CC for the clean ups: When __builtin_mul_overflow() has arguments that differ in terms of signedness and width, LLVM may generate a libcall to __muloti4 because it performs the checks in terms of 65-bit multiplication. This issue becomes harder to hit (but still possible) after LLVM 12.0.0, which includes a special case for matching widths but different signs. To gain access to this special case, which the kernel can take advantage of when calls to __muloti4 appear, bump the minimum supported version of LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there is minimal impact to distribution support while allowing a few more workarounds to be dropped in the kernel source than if 12.0.0 were chosen. Looking at container images of up to date distribution versions: archlinux:latest clang version 16.0.6 debian:oldoldstable-slim clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final) debian:oldstable-slim Debian clang version 11.0.1-2 debian:stable-slimDebian clang version 14.0.6 debian:testing-slim Debian clang version 16.0.6 (19) debian:unstable-slim Debian clang version 16.0.6 (19) fedora:38 clang version 16.0.6 (Fedora 16.0.6-3.fc38) fedora:latest clang version 17.0.6 (Fedora 17.0.6-1.fc39) fedora:rawhideclang version 17.0.6 (Fedora 17.0.6-1.fc40) opensuse/leap:latest clang version 15.0.7 opensuse/tumbleweed:latestclang version 17.0.6 ubuntu:focal clang version 10.0.0-4ubuntu1 ubuntu:latest Ubuntu clang version 14.0.0-1ubuntu1.1 ubuntu:rollingUbuntu clang version 16.0.6 (15) ubuntu:devel Ubuntu clang version 17.0.6 (3) The only distribution that gets left behind is Debian Bullseye, as the default version is 11.0.1; other distributions either have a newer version than 13.0.1 or one older than the current minimum of 11.0.0. Debian has easy access to more recent LLVM versions through apt.llvm.org, so this is not as much of a concern. There are also the kernel.org LLVM toolchains, which should work with distributions with glibc 2.28 and newer. Another benefit of slimming up the number of supported versions of LLVM for building the kernel is reducing the build capacity needed to support a matrix that builds with each supported version, which allows a matrix to reallocate the freed up build capacity towards something else, such as more configuration combinations. This passes my build matrix with all supported versions. This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts with my series to update the LLVM links across the repository [1] but I can easily rebase it to linux-kbuild if Masahiro would rather these patches go through there (and defer the conflict resolution to the merge window). [1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db...@kernel.org/ --- Nathan Chancellor (11): kbuild: Raise the minimum supported version of LLVM to 13.0.1 Makefile: Drop warn-stack-size plugin opt x86: Drop stack-alignment plugin opt ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang arm64: Kconfig: Clean up tautological LLVM version checks powerpc: Kconfig: Remove tautology in CONFIG_COMPAT riscv: Remove MCOUNT_NAME workaround riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE fortify: Drop Clang version check for 12.0.1 or newer lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV compiler-clang.h: Update __diag_clang() macros for minimum version bump Documentation/process/changes.rst | 2 +- Makefile | 8 arch/arm/include/asm/current.h| 8 +--- arch/arm64/Kconfig| 5 + arch/powerpc/Kconfig | 1 - arch/riscv/Kconfig| 2 -- arch/riscv/include/asm/ftrace.h | 14 ++ arch/riscv/kernel/mcount.S| 10 +- arch/x86/Makefile | 6 -- include/linux/compiler-clang.h| 8 ++-- lib/Kconfig.debug | 2 +- scripts/min-tool-version.sh | 2 +- scripts/recordmcount.pl | 2 +- security/Kconfig | 2 -- 14 files changed, 15 insertions(+), 57 deletions(-) --- base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19 Best regards, -- Nathan Chancellor
Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
Hi Alexei,
On Thu, Jan 11, 2024 at 12:00:50PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor wrote:
> >
> > Hi Yonghong,
> >
> > On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> > >
> > > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > > has been abandoned in favor of GitHub pull requests. While the majority
> > > > of links in the kernel sources still work because of the work Fangrui
> > > > has done turning the dynamic Phabricator instance into a static archive,
> > > > there are some issues with that work, so preemptively convert all the
> > > > links in the kernel sources to point to the commit on GitHub.
> > > >
> > > > Most of the commits have the corresponding differential review link in
> > > > the commit message itself so there should not be any loss of fidelity in
> > > > the relevant information.
> > > >
> > > > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > > > in the area.
> > > >
> > > > Link:
> > > > https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > > > Signed-off-by: Nathan Chancellor
> > >
> > > Ack with one nit below.
> > >
> > > Acked-by: Yonghong Song
> >
> >
> >
> > > > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > > > .. code-block:: console
> > > > - test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073?
> > > > unexpected error: -4007
> > > > + test_xdpwall:FAIL:Does LLVM have
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > > > unexpected error: -4007
> > > > -__ https://reviews.llvm.org/D109073
> > > > +__
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> > >
> > > To be consistent with other links, could you add the missing last alnum
> > > '5' to the above link?
> >
> > Thanks a lot for catching this and providing an ack. Andrew, could you
> > squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
>
> Please send a new patch.
> We'd like to take all bpf patches through the bpf tree to avoid conflicts.
Very well, I've sent a standalone v2 on top of bpf-next:
https://lore.kernel.org/20240111-bpf-update-llvm-phabricator-links-v2-1-9a7ae976b...@kernel.org/
Andrew, just drop selftests-bpf-update-llvm-phabricator-links.patch
altogether in that case, the other two patches are fine to go via -mm I
think.
Cheers,
Nathan
Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
Hi Yonghong,
On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
>
> On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > has been abandoned in favor of GitHub pull requests. While the majority
> > of links in the kernel sources still work because of the work Fangrui
> > has done turning the dynamic Phabricator instance into a static archive,
> > there are some issues with that work, so preemptively convert all the
> > links in the kernel sources to point to the commit on GitHub.
> >
> > Most of the commits have the corresponding differential review link in
> > the commit message itself so there should not be any loss of fidelity in
> > the relevant information.
> >
> > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > in the area.
> >
> > Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > Signed-off-by: Nathan Chancellor
>
> Ack with one nit below.
>
> Acked-by: Yonghong Song
> > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > .. code-block:: console
> > - test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073?
> > unexpected error: -4007
> > + test_xdpwall:FAIL:Does LLVM have
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > unexpected error: -4007
> > -__ https://reviews.llvm.org/D109073
> > +__
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
>
> To be consistent with other links, could you add the missing last alnum '5'
> to the above link?
Thanks a lot for catching this and providing an ack. Andrew, could you
squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
diff --git a/tools/testing/selftests/bpf/README.rst
b/tools/testing/selftests/bpf/README.rst
index b9a493f66557..e56034abb3c2 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -306,4 +306,4 @@ from running test_progs will look like:
test_xdpwall:FAIL:Does LLVM have
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
unexpected error: -4007
-__
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
+__
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5
[PATCH 3/3] treewide: Update LLVM Bugzilla links
LLVM moved their issue tracker from their own Bugzilla instance to
GitHub issues. While all of the links are still valid, they may not
necessarily show the most up to date information around the issues, as
all updates will occur on GitHub, not Bugzilla.
Another complication is that the Bugzilla issue number is not always the
same as the GitHub issue number. Thankfully, LLVM maintains this mapping
through two shortlinks:
https://llvm.org/bz -> https://bugs.llvm.org/show_bug.cgi?id=
https://llvm.org/pr ->
https://github.com/llvm/llvm-project/issues/
Switch all "https://bugs.llvm.org/show_bug.cgi?id=" links to the
"https://llvm.org/pr" shortlink so that the links show the most up
to date information. Each migrated issue links back to the Bugzilla
entry, so there should be no loss of fidelity of information here.
Signed-off-by: Nathan Chancellor
---
arch/powerpc/Makefile | 4 ++--
arch/powerpc/kvm/book3s_hv_nested.c | 2 +-
arch/s390/include/asm/ftrace.h | 2 +-
arch/x86/power/Makefile | 2 +-
crypto/blake2b_generic.c| 2 +-
drivers/firmware/efi/libstub/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c| 2 +-
drivers/media/test-drivers/vicodec/codec-fwht.c | 2 +-
drivers/regulator/Kconfig | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
lib/Kconfig.kasan | 2 +-
lib/raid6/Makefile | 2 +-
lib/stackinit_kunit.c | 2 +-
mm/slab_common.c| 2 +-
net/bridge/br_multicast.c | 2 +-
security/Kconfig| 2 +-
16 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f19dbaa1d541..cd6aaa45f355 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,11 +133,11 @@ CFLAGS-$(CONFIG_PPC64)+= $(call
cc-option,-mno-pointers-to-nested-functions)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128)
# Clang unconditionally reserves r2 on ppc32 and does not support the flag
-# https://bugs.llvm.org/show_bug.cgi?id=39555
+# https://llvm.org/pr39555
CFLAGS-$(CONFIG_PPC32) := $(call cc-option, -ffixed-r2)
# Clang doesn't support -mmultiple / -mno-multiple
-# https://bugs.llvm.org/show_bug.cgi?id=39556
+# https://llvm.org/pr39556
CFLAGS-$(CONFIG_PPC32) += $(call cc-option, $(MULTIPLEWORD))
CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c
b/arch/powerpc/kvm/book3s_hv_nested.c
index 3b658b8696bc..3f5970f74c6b 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -55,7 +55,7 @@ void kvmhv_save_hv_regs(struct kvm_vcpu *vcpu, struct
hv_guest_state *hr)
hr->dawrx1 = vcpu->arch.dawrx1;
}
-/* Use noinline_for_stack due to https://bugs.llvm.org/show_bug.cgi?id=49610 */
+/* Use noinline_for_stack due to https://llvm.org/pr49610 */
static noinline_for_stack void byteswap_pt_regs(struct pt_regs *regs)
{
unsigned long *addr = (unsigned long *) regs;
diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
index 5a82b08f03cd..621f23d5ae30 100644
--- a/arch/s390/include/asm/ftrace.h
+++ b/arch/s390/include/asm/ftrace.h
@@ -9,7 +9,7 @@
#ifndef __ASSEMBLY__
#ifdef CONFIG_CC_IS_CLANG
-/* https://bugs.llvm.org/show_bug.cgi?id=41424 */
+/* https://llvm.org/pr41424 */
#define ftrace_return_address(n) 0UL
#else
#define ftrace_return_address(n) __builtin_return_address(n)
diff --git a/arch/x86/power/Makefile b/arch/x86/power/Makefile
index 379777572bc9..e0cd7afd5302 100644
--- a/arch/x86/power/Makefile
+++ b/arch/x86/power/Makefile
@@ -5,7 +5,7 @@
CFLAGS_cpu.o := -fno-stack-protector
# Clang may incorrectly inline functions with stack protector enabled into
-# __restore_processor_state(): https://bugs.llvm.org/show_bug.cgi?id=47479
+# __restore_processor_state(): https://llvm.org/pr47479
CFLAGS_REMOVE_cpu.o := $(CC_FLAGS_LTO)
obj-$(CONFIG_PM_SLEEP) += cpu.o
diff --git a/crypto/blake2b_generic.c b/crypto/blake2b_generic.c
index 6704c0355889..32e380b714b6 100644
--- a/crypto/blake2b_generic.c
+++ b/crypto/blake2b_generic.c
@@ -102,7 +102,7 @@ static void blake2b_compress_one_generic(struct
blake2b_state *S,
ROUND(10);
ROUND(11);
#ifdef CONFIG_CC_IS_CLANG
-#pragma nounroll /* https://bugs.llvm.org/show_bug.cgi?id=45803 */
+#pragma nounroll /* https://llvm.org/pr45803 */
#endif
for (i = 0; i < 8; ++i)
S->h[i] = S->h[i] ^ v[i] ^ v[i + 8];
diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index 06964a3c130f..a223bd10564b 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/
[PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
reviews.llvm.org was LLVM's Phabricator instances for code review. It
has been abandoned in favor of GitHub pull requests. While the majority
of links in the kernel sources still work because of the work Fangrui
has done turning the dynamic Phabricator instance into a static archive,
there are some issues with that work, so preemptively convert all the
links in the kernel sources to point to the commit on GitHub.
Most of the commits have the corresponding differential review link in
the commit message itself so there should not be any loss of fidelity in
the relevant information.
Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
in the area.
Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
Signed-off-by: Nathan Chancellor
---
Cc: a...@kernel.org
Cc: dan...@iogearbox.net
Cc: and...@kernel.org
Cc: myko...@fb.com
Cc: b...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/bpf/README.rst | 32 +++---
tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +-
.../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +-
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/bpf/README.rst
b/tools/testing/selftests/bpf/README.rst
index cb9b95702ac6..b9a493f66557 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -115,7 +115,7 @@ the insn 20 undoes map_value addition. It is currently
impossible for the
verifier to understand such speculative pointer arithmetic.
Hence `this patch`__ addresses it on the compiler side. It was committed on
llvm 12.
-__ https://reviews.llvm.org/D85570
+__
https://github.com/llvm/llvm-project/commit/ddf1864ace484035e3cde5e83b3a31ac81e059c6
The corresponding C code
@@ -165,7 +165,7 @@ This is due to a llvm BPF backend bug. `The fix`__
has been pushed to llvm 10.x release branch and will be
available in 10.0.1. The patch is available in llvm 11.0.0 trunk.
-__ https://reviews.llvm.org/D78466
+__
https://github.com/llvm/llvm-project/commit/3cb7e7bf959dcd3b8080986c62e10a75c7af43f0
bpf_verif_scale/loop6.bpf.o test failure with Clang 12
==
@@ -204,7 +204,7 @@ r5(w5) is eventually saved on stack at insn #24 for later
use.
This cause later verifier failure. The bug has been `fixed`__ in
Clang 13.
-__ https://reviews.llvm.org/D97479
+__
https://github.com/llvm/llvm-project/commit/1959ead525b8830cc8a345f45e1c3ef9902d3229
BPF CO-RE-based tests and Clang version
===
@@ -221,11 +221,11 @@ failures:
- __builtin_btf_type_id() [0_, 1_, 2_];
- __builtin_preserve_type_info(), __builtin_preserve_enum_value() [3_, 4_].
-.. _0: https://reviews.llvm.org/D74572
-.. _1: https://reviews.llvm.org/D74668
-.. _2: https://reviews.llvm.org/D85174
-.. _3: https://reviews.llvm.org/D83878
-.. _4: https://reviews.llvm.org/D83242
+.. _0:
https://github.com/llvm/llvm-project/commit/6b01b465388b204d543da3cf49efd6080db094a9
+.. _1:
https://github.com/llvm/llvm-project/commit/072cde03aaa13a2c57acf62d79876bf79aa1919f
+.. _2:
https://github.com/llvm/llvm-project/commit/00602ee7ef0bf6c68d690a2bd729c12b95c95c99
+.. _3:
https://github.com/llvm/llvm-project/commit/6d218b4adb093ff2e9764febbbc89f429412006c
+.. _4:
https://github.com/llvm/llvm-project/commit/6d6750696400e7ce988d66a1a00e1d0cb32815f8
Floating-point tests and Clang version
==
@@ -234,7 +234,7 @@ Certain selftests, e.g. core_reloc, require support for the
floating-point
types, which was introduced in `Clang 13`__. The older Clang versions will
either crash when compiling these tests, or generate an incorrect BTF.
-__ https://reviews.llvm.org/D83289
+__
https://github.com/llvm/llvm-project/commit/a7137b238a07d9399d3ae96c0b461571bd5aa8b2
Kernel function call test and Clang version
===
@@ -248,7 +248,7 @@ Without it, the error from compiling bpf selftests looks
like:
libbpf: failed to find BTF for extern 'tcp_slow_start' [25] section: -2
-__ https://reviews.llvm.org/D93563
+__
https://github.com/llvm/llvm-project/commit/886f9ff53155075bd5f1e994f17b85d1e1b7470c
btf_tag test and Clang version
==
@@ -264,8 +264,8 @@ Without them, the btf_tag selftest will be skipped and you
will observe:
# btf_tag:SKIP
-.. _0: https://reviews.llvm.org/D111588
-.. _1: https://reviews.llvm.org/D99
+.. _0:
https://github.com/llvm/llvm-project/commit/a162b67c98066218d0d00aa13b99afb95d9bb5e6
+.. _1:
https://github.com/llvm/llvm-project/commit/3466e00716e12e32fdb100e3fcfca5c2b3e8d784
Clang dependencies for static linking tests
===
@@ -274,7 +274,7 @@ linked_vars, linked_maps, and linked_funcs tests depend on
`Clang fix`__ to
generate valid BTF infor
[PATCH 2/3] arch and include: Update LLVM Phabricator links
reviews.llvm.org was LLVM's Phabricator instances for code review. It has been abandoned in favor of GitHub pull requests. While the majority of links in the kernel sources still work because of the work Fangrui has done turning the dynamic Phabricator instance into a static archive, there are some issues with that work, so preemptively convert all the links in the kernel sources to point to the commit on GitHub. Most of the commits have the corresponding differential review link in the commit message itself so there should not be any loss of fidelity in the relevant information. Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172 Signed-off-by: Nathan Chancellor --- arch/arm64/Kconfig | 4 ++-- arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/ftrace.h | 2 +- include/linux/compiler-clang.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 7b071a00425d..3304ba7c6c2a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -380,7 +380,7 @@ config BROKEN_GAS_INST config BUILTIN_RETURN_ADDRESS_STRIPS_PAC bool # Clang's __builtin_return_adddress() strips the PAC since 12.0.0 - # https://reviews.llvm.org/D75044 + # https://github.com/llvm/llvm-project/commit/2a96f47c5ffca84cd774ad402cacd137f4bf45e2 default y if CC_IS_CLANG && (CLANG_VERSION >= 12) # 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 @@ -2202,7 +2202,7 @@ config STACKPROTECTOR_PER_TASK config UNWIND_PATCH_PAC_INTO_SCS bool "Enable shadow call stack dynamically using code patching" - # needs Clang with https://reviews.llvm.org/D111780 incorporated + # needs Clang with https://github.com/llvm/llvm-project/commit/de07cde67b5d205d58690be012106022aea6d2b3 incorporated depends on CC_IS_CLANG && CLANG_VERSION >= 15 depends on ARM64_PTR_AUTH_KERNEL && CC_HAS_BRANCH_PROT_PAC_RET depends on SHADOW_CALL_STACK diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index cd4c9a204d08..f7453eba0b62 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -291,7 +291,7 @@ config AS_HAS_INSN def_bool $(as-instr,.insn r 51$(comma) 0$(comma) 0$(comma) t0$(comma) t0$(comma) zero) config AS_HAS_OPTION_ARCH - # https://reviews.llvm.org/D123515 + # https://github.com/llvm/llvm-project/commit/9e8ed3403c191ab9c4903e8eeb8f732ff8a43cb4 def_bool y depends on $(as-instr, .option arch$(comma) +m) depends on !$(as-instr, .option arch$(comma) -i) diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h index 2b2f5df7ef2c..3f526404a718 100644 --- a/arch/riscv/include/asm/ftrace.h +++ b/arch/riscv/include/asm/ftrace.h @@ -15,7 +15,7 @@ /* * Clang prior to 13 had "mcount" instead of "_mcount": - * https://reviews.llvm.org/D98881 + * https://github.com/llvm/llvm-project/commit/ef58ae86ba778ed7d01cd3f6bd6d08f943abab44 */ #if defined(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >= 13 #define MCOUNT_NAME _mcount diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index ddab1ef22bee..f0a47afef125 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -9,7 +9,7 @@ * Clang prior to 17 is being silly and considers many __cleanup() variables * as unused (because they are, their sole purpose is to go out of scope). * - * https://reviews.llvm.org/D152180 + * https://github.com/llvm/llvm-project/commit/877210faa447f4cc7db87812f8ed80e398fedd61 */ #undef __cleanup #define __cleanup(func) __maybe_unused __attribute__((__cleanup__(func))) -- 2.43.0
[PATCH 0/3] Update LLVM Phabricator and Bugzilla links
This series updates all instances of LLVM Phabricator and Bugzilla links to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue shortlinks respectively. I split up the Phabricator patch into BPF selftests and the rest of the kernel in case the BPF folks want to take it separately from the rest of the series, there are obviously no dependency issues in that case. The Bugzilla change was mechanical enough and should have no conflicts. I am aiming this at Andrew and CC'ing other lists, in case maintainers want to chime in, but I think this is pretty uncontroversial (famous last words...). --- Nathan Chancellor (3): selftests/bpf: Update LLVM Phabricator links arch and include: Update LLVM Phabricator links treewide: Update LLVM Bugzilla links arch/arm64/Kconfig | 4 +-- arch/powerpc/Makefile | 4 +-- arch/powerpc/kvm/book3s_hv_nested.c| 2 +- arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/ftrace.h| 2 +- arch/s390/include/asm/ftrace.h | 2 +- arch/x86/power/Makefile| 2 +- crypto/blake2b_generic.c | 2 +- drivers/firmware/efi/libstub/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- drivers/regulator/Kconfig | 2 +- include/asm-generic/vmlinux.lds.h | 2 +- include/linux/compiler-clang.h | 2 +- lib/Kconfig.kasan | 2 +- lib/raid6/Makefile | 2 +- lib/stackinit_kunit.c | 2 +- mm/slab_common.c | 2 +- net/bridge/br_multicast.c | 2 +- security/Kconfig | 2 +- tools/testing/selftests/bpf/README.rst | 32 +++--- tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- 23 files changed, 40 insertions(+), 40 deletions(-) --- base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a change-id: 20240109-update-llvm-links-d03f9d649e1e Best regards, -- Nathan Chancellor
Re: [PATCH 2/7] kexec_file: print out debugging message if required
On Thu, Nov 23, 2023 at 09:49:20PM +0800, b...@redhat.com wrote:
> On 11/17/23 at 10:01pm, Baoquan He wrote:
> > On 11/17/23 at 09:37am, Liu, Yujie wrote:
> > > Hi Baoquan,
> > >
> > > On Fri, 2023-11-17 at 17:14 +0800, Baoquan He wrote:
> > > > Hi,
> > > >
> > > > On 11/16/23 at 05:04am, kernel test robot wrote:
> > > > > Hi Baoquan,
> > > > >
> > > > > kernel test robot noticed the following build errors:
> > > > >
> > > > > [auto build test ERROR on arm64/for-next/core]
> > > > > [also build test ERROR on tip/x86/core powerpc/next powerpc/fixes
> > > > > linus/master v6.7-rc1 next-20231115]
> > > > > [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/Baoquan-He/kexec_file-add-kexec_file-flag-to-control-debug-printing/20231114-234003
> > > > > base:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > > > > for-next/core
> > > > > patch link:
> > > > > https://lore.kernel.org/r/20231114153253.241262-3-bhe%40redhat.com
> > > > > patch subject: [PATCH 2/7] kexec_file: print out debugging message if
> > > > > required
> > > > > config: hexagon-comet_defconfig
> > > > > (https://download.01.org/0day-ci/archive/20231116/202311160431.bxpc7no9-...@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/20231116/202311160431.bxpc7no9-...@intel.com/reproduce)
> > > > >
> > > >
> > > > Thanks for reporting.
> > > >
> > > > I met below failure when following the steps of provided reproducer.
> > > > Could anyone help check what's wrong with that?
> > >
> > > Sorry this seems to be a bug in the reproducer. Could you please change
> > > the compiler parameter to "COMPILER=clang-16" and rerun the command? We
> > > will fix the issue ASAP.
>
> Any update for the reproducer? I would like to post v2 with the fix. I
> doubt it's the same issue as another report on this patch, while not
> quite sure.
Shouldn't you be able to run
$ COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-16 ~/bin/make.cross W=1
O=build_dir ARCH=hexagon SHELL=/bin/bash kernel/
after the command you just ran to reproduce this now? It is
essentially the same fix that they mention above but for the second
invocation of make.cross.
You can also not even bother with the wrapper altogether if you have the
compiler installed in the default path that they provide (W=1 is not
necessary to reproduce this issue):
$ mkdir -p build_dir
$ curl -LSso build_dir/.config
https://download.01.org/0day-ci/archive/20231116/202311160431.bxpc7no9-...@intel.com/config
$ make -skj"$(nproc)" ARCH=hexagon LLVM=$HOME/0day/llvm-16.0.6-x86_64/bin/
O=build_dir olddefconfig kernel/crash_core.o
...
kernel/crash_core.c:554:3: error: call to undeclared function
'kexec_dprintk'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
kexec_dprintk("Crash PT_LOAD ELF header. phdr=%p
vaddr=0x%llx, paddr=0x%llx, "
^
1 error generated.
> > Here you are. Thanks for your quick response.
> > --
> > [root@~ linux]# COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang-16
> > ~/bin/make.cross W=1 O=build_dir ARCH=hexagon olddefconfig
> > Compiler will be installed in /root/0day
> > lftpget -c
> > https://cdn.kernel.org/pub/tools/llvm/files/./llvm-16.0.6-x86_64.tar.xz
> > /root/linux
> >
> > tar Jxf /root/0day/./llvm-16.0.6-x86_64.tar.xz -C /root/0day
> > PATH=/root/0day/llvm-16.0.6-x86_64/bin:/root/.local/bin:/root/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
> > make --keep-going LLVM=1 CROSS_COMPILE=hexagon-linux- LLVM_IAS=1 --jobs=128
> > KCFLAGS=-Warray-bounds -Wundef -fstrict-flex-arrays=3 -funsigned-char
> > -Wenum-conversion W=1 O=build_dir ARCH=hexagon olddefconfig
> > make[1]: Entering directory '/root/linux/build_dir'
> > GEN Makefile
> > HOSTCC scripts/basic/fixdep
> > HOSTCC scripts/kconfig/conf.o
> > HOSTCC scripts/kconfig/confdata.o
> > HOSTCC scripts/kconfig/expr.o
> > HOSTCC scripts/kconfig/lexer.lex.o
> > HOSTCC scripts/kconfig/menu.o
> > HOSTCC scripts/kconfig/parser.tab.o
> > HOSTCC scripts/kconfig/preprocess.o
> > HOSTCC scripts/kconfig/symbol.o
> > HOSTCC scripts/kconfig/util.o
> > HOSTLD scripts/kconfig/conf
> > #
> > # configuration written to .config
> > #
> > make[1]: Leaving directory '/root/linux/build_dir'
> >
> > >
> > > > [root@~ linux]# COMPILER_INSTALL_PATH=$HOME/0day COMPILER=c
Re: [pci:controller/xilinx-xdma] BUILD REGRESSION 8d786149d78c7784144c7179e25134b6530b714b
On Wed, Nov 01, 2023 at 10:25:25AM +0100, Arnd Bergmann wrote:
> On Tue, Oct 31, 2023, at 18:14, Bjorn Helgaas wrote:
> > On Tue, Oct 31, 2023 at 09:59:29AM -0700, Nick Desaulniers wrote:
> >> On Tue, Oct 31, 2023 at 7:56 AM Bjorn Helgaas wrote:
>
> >> > arch/powerpc/xmon/xmon.c: release_output_lock();
> >> >
> >> > That said, the unused functions do look legit:
> >> >
> >> > grackle_set_stg() is a static function and the only call is under
> >> > "#if 0".
> >>
> >> Time to remove it then? Or is it a bug that it's not called?
> >> Otherwise the definition should be behind the same preprocessor guards
> >> as the caller. Same for the below.
>
> It would be nice to get rid of all warnings about unused
> "static inline" functions and "static const" variables in .c
> files. I think both these warnings got added at the W=1 level
> for compilers that support them at some point, but are ignored
> for normal builds without W=1 because they are too noisy.
>
> Obviously, all compilers ignore unused inline functions and
> const variables in header files regardless of the warning level.
Right, this was an intentional change done by Masahiro to try and take
advantage of the fact that clang warns about unused static inline
functions in .c files (whereas GCC has no warning in .c or .h files) to
clean up dead code. See commit 6863f5643dd7 ("kbuild: allow Clang to
find unused static inline functions for W=1 build") for more
information.
Cheers,
Nathan
[PATCH] scsi: ibmvfc: Use 'unsigned int' for single-bit bitfields in 'struct ibmvfc_host'
Clang warns (or errors with CONFIG_WERROR=y) several times along the
lines of:
drivers/scsi/ibmvscsi/ibmvfc.c:650:17: warning: implicit truncation from
'int' to a one-bit wide bit-field changes value from 1 to -1
[-Wsingle-bit-bitfield-constant-conversion]
650 | vhost->reinit = 1;
| ^ ~
A single-bit signed integer bitfield only has possible values of -1 and
0, not 0 and 1 like an unsigned one would. No context appears to check
the actual value of these bitfields, just whether or not it is zero.
However, it is easy enough to change the type of the fields to 'unsigned
int', which keeps the same size in memory and resolves the warning.
Fixes: 5144905884e2 ("scsi: ibmvfc: Use a bitfield for boolean flags")
Signed-off-by: Nathan Chancellor
---
drivers/scsi/ibmvscsi/ibmvfc.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.h b/drivers/scsi/ibmvscsi/ibmvfc.h
index 331ecf8254be..745ad5ac7251 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -892,15 +892,15 @@ struct ibmvfc_host {
int init_retries;
int discovery_threads;
int abort_threads;
- int client_migrated:1;
- int reinit:1;
- int delay_init:1;
- int logged_in:1;
- int mq_enabled:1;
- int using_channels:1;
- int do_enquiry:1;
- int aborting_passthru:1;
- int scan_complete:1;
+ unsigned int client_migrated:1;
+ unsigned int reinit:1;
+ unsigned int delay_init:1;
+ unsigned int logged_in:1;
+ unsigned int mq_enabled:1;
+ unsigned int using_channels:1;
+ unsigned int do_enquiry:1;
+ unsigned int aborting_passthru:1;
+ unsigned int scan_complete:1;
int scan_timeout;
int events_to_log;
#define IBMVFC_AE_LINKUP 0x0001
---
base-commit: b6f2e063017b92491976a40c32a0e4b3c13e7d2f
change-id: 20231010-ibmvfc-fix-bitfields-type-971a07c64ec6
Best regards,
--
Nathan Chancellor
Re: [PATCH v2] vfs: shave work on failed file open
Hi Christian,
> >From d266eee9d9d917f07774e2c2bab0115d2119a311 Mon Sep 17 00:00:00 2001
> From: Christian Brauner
> Date: Fri, 29 Sep 2023 08:45:59 +0200
> Subject: [PATCH] file: convert to SLAB_TYPESAFE_BY_RCU
>
> In recent discussions around some performance improvements in the file
> handling area we discussed switching the file cache to rely on
> SLAB_TYPESAFE_BY_RCU which allows us to get rid of call_rcu() based
> freeing for files completely. This is a pretty sensitive change overall
> but it might actually be worth doing.
>
> The main downside is the subtlety. The other one is that we should
> really wait for Jann's patch to land that enables KASAN to handle
> SLAB_TYPESAFE_BY_RCU UAFs. Currently it doesn't but a patch for this
> exists.
>
> With SLAB_TYPESAFE_BY_RCU objects may be freed and reused multiple times
> which requires a few changes. So it isn't sufficient anymore to just
> acquire a reference to the file in question under rcu using
> atomic_long_inc_not_zero() since the file might have already been
> recycled and someone else might have bumped the reference.
>
> In other words, callers might see reference count bumps from newer
> users. For this is reason it is necessary to verify that the pointer is
> the same before and after the reference count increment. This pattern
> can be seen in get_file_rcu() and __files_get_rcu().
>
> In addition, it isn't possible to access or check fields in struct file
> without first aqcuiring a reference on it. Not doing that was always
> very dodgy and it was only usable for non-pointer data in struct file.
> With SLAB_TYPESAFE_BY_RCU it is necessary that callers first acquire a
> reference under rcu or they must hold the files_lock of the fdtable.
> Failing to do either one of this is a bug.
>
> Thanks to Jann for pointing out that we need to ensure memory ordering
> between reallocations and pointer check by ensuring that all subsequent
> loads have a dependency on the second load in get_file_rcu() and
> providing a fixup that was folded into this patch.
>
> Cc: Jann Horn
> Suggested-by: Linus Torvalds
> Signed-off-by: Christian Brauner
> ---
> --- a/arch/powerpc/platforms/cell/spufs/coredump.c
> +++ b/arch/powerpc/platforms/cell/spufs/coredump.c
> @@ -74,10 +74,13 @@ static struct spu_context *coredump_next_context(int *fd)
> *fd = n - 1;
>
> rcu_read_lock();
> - file = lookup_fd_rcu(*fd);
> - ctx = SPUFS_I(file_inode(file))->i_ctx;
> - get_spu_context(ctx);
> + file = lookup_fdget_rcu(*fd);
> rcu_read_unlock();
> + if (file) {
> + ctx = SPUFS_I(file_inode(file))->i_ctx;
> + get_spu_context(ctx);
> + fput(file);
> + }
>
> return ctx;
> }
This hunk now causes a clang warning (or error, since arch/powerpc builds
with -Werror by default) in next-20231003.
$ make -skj"$(nproc)" ARCH=powerpc LLVM=1 ppc64_guest_defconfig
arch/powerpc/platforms/cell/spufs/coredump.o
...
arch/powerpc/platforms/cell/spufs/coredump.c:79:6: error: variable 'ctx' is
used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
79 | if (file) {
| ^~~~
arch/powerpc/platforms/cell/spufs/coredump.c:85:9: note: uninitialized use
occurs here
85 | return ctx;
|^~~
arch/powerpc/platforms/cell/spufs/coredump.c:79:2: note: remove the 'if' if
its condition is always true
79 | if (file) {
| ^
arch/powerpc/platforms/cell/spufs/coredump.c:69:25: note: initialize the
variable 'ctx' to silence this warning
69 | struct spu_context *ctx;
|^
| = NULL
1 error generated.
Cheers,
Nathan
Re: [PATCH v7 1/3 RESEND] block:sed-opal: SED Opal keystore
On Wed, Sep 13, 2023 at 01:49:39PM -0700, Nick Desaulniers wrote:
> On Wed, Sep 13, 2023 at 9:56 AM Nathan Chancellor wrote:
> >
> > Hi Greg,
> >
> > On Fri, Sep 08, 2023 at 10:30:54AM -0500, gjo...@linux.vnet.ibm.com wrote:
> > > From: Greg Joyce
> > >
> > > Add read and write functions that allow SED Opal keys to stored
> > > in a permanent keystore.
> > >
> > > Signed-off-by: Greg Joyce
> > > Reviewed-by: Jonathan Derrick
> > > ---
> > > block/Makefile | 2 +-
> > > block/sed-opal-key.c | 24
> > > include/linux/sed-opal-key.h | 15 +++
> > > 3 files changed, 40 insertions(+), 1 deletion(-)
> > > create mode 100644 block/sed-opal-key.c
> > > create mode 100644 include/linux/sed-opal-key.h
> > >
> > > diff --git a/block/Makefile b/block/Makefile
> > > index 46ada9dc8bbf..ea07d80402a6 100644
> > > --- a/block/Makefile
> > > +++ b/block/Makefile
> > > @@ -34,7 +34,7 @@ obj-$(CONFIG_BLK_DEV_ZONED) += blk-zoned.o
> > > obj-$(CONFIG_BLK_WBT)+= blk-wbt.o
> > > obj-$(CONFIG_BLK_DEBUG_FS) += blk-mq-debugfs.o
> > > obj-$(CONFIG_BLK_DEBUG_FS_ZONED)+= blk-mq-debugfs-zoned.o
> > > -obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o
> > > +obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o sed-opal-key.o
> > > obj-$(CONFIG_BLK_PM) += blk-pm.o
> > > obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o
> > > blk-crypto-profile.o \
> > > blk-crypto-sysfs.o
> > > diff --git a/block/sed-opal-key.c b/block/sed-opal-key.c
> > > new file mode 100644
> > > index ..16f380164c44
> > > --- /dev/null
> > > +++ b/block/sed-opal-key.c
> > > @@ -0,0 +1,24 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * SED key operations.
> > > + *
> > > + * Copyright (C) 2022 IBM Corporation
> > > + *
> > > + * These are the accessor functions (read/write) for SED Opal
> > > + * keys. Specific keystores can provide overrides.
> > > + *
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +int __weak sed_read_key(char *keyname, char *key, u_int *keylen)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> > > +
> > > +int __weak sed_write_key(char *keyname, char *key, u_int keylen)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> >
> > This change causes a build failure for certain clang configurations due
> > to an unfortunate issue [1] with recordmcount, clang's integrated
> > assembler, and object files that contain a section with only weak
> > functions/symbols (in this case, the .text section in sed-opal-key.c),
> > resulting in
> >
> > Cannot find symbol for section 2: .text.
> > block/sed-opal-key.o: failed
> >
> > when building this file.
>
> The definitions in
> block/sed-opal-key.c
> should be deleted. Instead, in
> include/linux/sed-opal-key.h
> CONFIG_PSERIES_PLPKS_SED should be used to define static inline
> versions when CONFIG_PSERIES_PLPKS_SED is not defined.
>
> #ifdef CONFIG_PSERIES_PLPKS_SED
> int sed_read_key(char *keyname, char *key, u_int *keylen);
> int sed_write_key(char *keyname, char *key, u_int keylen);
> #else
> static inline
> int sed_read_key(char *keyname, char *key, u_int *keylen) {
> return -EOPNOTSUPP;
> }
> static inline
> int sed_write_key(char *keyname, char *key, u_int keylen);
> return -EOPNOTSUPP;
> }
> #endif
Ah yes, this is the other solution. I figured the way that it was
written, sed_read_key() and sed_write_key() may be overridden by a
different architecture or translation unit in the future but I think
until it is needed, your solution would be perfectly fine. Thanks for
taking a look!
Cheers,
Nathan
> > Is there any real reason to have a separate translation unit for these
> > two functions versus just having them living in sed-opal.c? Those two
> > object files share the same Kconfig dependency. I am happy to send a
> > patch if that is an acceptable approach.
> >
> > [1]: https://github.com/ClangBuiltLinux/linux/issues/981
> >
> > Cheers,
> > Nathan
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
Re: [PATCH v7 3/3 RESEND] powerpc/pseries: PLPKS SED Opal keystore support
Hi Greg,
On Fri, Sep 08, 2023 at 10:30:56AM -0500, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Define operations for SED Opal to read/write keys
> from POWER LPAR Platform KeyStore(PLPKS). This allows
> non-volatile storage of SED Opal keys.
>
> Signed-off-by: Greg Joyce
> Reviewed-by: Jonathan Derrick
> Reviewed-by: Hannes Reinecke
After this change in -next as commit 9f2c7411ada9 ("powerpc/pseries:
PLPKS SED Opal keystore support"), I see the following crash when
booting some distribution configurations, such as OpenSUSE's [1] (the
rootfs is available at [2] if necessary):
$ qemu-system-ppc64 \
-display none \
-nodefaults \
-device ipmi-bmc-sim,id=bmc0 \
-device isa-ipmi-bt,bmc=bmc0,irq=10 \
-machine powernv \
-kernel arch/powerpc/boot/zImage.epapr \
-initrd ppc64le-rootfs.cpio \
-m 2G \
-serial mon:stdio
...
[0.00] Linux version 6.6.0-rc1-4-g9f2c7411ada9
(nathan@dev-arch.thelio-3990X) (powerpc64-linux-gcc (GCC) 13.2.0, GNU ld (GNU
Binutils) 2.41) #1 SMP Wed Sep 13 11:53:38 MST 2023
...
[1.808911] [ cut here ]
[1.810336] kernel BUG at arch/powerpc/kernel/syscall.c:34!
[1.810799] Oops: Exception in kernel mode, sig: 5 [#1]
[1.810985] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
[1.811191] Modules linked in:
[1.811483] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
6.6.0-rc1-4-g9f2c7411ada9 #1
[1.811825] Hardware name: IBM PowerNV (emulated by qemu) POWER9 0x4e1202
opal:v7.0 PowerNV
[1.812133] NIP: c002c8c4 LR: c000d620 CTR: c000d4c0
[1.812335] REGS: c2deb7b0 TRAP: 0700 Not tainted
(6.6.0-rc1-4-g9f2c7411ada9)
[1.812595] MSR: 90029033 CR: 2800028d
XER: 20040004
[1.812930] CFAR: c000d61c IRQMASK: 3
[1.812930] GPR00: c000d620 c2deba50 c15ef400
c2debe80
[1.812930] GPR04: 4800028d
[1.812930] GPR08: 79cd 0001
[1.812930] GPR12: c28b
[1.812930] GPR16:
[1.812930] GPR20:
[1.812930] GPR24:
[1.812930] GPR28: 4800028d c2debe80
c2debe10
[1.814858] NIP [c002c8c4] system_call_exception+0x84/0x250
[1.815480] LR [c000d620] system_call_common+0x160/0x2c4
[1.815772] Call Trace:
[1.815929] [c2debe50] [c000d620]
system_call_common+0x160/0x2c4
[1.816178] --- interrupt: c00 at plpar_hcall+0x38/0x60
[1.816330] NIP: c00e43f8 LR: c00fb558 CTR:
[1.816518] REGS: c2debe80 TRAP: 0c00 Not tainted
(6.6.0-rc1-4-g9f2c7411ada9)
[1.816740] MSR: 9280b033 CR:
2800028d XER:
[1.817039] IRQMASK: 0
[1.817039] GPR00: 4800028d c2deb950 c15ef400
0434
[1.817039] GPR04: 028eb190 28ac6600 001d
0010
[1.817039] GPR08:
[1.817039] GPR12: c28b c0011188
[1.817039] GPR16:
[1.817039] GPR20:
[1.817039] GPR24:
c00028ac6600
[1.817039] GPR28: 0010 c28eb190 c00028ac6600
c2deba30
[1.818785] NIP [c00e43f8] plpar_hcall+0x38/0x60
[1.818929] LR [c00fb558] plpks_read_var+0x208/0x290
[1.819093] --- interrupt: c00
[1.819195] [c2deb950] [c00fb528] plpks_read_var+0x1d8/0x290
(unreliable)
[1.819433] [c2deba10] [c00fc1ac] sed_read_key+0x9c/0x170
[1.819617] [c2debad0] [c20541a8] sed_opal_init+0xac/0x174
[1.819823] [c2debc50] [c0010ad0] do_one_initcall+0x80/0x3b0
[1.820017] [c2debd30] [c2004860]
kernel_init_freeable+0x338/0x3dc
[1.820229] [c2debdf0] [c00111b0] kernel_init+0x30/0x1a0
[1.820411] [c2debe50] [c000d620]
system_call_common+0x160/0x2c4
[1.820614] --- interrupt: c00 at plpar_hcall+0x38/0x60
[1.820755] NIP: c00e43f8 LR: c00fb558 CTR:
[1.820940] REGS: c2debe80 TRAP: 0c00 Not tainted
(6.6.0-rc1-4-g9f2c7411ada9)
[1.821157] MSR: 9280b033 CR:
2800028d XER:
[1.821444] IRQMASK: 0
[1.821444] GPR00: 4800028d c2deb950 c
Re: [PATCH v7 1/3 RESEND] block:sed-opal: SED Opal keystore
Hi Greg,
On Fri, Sep 08, 2023 at 10:30:54AM -0500, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce
>
> Add read and write functions that allow SED Opal keys to stored
> in a permanent keystore.
>
> Signed-off-by: Greg Joyce
> Reviewed-by: Jonathan Derrick
> ---
> block/Makefile | 2 +-
> block/sed-opal-key.c | 24
> include/linux/sed-opal-key.h | 15 +++
> 3 files changed, 40 insertions(+), 1 deletion(-)
> create mode 100644 block/sed-opal-key.c
> create mode 100644 include/linux/sed-opal-key.h
>
> diff --git a/block/Makefile b/block/Makefile
> index 46ada9dc8bbf..ea07d80402a6 100644
> --- a/block/Makefile
> +++ b/block/Makefile
> @@ -34,7 +34,7 @@ obj-$(CONFIG_BLK_DEV_ZONED) += blk-zoned.o
> obj-$(CONFIG_BLK_WBT)+= blk-wbt.o
> obj-$(CONFIG_BLK_DEBUG_FS) += blk-mq-debugfs.o
> obj-$(CONFIG_BLK_DEBUG_FS_ZONED)+= blk-mq-debugfs-zoned.o
> -obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o
> +obj-$(CONFIG_BLK_SED_OPAL) += sed-opal.o sed-opal-key.o
> obj-$(CONFIG_BLK_PM) += blk-pm.o
> obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
> blk-crypto-sysfs.o
> diff --git a/block/sed-opal-key.c b/block/sed-opal-key.c
> new file mode 100644
> index ..16f380164c44
> --- /dev/null
> +++ b/block/sed-opal-key.c
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * SED key operations.
> + *
> + * Copyright (C) 2022 IBM Corporation
> + *
> + * These are the accessor functions (read/write) for SED Opal
> + * keys. Specific keystores can provide overrides.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +
> +int __weak sed_read_key(char *keyname, char *key, u_int *keylen)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +int __weak sed_write_key(char *keyname, char *key, u_int keylen)
> +{
> + return -EOPNOTSUPP;
> +}
This change causes a build failure for certain clang configurations due
to an unfortunate issue [1] with recordmcount, clang's integrated
assembler, and object files that contain a section with only weak
functions/symbols (in this case, the .text section in sed-opal-key.c),
resulting in
Cannot find symbol for section 2: .text.
block/sed-opal-key.o: failed
when building this file.
Is there any real reason to have a separate translation unit for these
two functions versus just having them living in sed-opal.c? Those two
object files share the same Kconfig dependency. I am happy to send a
patch if that is an acceptable approach.
[1]: https://github.com/ClangBuiltLinux/linux/issues/981
Cheers,
Nathan
Re: [PATCH] Revert "Revert "powerpc/xmon: Relax frame size for clang""
On Mon, Aug 28, 2023 at 10:35:26AM -0700, ndesaulni...@google.com wrote: > This reverts commit 7f3c5d099b6f8452dc4dcfe4179ea48e6a13d0eb. > > Turns out that this is reproducible still under specific compiler > versions (mea culpa: I did not test every supported version of clang), > and even a few randconfigs bots found. > > We'll have to revisit this again in the future, for now back this out. > > Reported-by: Nathan Chancellor > Closes: > https://github.com/ClangBuiltLinux/linux/issues/252#issuecomment-1690371256 > Reported-by: kernel test robot > Closes: https://lore.kernel.org/llvm/202308260344.vc4giuk7-...@intel.com/ > Signed-off-by: Nick Desaulniers I know this is just a straight reapplication of the original workaround but could we use ccflags here instead of KBUILD_CFLAGS (with it placed after the NO_MIMINAL_TOC assignment)? # clang stores addresses on the stack causing the frame size to blow # out. See https://github.com/ClangBuiltLinux/linux/issues/252 ccflags-$(CONFIG_CC_IS_CLANG) += -Wframe-larger-than=4096 The addition to KBUILD_CFLAGS makes me think this flags will get applied to the rest of the kernel but I have not actually verified. Regardless: Reviewed-by: Nathan Chancellor Side note, seems like b4 is still doing the thing with "From:". > --- > arch/powerpc/xmon/Makefile | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile > index 7705aa74a24d..d334de392e6c 100644 > --- a/arch/powerpc/xmon/Makefile > +++ b/arch/powerpc/xmon/Makefile > @@ -10,6 +10,12 @@ KCSAN_SANITIZE := n > # Disable ftrace for the entire directory > ccflags-remove-$(CONFIG_FUNCTION_TRACER) += $(CC_FLAGS_FTRACE) > > +ifdef CONFIG_CC_IS_CLANG > +# clang stores addresses on the stack causing the frame size to blow > +# out. See https://github.com/ClangBuiltLinux/linux/issues/252 > +KBUILD_CFLAGS += -Wframe-larger-than=4096 > +endif > + > ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC) > > obj-y+= xmon.o nonstdio.o spr_access.o xmon_bpts.o > > --- > base-commit: 2ee82481c392eec06a7ef28df61b7f0d8e45be2e > change-id: 20230828-ppc_rerevert-647427f04ce1 > > Best regards, > -- > Nick Desaulniers >
Re: [PATCH] Revert "powerpc/xmon: Relax frame size for clang"
On Thu, Aug 17, 2023 at 11:11:56AM -0700, ndesaulni...@google.com wrote: > This reverts commit 9c87156cce5a63735d1218f0096a65c50a7a32aa. > > I have not been able to reproduce the reported -Wframe-larger-than= > warning (or disassembly) with clang-11 or clang-18. > > I don't know precisely when this was fixed in llvm, but it may be time > to revert this. > > Closes: https://github.com/ClangBuiltLinux/linux/issues/252 > Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor > --- > arch/powerpc/xmon/Makefile | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile > index d334de392e6c..7705aa74a24d 100644 > --- a/arch/powerpc/xmon/Makefile > +++ b/arch/powerpc/xmon/Makefile > @@ -10,12 +10,6 @@ KCSAN_SANITIZE := n > # Disable ftrace for the entire directory > ccflags-remove-$(CONFIG_FUNCTION_TRACER) += $(CC_FLAGS_FTRACE) > > -ifdef CONFIG_CC_IS_CLANG > -# clang stores addresses on the stack causing the frame size to blow > -# out. See https://github.com/ClangBuiltLinux/linux/issues/252 > -KBUILD_CFLAGS += -Wframe-larger-than=4096 > -endif > - > ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC) > > obj-y+= xmon.o nonstdio.o spr_access.o xmon_bpts.o > > --- > base-commit: 16931859a6500d360b90aeacab3b505a3560a3ed > change-id: 20230817-ppc_xmon-d288d803610e > > Best regards, > -- > Nick Desaulniers >
Re: [PATCH v6 21/38] powerpc: Implement the new page table range API
Hi Matthew,
On Wed, Aug 02, 2023 at 04:13:49PM +0100, Matthew Wilcox (Oracle) wrote:
> Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
> Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
> per-folio.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Acked-by: Mike Rapoport (IBM)
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: linuxppc-dev@lists.ozlabs.org
...
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index d16d80ad2ae4..b4da8514af43 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -894,7 +894,7 @@ void kvmppc_init_lpid(unsigned long nr_lpids);
>
> static inline void kvmppc_mmu_flush_icache(kvm_pfn_t pfn)
> {
> - struct page *page;
> + struct folio *folio;
> /*
>* We can only access pages that the kernel maps
>* as memory. Bail out for unmapped ones.
> @@ -903,10 +903,10 @@ static inline void kvmppc_mmu_flush_icache(kvm_pfn_t
> pfn)
> return;
>
> /* Clear i-cache for new pages */
> - page = pfn_to_page(pfn);
> - if (!test_bit(PG_dcache_clean, &page->flags)) {
> - flush_dcache_icache_page(page);
> - set_bit(PG_dcache_clean, &page->flags);
> + folio = page_folio(pfn_to_page(pfn));
> + if (!test_bit(PG_dcache_clean, &folio->flags)) {
> + flush_dcache_icache_folio(folio);
> + set_bit(PG_dcache_clean, &folio->flags);
> }
> }
...
> diff --git a/arch/powerpc/mm/cacheflush.c b/arch/powerpc/mm/cacheflush.c
> index 0e9b4879c0f9..8760d2223abe 100644
> --- a/arch/powerpc/mm/cacheflush.c
> +++ b/arch/powerpc/mm/cacheflush.c
> @@ -148,44 +148,30 @@ static void __flush_dcache_icache(void *p)
> invalidate_icache_range(addr, addr + PAGE_SIZE);
> }
>
> -static void flush_dcache_icache_hugepage(struct page *page)
> +void flush_dcache_icache_folio(struct folio *folio)
> {
> - int i;
> - int nr = compound_nr(page);
> + unsigned int i, nr = folio_nr_pages(folio);
>
> - if (!PageHighMem(page)) {
> + if (flush_coherent_icache())
> + return;
> +
> + if (!folio_test_highmem(folio)) {
> + void *addr = folio_address(folio);
> for (i = 0; i < nr; i++)
> - __flush_dcache_icache(lowmem_page_address(page + i));
> - } else {
> + __flush_dcache_icache(addr + i * PAGE_SIZE);
> + } else if (IS_ENABLED(CONFIG_BOOKE) || sizeof(phys_addr_t) >
> sizeof(void *)) {
> for (i = 0; i < nr; i++) {
> - void *start = kmap_local_page(page + i);
> + void *start = kmap_local_folio(folio, i * PAGE_SIZE);
>
> __flush_dcache_icache(start);
> kunmap_local(start);
> }
> - }
> -}
> -
> -void flush_dcache_icache_page(struct page *page)
> -{
> - if (flush_coherent_icache())
> - return;
> -
> - if (PageCompound(page))
> - return flush_dcache_icache_hugepage(page);
> -
> - if (!PageHighMem(page)) {
> - __flush_dcache_icache(lowmem_page_address(page));
> - } else if (IS_ENABLED(CONFIG_BOOKE) || sizeof(phys_addr_t) >
> sizeof(void *)) {
> - void *start = kmap_local_page(page);
> -
> - __flush_dcache_icache(start);
> - kunmap_local(start);
> } else {
> - flush_dcache_icache_phys(page_to_phys(page));
> + unsigned long pfn = folio_pfn(folio);
> + for (i = 0; i < nr; i++)
> + flush_dcache_icache_phys((pfn + i) * PAGE_SIZE);
> }
> }
> -EXPORT_SYMBOL(flush_dcache_icache_page);
Apologies if this has already been fixed or reported, I searched lore
and did not find anything. The dropping of this export in combination
with the conversion above appears to cause ARCH=powerpc allmodconfig to
fail with:
ERROR: modpost: "flush_dcache_icache_folio" [arch/powerpc/kvm/kvm-pr.ko]
undefined!
I don't know if this should be re-exported or not but that does
obviously resolve the issue.
Cheers,
Nathan
Re: [PATCH v4 12/13] s390/kexec: refactor for kernel/Kconfig.kexec
Hi Eric,
On Wed, Jul 05, 2023 at 10:20:03AM -0400, Eric DeVolder wrote:
> The kexec and crash kernel options are provided in the common
> kernel/Kconfig.kexec. Utilize the common options and provide
> the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
> equivalent set of KEXEC and CRASH options.
>
> NOTE: The original Kconfig has a KEXEC_SIG which depends on
> MODULE_SIG_FORMAT. However, attempts to keep the MODULE_SIG_FORMAT
> dependency (using the strategy outlined in this series, and other
> techniques) results in 'error: recursive dependency detected'
> on CRYPTO.
>
> Per Alexander Gordeev : "the MODULE_SIG_FORMAT
> dependency was introduced with [git commit below] and in fact was not
> necessary, since s390 did/does not use mod_check_sig() anyway.
>
> commit c8424e776b09 ("MODSIGN: Export module signature definitions")
>
> MODULE_SIG_FORMAT is needed to select SYSTEM_DATA_VERIFICATION. But
> SYSTEM_DATA_VERIFICATION is also selected by FS_VERITY*, so dropping
> MODULE_SIG_FORMAT does not hurt."
>
> Therefore, the solution is to drop the MODULE_SIG_FORMAT dependency
> from KEXEC_SIG. Still results in equivalent .config files for s390.
>
> Signed-off-by: Eric DeVolder
> Acked-by: Alexander Gordeev
> ---
> arch/s390/Kconfig | 65 ++-
> 1 file changed, 19 insertions(+), 46 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 5b39918b7042..5d4fbbfdd1cd 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -244,6 +244,25 @@ config PGTABLE_LEVELS
>
> source "kernel/livepatch/Kconfig"
>
> +config ARCH_DEFAULT_KEXEC
> + def_bool y
> +
> +config ARCH_SUPPORTS_KEXEC
> + def_bool y
> +
> +config ARCH_SUPPORTS_KEXEC_FILE
> + def_bool CRYPTO && CRYPTO_SHA256 && CRYPTO_SHA256_S390
> +
> +config ARCH_HAS_KEXEC_PURGATORY
> + def_bool KEXEC_FILE
> +
> +config ARCH_SUPPORTS_CRASH_DUMP
> + def_bool y
> + help
> + Refer to for more details on
> this.
> + This option also enables s390 zfcpdump.
> + See also
> +
> menu "Processor type and features"
>
> config HAVE_MARCH_Z10_FEATURES
> @@ -482,36 +501,6 @@ config SCHED_TOPOLOGY
>
> source "kernel/Kconfig.hz"
>
> -config KEXEC
> - def_bool y
> - select KEXEC_CORE
> -
> -config KEXEC_FILE
> - bool "kexec file based system call"
> - select KEXEC_CORE
> - depends on CRYPTO
> - depends on CRYPTO_SHA256
> - depends on CRYPTO_SHA256_S390
> - help
> - Enable the kexec file based system call. In contrast to the normal
> - kexec system call this system call takes file descriptors for the
> - kernel and initramfs as arguments.
> -
> -config ARCH_HAS_KEXEC_PURGATORY
> - def_bool y
> - depends on KEXEC_FILE
> -
> -config KEXEC_SIG
> - bool "Verify kernel signature during kexec_file_load() syscall"
> - depends on KEXEC_FILE && MODULE_SIG_FORMAT
> - help
> - This option makes kernel signature verification mandatory for
> - the kexec_file_load() syscall.
> -
> - In addition to that option, you need to enable signature
> - verification for the corresponding kernel image type being
> - loaded in order for this to work.
> -
> config KERNEL_NOBP
> def_bool n
> prompt "Enable modified branch prediction for the kernel by default"
> @@ -733,22 +722,6 @@ config VFIO_AP
>
> endmenu
>
> -menu "Dump support"
> -
> -config CRASH_DUMP
> - bool "kernel crash dumps"
> - select KEXEC
> - help
> - Generate crash dump after being started by kexec.
> - Crash dump kernels are loaded in the main kernel with kexec-tools
> - into a specially reserved region and then later executed after
> - a crash by kdump/kexec.
> - Refer to for more details on
> this.
> - This option also enables s390 zfcpdump.
> - See also
> -
> -endmenu
> -
> config CCW
> def_bool y
>
> --
> 2.31.1
>
I just bisected the following build failure visible with 'ARCH=s390
allnoconfig' to this change as commit 842ce0e1dafa ("s390/kexec:
refactor for kernel/Kconfig.kexec") in -next.
arch/s390/kernel/machine_kexec.c:120:37: warning: 'struct kimage' declared
inside parameter list will not be visible outside of this definition or
declaration
120 | static bool kdump_csum_valid(struct kimage *image)
| ^~
arch/s390/kernel/machine_kexec.c:188:34: warning: 'struct kimage' declared
inside parameter list will not be visible outside of this definition or
declaration
188 | int machine_kexec_prepare(struct kimage *image)
| ^~
arch/s390/kernel/machine_kexec.c: In function 'machine_kexec_prepare':
arch/s390/kernel/machine_kexec.c:192:18: error: invalid use of undefined type
'struct kimage'
192 | if (image->type == KEXEC_TYPE_CRASH)
| ^~
arch/s390/kernel/machine_kexec.c:192:
Re: [PATCH v2 07/23] mips: update_mmu_cache() can replace __update_tlb()
On Wed, Jun 14, 2023 at 10:43:30PM -0700, Hugh Dickins wrote:
> On Wed, 14 Jun 2023, Hugh Dickins wrote:
> > On Wed, 14 Jun 2023, Nathan Chancellor wrote:
> > >
> > > I just bisected a crash while powering down a MIPS machine in QEMU to
> > > this change as commit 8044511d3893 ("mips: update_mmu_cache() can
> > > replace __update_tlb()") in linux-next.
> >
> > Thank you, Nathan, that's very helpful indeed. This patch certainly knew
> > that it wanted testing, and I'm glad to hear that it is now seeing some.
> >
> > While powering down? The messages below look like it was just coming up,
> > but no doubt that's because you were bisecting (or because I'm unfamiliar
> > with what messages to expect there). It's probably irrelevant information,
> > but I wonder whether the (V)machine worked well enough for a while before
> > you first powered down and spotted the problem, or whether it's never got
> > much further than trying to run init (busybox)? I'm trying to get a feel
> > for whether the problem occurs under common or uncommon conditions.
Ugh sorry, I have been looking into too many bugs lately and got my
wires crossed :) this is indeed a problem when running init (which is
busybox, this is a simple Buildroot file system).
> > > Unfortunately, I can still
> > > reproduce it with the existing fix you have for this change on the
> > > mailing list, which is present in next-20230614.
> >
> > Right, that later fix was only for a build warning, nothing functional
> > (or at least I hoped that it wasn't making any functional difference).
> >
> > Thanks a lot for the detailed instructions below: unfortunately, those
> > would draw me into a realm of testing I've never needed to enter before,
> > so a lot of time spent on setup and learning. Usually, I just stare at
> > the source.
> >
> > What this probably says is that I should revert most my cleanup there,
> > and keep as close to the existing code as possible. But some change is
> > needed, and I may need to understand (or have a good guess at) what was
> > going wrong, to decide what kind of retreat will be successful.
> >
> > Back to the source for a while: I hope I'll find examples in nearby MIPS
> > kernel source (and git history), which will hint at the right way forward.
> > Then send you a patch against next-20230614 to try, when I'm reasonably
> > confident that it's enough to satisfy my purpose, but likely not to waste
> > your time.
>
> I'm going to take advantage of your good nature by attaching
> two alternative patches, either to go on top of next-20230614.
>
> mips1.patch,
> arch/mips/mm/tlb-r4k.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> is by far my favourite. I couldn't see anything wrong with what's
> already there for mips, but it seems possible that (though I didn't
> find it) somewhere calls update_mmu_cache_pmd() on a page table. So
> mips1.patch restores the pmd_huge() check, and cleans up further by
> removing the silly pgdp, p4dp, pudp, pmdp stuff: the pointer has now
> been passed in by the caller, why walk the tree again? I should have
> done it this way before.
>
> But if that doesn't work, then I'm afraid it will have to be
> mips2.patch,
> arch/mips/include/asm/pgtable.h | 15 ---
> arch/mips/mm/tlb-r3k.c |5 ++---
> arch/mips/mm/tlb-r4k.c | 27 ++-
> 3 files changed, 32 insertions(+), 15 deletions(-)
>
> which reverts all of the original patch and its build warning fix,
> and does a pte_unmap() to balance the silly pte_offset_map() there;
> with an apologetic comment for this being about the only place in
> the tree where I have no idea what to do if ptep were NULL.
>
> I do hope that you find the first fixes the breakage; but if not, then
I hate to be the bearer of bad news but the first patch did not fix the
breakage, I see the same issue.
> I even more fervently hope that the second will, despite my hating it.
> Touch wood for the first, fingers crossed for the second, thanks,
Thankfully, the second one does. Thanks for the quick and thoughtful
responses!
Cheers,
Nathan
Re: [PATCH v2 07/23] mips: update_mmu_cache() can replace __update_tlb()
Hi Hugh,
On Thu, Jun 08, 2023 at 12:17:24PM -0700, Hugh Dickins wrote:
> Don't make update_mmu_cache() a wrapper around __update_tlb(): call it
> directly, and use the ptep (or pmdp) provided by the caller, instead of
> re-calling pte_offset_map() - which would raise a question of whether a
> pte_unmap() is needed to balance it.
>
> Check whether the "ptep" provided by the caller is actually the pmdp,
> instead of testing pmd_huge(): or test pmd_huge() too and warn if it
> disagrees? This is "hazardous" territory: needs review and testing.
>
> Signed-off-by: Hugh Dickins
> ---
> arch/mips/include/asm/pgtable.h | 15 +++
> arch/mips/mm/tlb-r3k.c | 5 +++--
> arch/mips/mm/tlb-r4k.c | 9 +++--
> 3 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> index 574fa14ac8b2..9175dfab08d5 100644
> --- a/arch/mips/include/asm/pgtable.h
> +++ b/arch/mips/include/asm/pgtable.h
> @@ -565,15 +565,8 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
> }
> #endif
>
> -extern void __update_tlb(struct vm_area_struct *vma, unsigned long address,
> - pte_t pte);
> -
> -static inline void update_mmu_cache(struct vm_area_struct *vma,
> - unsigned long address, pte_t *ptep)
> -{
> - pte_t pte = *ptep;
> - __update_tlb(vma, address, pte);
> -}
> +extern void update_mmu_cache(struct vm_area_struct *vma,
> + unsigned long address, pte_t *ptep);
>
> #define __HAVE_ARCH_UPDATE_MMU_TLB
> #define update_mmu_tlb update_mmu_cache
> @@ -581,9 +574,7 @@ static inline void update_mmu_cache(struct vm_area_struct
> *vma,
> static inline void update_mmu_cache_pmd(struct vm_area_struct *vma,
> unsigned long address, pmd_t *pmdp)
> {
> - pte_t pte = *(pte_t *)pmdp;
> -
> - __update_tlb(vma, address, pte);
> + update_mmu_cache(vma, address, (pte_t *)pmdp);
> }
>
> /*
> diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
> index 53dfa2b9316b..e5722cd8dd6d 100644
> --- a/arch/mips/mm/tlb-r3k.c
> +++ b/arch/mips/mm/tlb-r3k.c
> @@ -176,7 +176,8 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
> unsigned long page)
> }
> }
>
> -void __update_tlb(struct vm_area_struct *vma, unsigned long address, pte_t
> pte)
> +void update_mmu_cache(struct vm_area_struct *vma,
> + unsigned long address, pte_t *ptep)
> {
> unsigned long asid_mask = cpu_asid_mask(¤t_cpu_data);
> unsigned long flags;
> @@ -203,7 +204,7 @@ void __update_tlb(struct vm_area_struct *vma, unsigned
> long address, pte_t pte)
> BARRIER;
> tlb_probe();
> idx = read_c0_index();
> - write_c0_entrylo0(pte_val(pte));
> + write_c0_entrylo0(pte_val(*ptep));
> write_c0_entryhi(address | pid);
> if (idx < 0) { /* BARRIER */
> tlb_write_random();
> diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
> index 1b939abbe4ca..c96725d17cab 100644
> --- a/arch/mips/mm/tlb-r4k.c
> +++ b/arch/mips/mm/tlb-r4k.c
> @@ -290,14 +290,14 @@ void local_flush_tlb_one(unsigned long page)
> * updates the TLB with the new pte(s), and another which also checks
> * for the R4k "end of page" hardware bug and does the needy.
> */
> -void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t
> pte)
> +void update_mmu_cache(struct vm_area_struct *vma,
> + unsigned long address, pte_t *ptep)
> {
> unsigned long flags;
> pgd_t *pgdp;
> p4d_t *p4dp;
> pud_t *pudp;
> pmd_t *pmdp;
> - pte_t *ptep;
> int idx, pid;
>
> /*
> @@ -326,10 +326,9 @@ void __update_tlb(struct vm_area_struct * vma, unsigned
> long address, pte_t pte)
> idx = read_c0_index();
> #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT
> /* this could be a huge page */
> - if (pmd_huge(*pmdp)) {
> + if (ptep == (pte_t *)pmdp) {
> unsigned long lo;
> write_c0_pagemask(PM_HUGE_MASK);
> - ptep = (pte_t *)pmdp;
> lo = pte_to_entrylo(pte_val(*ptep));
> write_c0_entrylo0(lo);
> write_c0_entrylo1(lo + (HPAGE_SIZE >> 7));
> @@ -344,8 +343,6 @@ void __update_tlb(struct vm_area_struct * vma, unsigned
> long address, pte_t pte)
> } else
> #endif
> {
> - ptep = pte_offset_map(pmdp, address);
> -
> #if defined(CONFIG_PHYS_ADDR_T_64BIT) && defined(CONFIG_CPU_MIPS32)
> #ifdef CONFIG_XPA
> write_c0_entrylo0(pte_to_entrylo(ptep->pte_high));
> --
> 2.35.3
>
I just bisected a crash while powering down a MIPS machine in QEMU to
this change as commit 8044511d3893 ("mips: update_mmu_cache() can
replace __update_tlb()") in linux-next. Unfortunately, I can still
reproduce it with the existing fix you have for this change on the
mailing list, which is present in next-20230614.
I can reproduce it with the GCC 13.1.0 on kernel.org [1]
Re: [PATCH 1/4] powerpc/64: Force ELFv2 when building with LLVM linker
Hi Nick, + our mailing list, helps with review and making sure that we are not missing anything :) On Fri, May 05, 2023 at 05:18:47PM +1000, Nicholas Piggin wrote: > The LLVM linker does not support ELFv1 at all, so BE kernels must be > built with ELFv2. The LLD version check was added to be conservative, > but previous LLD versions would simply fail to link ELFv1 entirely. The > only would be to require LLD >= 15 for BE builds, but let's instead > remove that restriction until proven otherwise (LLD 14.0 links a booting > ELFv2 BE vmlinux for me). > > The minimum binutils has increased such that ELFv2 is always supported, > so remove that check while we're here. > > Cc: Nathan Chancellor > Signed-off-by: Nicholas Piggin Thanks for this change! I ran it through my (admittedly limited set of) build tests with LD=ld.lld for big endian configurations and I saw no build errors with LLVM 11.1.0 through 16.0.3 (and currently, a 17.0.0 built from main); my simple QEMU boot testing passed as well. Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor One small comment below. > --- > arch/powerpc/Kconfig | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index acbd5d77..e5d81645c902 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -624,10 +624,11 @@ config ARCH_HAS_KEXEC_PURGATORY > def_bool KEXEC_FILE > > config PPC64_BIG_ENDIAN_ELF_ABI_V2 > - bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" > + prompt "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if > LD_IS_BFD > + bool This could be bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)" if LD_IS_BFD which is the syntactic sugar equivalent of what you already have. The rest looks good to me. > + default y if LD_IS_LLD > depends on PPC64 && CPU_BIG_ENDIAN > depends on CC_HAS_ELFV2 > - depends on LD_VERSION >= 22400 || LLD_VERSION >= 15 > help > This builds the kernel image using the "Power Architecture 64-Bit ELF > V2 ABI Specification", which has a reduced stack overhead and faster > @@ -638,8 +639,6 @@ config PPC64_BIG_ENDIAN_ELF_ABI_V2 > it is less well tested by kernel and toolchain. However some distros > build userspace this way, and it can produce a functioning kernel. > > - This requires GCC and binutils 2.24 or newer. > - > config RELOCATABLE > bool "Build a relocatable kernel" > depends on PPC64 || (FLATMEM && (44x || PPC_85xx)) > -- > 2.40.1 >
[PATCH] powerpc/boot: Disable power10 features after BOOTAFLAGS assignment
When building the boot wrapper assembly files with clang after
commit 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation
with CONFIG_POWER10_CPU"), the following warnings appear for each file
built:
'-prefixed' is not a recognized feature for this target (ignoring feature)
'-pcrel' is not a recognized feature for this target (ignoring feature)
While it is questionable whether or not LLVM should be emitting a
warning when passed negative versions of code generation flags when
building assembly files (since it does not emit a warning for the
altivec and vsx flags), it is easy enough to work around this by just
moving the disabled flags to BOOTCFLAGS after the assignment of
BOOTAFLAGS, so that they are not added when building assembly files.
Do so to silence the warnings.
Cc: sta...@vger.kernel.org
Fixes: 648a1783fe25 ("powerpc/boot: Fix boot wrapper code generation with
CONFIG_POWER10_CPU")
Link: https://github.com/ClangBuiltLinux/linux/issues/1839
Reviewed-by: Nicholas Piggin
Signed-off-by: Nathan Chancellor
---
I do not think that 648a1783fe25 is truly to blame for this but the
Fixes tag will help the stable team ensure that this change gets
backported with 648a1783fe25. This is the minimal fix for the problem
but the true fix is separating AFLAGS and CFLAGS, which should be done
by this in-flight series by Nick:
https://lore.kernel.org/20230426055848.402993-1-npig...@gmail.com/
---
arch/powerpc/boot/Makefile | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 85cde5bf04b7..771b79423bbc 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -34,8 +34,6 @@ endif
BOOTCFLAGS:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \
-$(call cc-option,-mno-prefixed) $(call cc-option,-mno-pcrel) \
-$(call cc-option,-mno-mma) \
$(call cc-option,-mno-spe) $(call cc-option,-mspe=no) \
-pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
$(LINUXINCLUDE)
@@ -71,6 +69,10 @@ BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc
BOOTARFLAGS:= -crD
+BOOTCFLAGS += $(call cc-option,-mno-prefixed) \
+ $(call cc-option,-mno-pcrel) \
+ $(call cc-option,-mno-mma)
+
ifdef CONFIG_CC_IS_CLANG
BOOTCFLAGS += $(CLANG_FLAGS)
BOOTAFLAGS += $(CLANG_FLAGS)
---
base-commit: 169f8997968ab620d750d9a45e15c5288d498356
change-id: 20230427-remove-power10-args-from-boot-aflags-clang-268c43e8c1fc
Best regards,
--
Nathan Chancellor
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Tue, Apr 18, 2023 at 07:25:00PM +0100, Mark Brown wrote:
> On Tue, Apr 18, 2023 at 11:21:45AM -0700, Nathan Chancellor wrote:
> > On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote:
>
> > > Done.
>
> > Thanks a lot, sorry for not saying it sooner! It looks like this
> > regressed in next-20230417 and next-20230418 though.
>
> Someone sent a mail saying they thought they'd fixed the DRM tree - is
> that not the case?
Does not seem like it:
$ git show -s --format='%h ("%s")'
67d5d9f013d6 ("Add linux-next specific files for 20230418")
$ git grep DRM_AMD_DC_DCN
drivers/gpu/drm/amd/display/Kconfig:select DRM_AMD_DC_DCN if (X86 || (PPC64
&& ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
Cheers,
Nathan
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote: > On Thu, Apr 13, 2023 at 11:47:25AM -0700, Nathan Chancellor wrote: > > On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote: > > > select SND_HDA_COMPONENT if SND_HDA_CORE > > # !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752 > > - select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > > KERNEL_MODE_NEON && !CC_IS_CLANG)) > > + select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > > KERNEL_MODE_NEON && !CC_IS_CLANG)) > > help > > Choose this option if you want to use the new display engine > > support for AMDGPU. This adds required support for Vega and > > > Please consider resolving this in a future -next update, I was rather > > surprised that my AMD test machine's graphical output was not working > > until I noticed the configuration difference :) > > Done. Thanks a lot, sorry for not saying it sooner! It looks like this regressed in next-20230417 and next-20230418 though. Cheers, Nathan
Re: linux-next: manual merge of the drm tree with the powerpc tree
Hi Mark,
On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/Kconfig
>
> between commit:
>
> 78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
>
> from the powerpc tree and commit:
>
> 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
>
> from the drm tree.
>
> I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
> and can carry the fix as necessary. This is now fixed as far as
> linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
This resolution is not quite right on next-20230412 and next-20230413,
as the drm tree's rename was not taken into account on the conflicting
line. In other words, I need this diff for everything to work properly.
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index b990ef80d686..2d8e55e29637 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
Please consider resolving this in a future -next update, I was rather
surprised that my AMD test machine's graphical output was not working
until I noticed the configuration difference :)
Cheers,
Nathan
Re: [PATCH 2/2] start_kernel: omit prevent_tail_call_optimization for newer toolchains
On Wed, Apr 12, 2023 at 11:32:13AM -0700, ndesaulni...@google.com wrote:
> prevent_tail_call_optimization was added in
> commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
> to work around stack canaries getting inserted into functions that would
> initialize the stack canary in the first place.
>
> Now that we have no_stack_protector function attribute (gcc-11+,
> clang-7+) and use it on start_kernel, remove the call to
> prevent_tail_call_optimization such that we may one day remove it
> outright.
>
> Signed-off-by: Nick Desaulniers
Reviewed-by: Nathan Chancellor
> ---
> init/main.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index 213baf7b8cb1..c8503d02dfa6 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1152,7 +1152,12 @@ void start_kernel(void)
> /* Do the rest non-__init'ed, we're now alive */
> arch_call_rest_init();
>
> + /* Avoid stack canaries in callers of boot_init_stack_canary for gcc-10
> + * and older.
> + */
> +#if !__has_attribute(__no_stack_protector__)
> prevent_tail_call_optimization();
> +#endif
> }
>
> /* Call all constructor functions linked into the kernel. */
>
> --
> 2.40.0.577.gac1e443424-goog
>
Re: [PATCH 1/2] start_kernel: add no_stack_protector fn attr
On Wed, Apr 12, 2023 at 11:32:12AM -0700, ndesaulni...@google.com wrote:
> Back during the discussion of
> commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
> we discussed the need for a function attribute to control the omission
> of stack protectors on a per-function basis; at the time Clang had
> support for no_stack_protector but GCC did not. This was fixed in
> gcc-11. Now that the function attribute is available, let's start using
> it.
>
> Callers of boot_init_stack_canary need to use this function attribute
> unless they're compiled with -fno-stack-protector, otherwise the canary
> stored in the stack slot of the caller will differ upon the call to
> boot_init_stack_canary. This will lead to a call to __stack_chk_fail
> then panic.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
> Link:
> https://lore.kernel.org/all/20200316130414.gc12...@hirez.programming.kicks-ass.net/
> Signed-off-by: Nick Desaulniers
I applied this in front of Josh's series and defconfig no longer panics
on boot :)
Tested-by: Nathan Chancellor
> ---
> arch/powerpc/kernel/smp.c | 1 +
> include/linux/compiler_attributes.h | 12
> init/main.c | 3 ++-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 6b90f10a6c81..7d4c12b1abb7 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1603,6 +1603,7 @@ static void add_cpu_to_masks(int cpu)
> }
>
> /* Activate a secondary processor. */
> +__no_stack_protector
> void start_secondary(void *unused)
> {
> unsigned int cpu = raw_smp_processor_id();
> diff --git a/include/linux/compiler_attributes.h
> b/include/linux/compiler_attributes.h
> index e659cb6fded3..84864767a56a 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -255,6 +255,18 @@
> */
> #define __noreturn __attribute__((__noreturn__))
>
> +/*
> + * Optional: only supported since GCC >= 11.1, clang >= 7.0.
> + *
> + * gcc:
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-no_005fstack_005fprotector-function-attribute
> + * clang:
> https://clang.llvm.org/docs/AttributeReference.html#no-stack-protector-safebuffers
> + */
> +#if __has_attribute(__no_stack_protector__)
> +# define __no_stack_protector
> __attribute__((__no_stack_protector__))
> +#else
> +# define __no_stack_protector
> +#endif
> +
> /*
> * Optional: not supported by gcc.
> *
> diff --git a/init/main.c b/init/main.c
> index bb87b789c543..213baf7b8cb1 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -941,7 +941,8 @@ static void __init print_unknown_bootoptions(void)
> memblock_free(unknown_options, len);
> }
>
> -asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
> +asmlinkage __visible __init __no_sanitize_address __no_stack_protector
> +void start_kernel(void)
> {
> char *command_line;
> char *after_dashes;
>
> --
> 2.40.0.577.gac1e443424-goog
>
>
Re: arch/powerpc/kvm/../kernel/head_booke.h:20:6: warning: "THREAD_SHIFT" is not defined, evaluates to 0
On Fri, Apr 07, 2023 at 04:08:43PM -0700, Nick Desaulniers wrote: > On Tue, Apr 4, 2023 at 6:29 PM kernel test robot wrote: > > > > Hi Masahiro, > > > > FYI, the error/warning still remains. > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > head: 76f598ba7d8e2bfb4855b5298caedd5af0c374a8 > > commit: 80b6093b55e31c2c40ff082fb32523d4e852954f kbuild: add -Wundef to > > KBUILD_CPPFLAGS for W=1 builds > > date: 4 months ago > > config: powerpc-buildonly-randconfig-r003-20230405 > > (https://download.01.org/0day-ci/archive/20230405/202304050954.yskldczh-...@intel.com/config) > > compiler: powerpc-linux-gcc (GCC) 12.1.0 > > reproduce (this is a W=1 build): > > wget > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > > ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80b6093b55e31c2c40ff082fb32523d4e852954f > > git remote add linus > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git fetch --no-tags linus master > > git checkout 80b6093b55e31c2c40ff082fb32523d4e852954f > > # save the config file > > mkdir build_dir && cp config build_dir/.config > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 > > O=build_dir ARCH=powerpc olddefconfig > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 > > O=build_dir ARCH=powerpc SHELL=/bin/bash arch/powerpc/kernel/ > > arch/powerpc/kvm/ virt/ > > > > If you fix the issue, kindly add following tag where applicable > > | Reported-by: kernel test robot > > | Link: > > https://lore.kernel.org/oe-kbuild-all/202304050954.yskldczh-...@intel.com/ > > > > All warnings (new ones prefixed by >>): > > > >In file included from arch/powerpc/kvm/bookehv_interrupts.S:26: > > >> arch/powerpc/kvm/../kernel/head_booke.h:20:6: warning: "THREAD_SHIFT" is > > >> not defined, evaluates to 0 [-Wundef] > > 20 | #if (THREAD_SHIFT < 15) > > | ^~~~ > > Should arch/powerpc/kernel/head_booke.h be #include'ing > asm/thread_info.h before using THREAD_SHIFT? I think so, sorry for not cc'ing you on https://lore.kernel.org/linuxppc-dev/20230406-wundef-thread_shift_booke-v1-1-8deffa4d8...@kernel.org/ > > > > > > vim +/THREAD_SHIFT +20 arch/powerpc/kvm/../kernel/head_booke.h > > > > 1a4b739bbb4f88 Christophe Leroy 2019-04-30 10 > > 63dafe5728e735 Becky Bruce 2006-01-14 11 /* > > 63dafe5728e735 Becky Bruce 2006-01-14 12 * Macros used for common > > Book-e exception handling > > 63dafe5728e735 Becky Bruce 2006-01-14 13 */ > > 63dafe5728e735 Becky Bruce 2006-01-14 14 > > 63dafe5728e735 Becky Bruce 2006-01-14 15 #define > > SET_IVOR(vector_number, vector_label) \ > > 63dafe5728e735 Becky Bruce 2006-01-14 16 li > > r26,vector_label@l; \ > > 63dafe5728e735 Becky Bruce 2006-01-14 17 mtspr > > SPRN_IVOR##vector_number,r26; \ > > 63dafe5728e735 Becky Bruce 2006-01-14 18 sync > > 63dafe5728e735 Becky Bruce 2006-01-14 19 > > e12401222f749c Yuri Tikhonov2009-01-29 @20 #if (THREAD_SHIFT < 15) > > e12401222f749c Yuri Tikhonov2009-01-29 21 #define > > ALLOC_STACK_FRAME(reg, val) \ > > e12401222f749c Yuri Tikhonov2009-01-29 22 addi reg,reg,val > > e12401222f749c Yuri Tikhonov2009-01-29 23 #else > > e12401222f749c Yuri Tikhonov2009-01-29 24 #define > > ALLOC_STACK_FRAME(reg, val) \ > > e12401222f749c Yuri Tikhonov2009-01-29 25 addis > > reg,reg,val@ha; \ > > e12401222f749c Yuri Tikhonov2009-01-29 26 addi > > reg,reg,val@l > > e12401222f749c Yuri Tikhonov2009-01-29 27 #endif > > e12401222f749c Yuri Tikhonov2009-01-29 28 > > > > :: The code at line 20 was first introduced by commit > > :: e12401222f749c37277a313d631dc024bbfd3b00 powerpc/44x: Support for > > 256KB PAGE_SIZE > > > > :: TO: Yuri Tikhonov > > :: CC: Josh Boyer > > > > -- > > 0-DAY CI Kernel Test Service > > https://github.com/intel/lkp-tests > > > > -- > Thanks, > ~Nick Desaulniers
[PATCH] powerpc/32: Include thread_info.h in head_booke.h
When building with W=1 after commit 80b6093b55e3 ("kbuild: add -Wundef
to KBUILD_CPPFLAGS for W=1 builds"), the following warning occurs.
In file included from arch/powerpc/kvm/bookehv_interrupts.S:26:
arch/powerpc/kvm/../kernel/head_booke.h:20:6: warning: "THREAD_SHIFT" is not
defined, evaluates to 0 [-Wundef]
20 | #if (THREAD_SHIFT < 15)
| ^~~~
THREAD_SHIFT is defined in thread_info.h but it is not directly included
in head_booke.h, so it is possible for THREAD_SHIFT to be undefined. Add
the include to ensure that THREAD_SHIFT is always defined.
Reported-by: kernel test robot
Link: https://lore.kernel.org/202304050954.yskldczh-...@intel.com/
Signed-off-by: Nathan Chancellor
---
arch/powerpc/kernel/head_booke.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/head_booke.h b/arch/powerpc/kernel/head_booke.h
index 37d43c172676..b6b5b01a173c 100644
--- a/arch/powerpc/kernel/head_booke.h
+++ b/arch/powerpc/kernel/head_booke.h
@@ -5,6 +5,7 @@
#include /* for STACK_FRAME_REGS_MARKER */
#include
#include
+#include/* for THREAD_SHIFT */
#ifdef __ASSEMBLY__
---
base-commit: b0bbe5a2915201e3231e788d716d39dc54493b03
change-id: 20230406-wundef-thread_shift_booke-e08d806ed656
Best regards,
--
Nathan Chancellor
Re: [PATCH 2/2] powerpc/64: Use -mtune=pwr10/9/8 for clang
On Fri, Mar 03, 2023 at 10:53:02AM +1100, Michael Ellerman wrote: > Nathan Chancellor writes: > > Hi Michael, > > > > Thanks for the workaround and sorry this has come to bite us :/ > > > > On Fri, Mar 03, 2023 at 12:16:56AM +1100, Michael Ellerman wrote: > >> For the -mtune option clang doesn't accept power10/9/8, instead it > >> accepts pwr10/9/8. That will be fixed in future versions of clang, but > >> the kernel must support the clang versions in the wild. > >> > >> So add support for the "pwr" spelling if clang is in use. > >> > >> Reported-by: Nathan Chancellor > > > > I think that should actually be > > > > Reported-by: Nick Desaulniers > > I guess yeah. > > >> BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799 > >> Signed-off-by: Michael Ellerman > > > > Reviewed-by: Nathan Chancellor > > Thanks. > > >> --- > >> arch/powerpc/platforms/Kconfig.cputype | 4 > >> 1 file changed, 4 insertions(+) > >> > >> Need to confirm the clang <= 16 statement is correct. > > > > Currently, this is indeed the case. It is possible that Nemanja's patch > > will get applied to release/16.x before 16.0.0 final but it might not. > > > > We can always update it later. I think we do want to push to get that > > patch applied because I forgot that it is only in 16.0.0 that '-mtune' > > starts to do something on PowerPC: > > > > https://github.com/llvm/llvm-project/commit/1dc26b80b872a94c581549a21943756a8c3448a3 > > > > Prior to that change, '-mtune' was accepted but did nothing. It is only > > once it was hooked up to the backend that we got the spew of warnings. I > > think that warrants us trying to get Nemanja's patch into 16.0.0, which > > may allow us to drop this workaround altogether... > > Aha OK, I missed that the warning was new in 16. > > I'll sit on this for now then until we know if that change will make it > into clang 16. It was merged into release/16.x a few hours ago: https://github.com/llvm/llvm-project/issues/61128 https://github.com/llvm/llvm-project/commit/9b2e09e9fb1aa3bbe3668d7cc585188a3014d1b9 So I think this particular workaround is no longer needed :) Cheers, Nathan
Re: [PATCH 2/2] powerpc/64: Use -mtune=pwr10/9/8 for clang
Hi Michael, Thanks for the workaround and sorry this has come to bite us :/ On Fri, Mar 03, 2023 at 12:16:56AM +1100, Michael Ellerman wrote: > For the -mtune option clang doesn't accept power10/9/8, instead it > accepts pwr10/9/8. That will be fixed in future versions of clang, but > the kernel must support the clang versions in the wild. > > So add support for the "pwr" spelling if clang is in use. > > Reported-by: Nathan Chancellor I think that should actually be Reported-by: Nick Desaulniers > BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799 > Signed-off-by: Michael Ellerman Reviewed-by: Nathan Chancellor > --- > arch/powerpc/platforms/Kconfig.cputype | 4 > 1 file changed, 4 insertions(+) > > Need to confirm the clang <= 16 statement is correct. Currently, this is indeed the case. It is possible that Nemanja's patch will get applied to release/16.x before 16.0.0 final but it might not. We can always update it later. I think we do want to push to get that patch applied because I forgot that it is only in 16.0.0 that '-mtune' starts to do something on PowerPC: https://github.com/llvm/llvm-project/commit/1dc26b80b872a94c581549a21943756a8c3448a3 Prior to that change, '-mtune' was accepted but did nothing. It is only once it was hooked up to the backend that we got the spew of warnings. I think that warrants us trying to get Nemanja's patch into 16.0.0, which may allow us to drop this workaround altogether... > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 7d7477b73951..e4e0e81be7de 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -278,6 +278,10 @@ config TUNE_CPU > default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power10) > default "-mtune=power9" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power9) > default "-mtune=power8" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power8) > + # clang <= 16 only supports the "pwr" names > + default "-mtune=pwr10" if POWERPC64_CPU && CC_IS_CLANG && > $(cc-option,-mtune=pwr10) > + default "-mtune=pwr9"if POWERPC64_CPU && CC_IS_CLANG && > $(cc-option,-mtune=pwr9) > + default "-mtune=pwr8"if POWERPC64_CPU && CC_IS_CLANG && > $(cc-option,-mtune=pwr8) > > config PPC_BOOK3S > def_bool y > -- > 2.39.2 >
Re: [PATCH 1/2] powerpc/64: Move CPU -mtune options into Kconfig
On Fri, Mar 03, 2023 at 12:16:55AM +1100, Michael Ellerman wrote: > Currently the -mtune options are set in the Makefile, depending on what > is the compiler supports. > > One downside of doing it that way is that the chosen -mtune option is > not recorded in the .config. > > Another downside is that doing more complicated logic to calculate the > correct option gets messy in the Makefile. > > So move the determination of which -mtune option to use into Kconfig > logic. > > Signed-off-by: Michael Ellerman Reviewed-by: Nathan Chancellor > --- > arch/powerpc/Makefile | 4 +--- > arch/powerpc/platforms/Kconfig.cputype | 6 ++ > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > index 87d6ac27eebd..779956007f0c 100644 > --- a/arch/powerpc/Makefile > +++ b/arch/powerpc/Makefile > @@ -156,9 +156,7 @@ endif > CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) > AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) > > -CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10, \ > - $(call cc-option,-mtune=power9, \ > - $(call cc-option,-mtune=power8))) > +CFLAGS-y += $(CONFIG_TUNE_CPU) > > asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) > > diff --git a/arch/powerpc/platforms/Kconfig.cputype > b/arch/powerpc/platforms/Kconfig.cputype > index 046b571496b1..7d7477b73951 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -273,6 +273,12 @@ config TARGET_CPU > default "e500mc" if E500MC_CPU > default "powerpc" if POWERPC_CPU > > +config TUNE_CPU > + string > + default "-mtune=power10" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power10) > + default "-mtune=power9" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power9) > + default "-mtune=power8" if POWERPC64_CPU && CC_IS_GCC && > $(cc-option,-mtune=power8) Would it be cleaner to hoist the POWERPC64_CPU dependency? config TUNE_CPU string default "-mtune=power10" if CC_IS_GCC && $(cc-option,-mtune=power10) default "-mtune=power9" if CC_IS_GCC && $(cc-option,-mtune=power9) default "-mtune=power8" if CC_IS_GCC && $(cc-option,-mtune=power8) depends on POWERPC64_CPU > + > config PPC_BOOK3S > def_bool y > depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 > -- > 2.39.2 >
Re: [PATCH] powerpc/vmlinux.lds: Add .text.asan/tsan sections
On Wed, Feb 22, 2023 at 05:00:37PM +1100, Michael Ellerman wrote:
> When KASAN/KCSAN are enabled clang generates .text.asan/tsan sections.
> Because they are not mentioned in the linker script warnings are
> generated, and when orphan handling is set to error that becomes a build
> error, eg:
>
> ld.lld: error: vmlinux.a(init/main.o):(.text.tsan.module_ctor) is
> being placed in '.text.tsan.module_ctor' ld.lld: error:
> vmlinux.a(init/version.o):(.text.tsan.module_ctor) is being placed in
> '.text.tsan.module_ctor'
>
> Fix it by adding the sections to our linker script, similar to the
> generic change made in 848378812e40 ("vmlinux.lds.h: Handle clang's
> module.{c,d}tor sections").
>
> Signed-off-by: Michael Ellerman
Indeed, I had not thought about architectures not using the TEXT_TEXT
macro.
Reviewed-by: Nathan Chancellor
> ---
> arch/powerpc/kernel/vmlinux.lds.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S
> b/arch/powerpc/kernel/vmlinux.lds.S
> index 958e77a24f85..7a2209767adf 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -125,6 +125,7 @@ SECTIONS
>* included with the main text sections, so put it by itself.
>*/
> *(.sfpr);
> + *(.text.asan.* .text.tsan.*)
> MEM_KEEP(init.text)
> MEM_KEEP(exit.text)
> } :text
> --
> 2.39.1
>
Re: [PATCH 0/3] Allow CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 with ld.lld 15+
On Mon, Feb 20, 2023 at 05:11:54PM +1100, Michael Ellerman wrote: > Nathan Chancellor writes: > > Currently, CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 is not selectable with > > ld.lld because of an explicit dependency on GNU ld, due to lack of > > testing with LLVM. > > > > Erhard was kind enough to test this option on his hardware with LLVM 15, > > which ran without any issues. This should not be too surprising, as > > ld.lld does not have support for the ELFv1 ABI, only ELFv2, so it should > > have decent support. With this series, big endian kernels can be built > > with LLVM=1. > > > > This has seen our basic set of powerpc configurations with clang-15, > > clang-16, and clang-17 but I will never be opposed to more testing :) > > > > The first two patches fix a couple of issues I noticed while build > > testing and the final patch actually allows the option to be selected. > > Thanks for this. > > I thought about applying this last week but decided not to. I'll plan to > pick it up for 6.4. No worries, I sent this much later in the development cycle than I had initially intended, so I figured that 6.3 was a long shot anyways. Plus more soak time is never a bad thing :) Thanks for taking the initial look, cheers! Nathan
[PATCH 2/3] powerpc: Fix use of '-mabi=elfv2' with clang
'-mabi=elfv2' is not added to clang's invocations when
CONFIG_PPC64_ELF_ABI_V2 is enabled, resulting in the generation of elfv1
code, as evidenced by the orphan section warnings/errors:
ld.lld: error: vmlinux.a(arch/powerpc/kernel/prom_init.o):(.opd) is being
placed in '.opd'
ld.lld: error: vmlinux.a(init/main.o):(.opd) is being placed in '.opd'
ld.lld: error: vmlinux.a(init/version.o):(.opd) is being placed in '.opd'
To resolve this, add '-mabi=elfv2' to CFLAGS with clang. This uncovers
an issue in the 32-bit vDSO:
error: unknown target ABI 'elfv2'
The ELFv2 ABI cannot be used when building code for a 32-bit target. To
resolve this, just remove the '-mabi' flags from the assembler flags, as
it was only needed for preprocessing (the _CALL_ELF macro) but this was
cleaned up in commit 5b89492c03e5 ("powerpc: Finalise cleanup around ABI
use").
Tested-by: "Erhard F."
---
arch/powerpc/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..3f2dd930e3cd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -123,14 +123,12 @@ endif
endif
CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
-ifndef CONFIG_CC_IS_CLANG
ifdef CONFIG_PPC64_ELF_ABI_V2
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call
cc-option,-mcall-aixdesc))
-AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2)
else
+ifndef CONFIG_CC_IS_CLANG
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc)
-AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1)
endif
endif
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call
cc-option,-mminimal-toc))
--
2.39.2
[PATCH 3/3] powerpc: Allow CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 with ld.lld 15+
Commit 5017b4594672 ("powerpc/64: Option to build big-endian with ELFv2
ABI") restricted the ELFv2 ABI configuration such that it can only be
selected when linking with ld.bfd, due to lack of testing with LLVM.
ld.lld can link ELFv2 kernels without any issues; in fact, it is the
only ABI that ld.lld supports, as ELFv1 is not supported in ld.lld.
As this has not seen a ton of real world testing yet, be conservative
and only allow this option to be selected with the latest stable release
of LLVM (15.x) and newer.
While in the area, remove 'default n', as it is unnecessary to specify
it explicitly since all boolean/tristate configuration symbols default
to n.
Tested-by: "Erhard F."
---
arch/powerpc/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b8c4ac56bddc..f9f13029c98a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -603,8 +603,7 @@ config PPC64_BIG_ENDIAN_ELF_ABI_V2
bool "Build big-endian kernel using ELF ABI V2 (EXPERIMENTAL)"
depends on PPC64 && CPU_BIG_ENDIAN
depends on CC_HAS_ELFV2
- depends on LD_IS_BFD && LD_VERSION >= 22400
- default n
+ depends on LD_VERSION >= 22400 || LLD_VERSION >= 15
help
This builds the kernel image using the "Power Architecture 64-Bit ELF
V2 ABI Specification", which has a reduced stack overhead and faster
--
2.39.2
[PATCH 1/3] powerpc/boot: Only use '-mabi=elfv2' with CONFIG_PPC64_BOOT_WRAPPER
When CONFIG_PPC64_ELF_ABI_V2 is enabled with clang through CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2, building the powerpc boot wrapper in 32-bit mode (i.e. with CONFIG_PPC64_BOOT_WRAPPER=n) fails with: error: unknown target ABI 'elfv2' The ABI cannot be changed with '-m32'; GCC silently accepts it but clang errors out. Only provide '-mabi=elfv2' when CONFIG_PPC64_BOOT_WRAPPER is enabled, which is the only way '-mabi=elfv2' will be useful. Tested-by: "Erhard F." Signed-off-by: Nathan Chancellor --- arch/powerpc/boot/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index d32d95aea5d6..0d4a8e8bdcab 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -44,6 +44,9 @@ BOOTCFLAGS+= -m64 -mcpu=powerpc64le else BOOTCFLAGS += -m64 -mcpu=powerpc64 endif +ifdef CONFIG_PPC64_ELF_ABI_V2 +BOOTCFLAGS += $(call cc-option,-mabi=elfv2) +endif else BOOTCFLAGS += -m32 -mcpu=powerpc endif @@ -55,9 +58,6 @@ BOOTCFLAGS+= -mbig-endian else BOOTCFLAGS += -mlittle-endian endif -ifdef CONFIG_PPC64_ELF_ABI_V2 -BOOTCFLAGS += $(call cc-option,-mabi=elfv2) -endif BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -nostdinc -- 2.39.2
[PATCH 0/3] Allow CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 with ld.lld 15+
Currently, CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 is not selectable with ld.lld because of an explicit dependency on GNU ld, due to lack of testing with LLVM. Erhard was kind enough to test this option on his hardware with LLVM 15, which ran without any issues. This should not be too surprising, as ld.lld does not have support for the ELFv1 ABI, only ELFv2, so it should have decent support. With this series, big endian kernels can be built with LLVM=1. This has seen our basic set of powerpc configurations with clang-15, clang-16, and clang-17 but I will never be opposed to more testing :) The first two patches fix a couple of issues I noticed while build testing and the final patch actually allows the option to be selected. --- Nathan Chancellor (3): powerpc/boot: Only use '-mabi=elfv2' with CONFIG_PPC64_BOOT_WRAPPER powerpc: Fix use of '-mabi=elfv2' with clang powerpc: Allow CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2 with ld.lld 15+ arch/powerpc/Kconfig | 3 +-- arch/powerpc/Makefile | 4 +--- arch/powerpc/boot/Makefile | 6 +++--- 3 files changed, 5 insertions(+), 8 deletions(-) --- base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4 change-id: 20230118-ppc64-elfv2-llvm-39edac67bf0a Best regards, -- Nathan Chancellor
[PATCH] macintosh: windfarm: Use unsigned type for 1-bit bitfields
Clang warns:
drivers/macintosh/windfarm_lm75_sensor.c:63:14: error: implicit truncation
from 'int' to a one-bit wide bit-field changes value from 1 to -1
[-Werror,-Wsingle-bit-bitfield-constant-conversion]
lm->inited = 1;
^ ~
drivers/macintosh/windfarm_smu_sensors.c:356:19: error: implicit truncation
from 'int' to a one-bit wide bit-field changes value from 1 to -1
[-Werror,-Wsingle-bit-bitfield-constant-conversion]
pow->fake_volts = 1;
^ ~
drivers/macintosh/windfarm_smu_sensors.c:368:18: error: implicit truncation
from 'int' to a one-bit wide bit-field changes value from 1 to -1
[-Werror,-Wsingle-bit-bitfield-constant-conversion]
pow->quadratic = 1;
^ ~
There is no bug here since no code checks the actual value of these
fields, just whether or not they are zero (boolean context), but this
can be easily fixed by switching to an unsigned type.
Signed-off-by: Nathan Chancellor
---
drivers/macintosh/windfarm_lm75_sensor.c | 4 ++--
drivers/macintosh/windfarm_smu_sensors.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/macintosh/windfarm_lm75_sensor.c
b/drivers/macintosh/windfarm_lm75_sensor.c
index 24f0a444d312..9c6febce2376 100644
--- a/drivers/macintosh/windfarm_lm75_sensor.c
+++ b/drivers/macintosh/windfarm_lm75_sensor.c
@@ -33,8 +33,8 @@
#endif
struct wf_lm75_sensor {
- int ds1775 : 1;
- int inited : 1;
+ unsigned intds1775 : 1;
+ unsigned intinited : 1;
struct i2c_client *i2c;
struct wf_sensorsens;
};
diff --git a/drivers/macintosh/windfarm_smu_sensors.c
b/drivers/macintosh/windfarm_smu_sensors.c
index 00c6fe25fcba..2bdb73b34d29 100644
--- a/drivers/macintosh/windfarm_smu_sensors.c
+++ b/drivers/macintosh/windfarm_smu_sensors.c
@@ -274,8 +274,8 @@ struct smu_cpu_power_sensor {
struct list_headlink;
struct wf_sensor*volts;
struct wf_sensor*amps;
- int fake_volts : 1;
- int quadratic : 1;
+ unsigned intfake_volts : 1;
+ unsigned intquadratic : 1;
struct wf_sensorsens;
};
#define to_smu_cpu_power(c) container_of(c, struct smu_cpu_power_sensor, sens)
---
base-commit: ceaa837f96adb69c0df0397937cd74991d5d821a
change-id:
20230215-windfarm-wsingle-bit-bitfield-constant-conversion-324fed6e2342
Best regards,
--
Nathan Chancellor
Re: [PATCH v2 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
On Thu, Jan 26, 2023 at 10:29:54AM +0900, Masahiro Yamada wrote:
> On Wed, Jan 25, 2023 at 1:11 PM Michael Ellerman wrote:
> >
> > Nathan Chancellor writes:
> > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
> > > points out that KBUILD_AFLAGS contains a linker flag, which will be
> > > used:
> >
> > Should that say "unused" ?
>
>
>
> Nathan, shall I fix it up locally?
> (it will change the commit hash, though.)
Yes please, if you would not mind. Sorry about that and thank you for
spotting it Michael!
Since you have to rebase to fix it, you can include Michael's acks?
Cheers,
Nathan
> > > clang: error: -Wl,-a32: 'linker' input unused
> > > [-Werror,-Wunused-command-line-argument]
> > >
> > > This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is
> > > unnecessary, as all supported versions of clang and gcc will pass '-a64'
> > > or '-a32' to GNU as based on the value of '-m'; the behavior of the
> > > latest stable release of the oldest supported major version of each
> > > compiler is shown below and each compiler's latest release exhibits the
> > > same behavior (GCC 12.2.0 and Clang 15.0.6).
> > >
> > > $ powerpc64-linux-gcc --version | head -1
> > > powerpc64-linux-gcc (GCC) 5.5.0
> > >
> > > $ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null
> > > /dev/null &| grep 'as '
> > > .../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s
> > >
> > > $ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null
> > > /dev/null &| grep 'as '
> > > .../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg
> > >
> > > $ clang --version | head -1
> > > Ubuntu clang version
> > > 11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5
> > >
> > > $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
> > > -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
> > >"/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o"
> > > "/dev/null" "/tmp/null-80267c.s"
> > >
> > > $ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
> > > -x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
> > >"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o"
> > > "/dev/null" "/tmp/null-ab8f8d.s"
> > >
> > > Remove this flag altogether to avoid future issues.
> > >
> > > Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than
> > > overriding LD/CC/AS")
> > > Signed-off-by: Nathan Chancellor
> > > Reviewed-by: Nick Desaulniers
> > > ---
> > > Cc: m...@ellerman.id.au
> >
> > Acked-by: Michael Ellerman (powerpc)
> >
> > cheers
>
>
>
> --
> Best Regards
> Masahiro Yamada
[PATCH] powerpc/vdso: Filter clang's auto var init zero enabler when linking
After commit 7bbf02b875b5 ("kbuild: Stop using '-Qunused-arguments' with
clang"), the PowerPC vDSO shows the following error with clang-13 and
older when CONFIG_INIT_STACK_ALL_ZERO is enabled:
clang: error: argument unused during compilation:
'-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang'
[-Werror,-Wunused-command-line-argument]
clang-14 added a change to make sure this flag never triggers
-Wunused-command-line-argument, so it is fixed with newer releases. For
older releases that the kernel still supports building with, just filter
out this flag, as has been done for other flags.
Fixes: b174f4c26aa3 ("powerpc/vdso: Improve linker flags")
Fixes: 7bbf02b875b5 ("kbuild: Stop using '-Qunused-arguments' with clang")
Link:
https://github.com/llvm/llvm-project/commit/ca6d5813d17598cd180995fb3bdfca00f364475f
Signed-off-by: Nathan Chancellor
---
This should be the last flag that needs to be filtered (famous last
words...) but if any more come up, we should really just explore
switching the PowerPC vDSO to linking with $(LD) like every other part
of the kernel; for now, I hope this is fine.
Cheers,
Nathan
---
Makefile | 4 +++-
arch/powerpc/kernel/vdso/Makefile | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index cf30a8b6463e..0406f37fd7a2 100644
--- a/Makefile
+++ b/Makefile
@@ -912,7 +912,9 @@ ifdef CONFIG_INIT_STACK_ALL_ZERO
KBUILD_CFLAGS += -ftrivial-auto-var-init=zero
ifdef CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
# https://github.com/llvm/llvm-project/issues/44842
-KBUILD_CFLAGS +=
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
+CC_AUTO_VAR_INIT_ZERO_ENABLER :=
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
+export CC_AUTO_VAR_INIT_ZERO_ENABLER
+KBUILD_CFLAGS += $(CC_AUTO_VAR_INIT_ZERO_ENABLER)
endif
endif
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/arch/powerpc/kernel/vdso/Makefile
index 7e69e87fbf74..d2a1dc0956d5 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -56,7 +56,7 @@ ccflags-y := -fno-common -fno-builtin
ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack
ldflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
# Filter flags that clang will warn are unused for linking
-ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CFLAGS))
+ldflags-y += $(filter-out $(CC_AUTO_VAR_INIT_ZERO_ENABLER) $(CC_FLAGS_FTRACE)
-Wa$(comma)%, $(KBUILD_CFLAGS))
CC32FLAGS := -m32
LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
---
base-commit: a778c9dd138b4f4410779705b444d58ce6f8fc44
change-id: 20230123-qunused-argument-auto-var-init-8ae79ddfd34f
Best regards,
--
Nathan Chancellor
Re: [PATCH v2 07/14] powerpc/vdso: Improve linker flags
On Mon, Jan 23, 2023 at 09:07:16AM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 11, 2023 at 08:05:04PM -0700, Nathan Chancellor wrote: > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there > > are several warnings in the PowerPC vDSO: > > > > clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: -Wl,--hash-style=both: 'linker' input unused > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: argument unused during compilation: '-shared' > > [-Werror,-Wunused-command-line-argument] > > > > clang-16: error: argument unused during compilation: '-nostdinc' > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: argument unused during compilation: '-Wa,-maltivec' > > [-Werror,-Wunused-command-line-argument] > > There is nothing wrong with the warnings, but as usual, -Werror is very > counterproductive. > > > The first group of warnings point out that linker flags were being added > > to all invocations of $(CC), even though they will only be used during > > the final vDSO link. Move those flags to ldflags-y. > > Which is explicitly allowed, and won't do anything, so nothing harmful > either. It is not a bad idea to avoid this if that is trivial to do, > of course. I think this patch shows that it is trivial to do this, the primary core of the diff is only a few lines. > > The second group of warnings are compiler or assembler flags that will > > be unused during linking. Filter them out from KBUILD_CFLAGS so that > > they are not used during linking. > > And here it is even more obviously fine. If you need obfuscation like > in your patch, it is better not to do this imo. I do not think this patch really obfuscates anything? The filtering is pretty clear to me. If this is a real objection to the patch, I suppose we could just localize '-Qunused-arguments' to this Makefile and be done with it but I do not think this change is a bad solution to the problem either. Cheers, Nathan
Re: [PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
Hi Naresh,
On Mon, Jan 23, 2023 at 07:28:10PM +0530, Naresh Kamboju wrote:
> FYI,
> [ please provide comments, feedback and improvements on build/ ltp smoke
> tests ]
>
> LKFT test farm have fetched your patch series [1]
> [PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
> [1]
> https://lore.kernel.org/llvm/20221228-drop-qunused-arguments-v2-0-9adbddd20...@kernel.org/
Thank you a lot for testing this series, it is much appreciated!
It looks like this was applied on top of 6.2-rc3 if I am reading your
logs right but your mainline testing is recent, 6.2-rc5. I think the
errors you are seeing here are just existing mainline regressions that
were later fixed.
> Following build warnings and errors reported.
>
> sh:
> gcc-11-defconfig — FAIL
> gcc-11-shx3_defconfig — FAIL
> https://qa-reports.linaro.org/~anders.roxell/linux-mainline-patches/build/https___lore_kernel_org_llvm_20221228-drop-qunused-arguments-v2-1-9adbddd20d86_kernel_org/testrun/14221835/suite/build/tests/
>
> mainline getting passed.
> https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.2-rc5/testrun/14298156/suite/build/test/gcc-11-defconfig/history/
> https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.2-rc5/testrun/14298156/suite/build/test/gcc-11-shx3_defconfig/history/
>
> Build error:
> In function 'follow_pmd_mask',
> inlined from 'follow_pud_mask' at /builds/linux/mm/gup.c:735:9,
> inlined from 'follow_p4d_mask' at /builds/linux/mm/gup.c:752:9,
> inlined from 'follow_page_mask' at /builds/linux/mm/gup.c:809:9:
> /builds/linux/include/linux/compiler_types.h:358:45: error: call to
> '__compiletime_assert_263' declared with attribute error: Unsupported
> access size for {READ,WRITE}_ONCE().
> 358 | _compiletime_assert(condition, msg,
> __compiletime_assert_, __COUNTER__)
I think this was fixed with mainline commit 526970be53d5 ("sh/mm: Fix
pmd_t for real"), released in 6.2-rc4. You can see a previous build
failing in the same manner:
https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.2-rc3-9-g5a41237ad1d4/testrun/14056384/suite/build/tests/
> s390:
> clang-15-defconfig — FAIL
> https://qa-reports.linaro.org/~anders.roxell/linux-mainline-patches/build/https___lore_kernel_org_llvm_20221228-drop-qunused-arguments-v2-1-9adbddd20d86_kernel_org/testrun/14221913/suite/build/tests/
>
> mainline getting passed.
> https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.2-rc5/testrun/14300495/suite/build/test/clang-15-defconfig/history/
>
> Build error:
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/1/build LLVM_IAS=0 ARCH=s390
> CROSS_COMPILE=s390x-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> clang'
> `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o:
> defined in discarded section `.exit.text' of fs/fuse/inode.o
> `.exit.text' referenced in section `__jump_table' of fs/fuse/inode.o:
> defined in discarded section `.exit.text' of fs/fuse/inode.o
> `.exit.text' referenced in section `__bug_table' of crypto/algboss.o:
> defined in discarded section `.exit.text' of crypto/algboss.o
> `.exit.text' referenced in section `__bug_table' of drivers/scsi/sd.o:
> defined in discarded section `.exit.text' of drivers/scsi/sd.o
> `.exit.text' referenced in section `__jump_table' of drivers/md/md.o:
> defined in discarded section `.exit.text' of drivers/md/md.o
> `.exit.text' referenced in section `__jump_table' of drivers/md/md.o:
> defined in discarded section `.exit.text' of drivers/md/md.o
> `.exit.text' referenced in section `.altinstructions' of
> drivers/md/md.o: defined in discarded section `.exit.text' of
> drivers/md/md.o
> `.exit.text' referenced in section `.altinstructions' of
> drivers/md/md.o: defined in discarded section `.exit.text' of
> drivers/md/md.o
> `.exit.text' referenced in section `.altinstructions' of
> net/iucv/iucv.o: defined in discarded section `.exit.text' of
> net/iucv/iucv.o
> `.exit.text' referenced in section `__bug_table' of
> drivers/s390/cio/qdio_thinint.o: defined in discarded section
> `.exit.text' of drivers/s390/cio/qdio_thinint.o
> `.exit.text' referenced in section `__bug_table' of
> drivers/s390/net/qeth_l3_main.o: defined in discarded section
> `.exit.text' of drivers/s390/net/qeth_l3_main.o
> `.exit.text' referenced in section `__bug_table' of
> drivers/s390/net/qeth_l3_main.o: defined in discarded section
> `.exit.text' of drivers/s390/net/qeth_l3_main.o
> s390x-linux-gnu-ld: BFD (GNU Binutils for Debian) 2.35.2 assertion
> fail ../../bfd/elf64-s390.c:3349
> make[2]: *** [/builds/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
This should be fixed with mainline commit a494398bde27 ("s390: define
RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36"), released in
6.2-rc4 as well. Same as before, visible in mainline at one point
without this series:
https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v6.2-rc3-9-g5a41237ad1d4/testrun/1
Re: [PATCH v2 07/14] powerpc/vdso: Improve linker flags
On Mon, Jan 23, 2023 at 02:27:51AM +0900, Masahiro Yamada wrote:
> On Fri, Jan 13, 2023 at 3:21 AM Nathan Chancellor wrote:
> >
> > Hi Sedat,
> >
> > On Thu, Jan 12, 2023 at 07:02:30PM +0100, Sedat Dilek wrote:
> > > On Thu, Jan 12, 2023 at 4:06 AM Nathan Chancellor
> > > wrote:
> > > >
> > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> > > > are several warnings in the PowerPC vDSO:
> > > >
> > > > clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
> > > > [-Werror,-Wunused-command-line-argument]
> > > > clang-16: error: -Wl,--hash-style=both: 'linker' input unused
> > > > [-Werror,-Wunused-command-line-argument]
> > > > clang-16: error: argument unused during compilation: '-shared'
> > > > [-Werror,-Wunused-command-line-argument]
> > > >
> > > > clang-16: error: argument unused during compilation: '-nostdinc'
> > > > [-Werror,-Wunused-command-line-argument]
> > > > clang-16: error: argument unused during compilation: '-Wa,-maltivec'
> > > > [-Werror,-Wunused-command-line-argument]
> > > >
> > > > The first group of warnings point out that linker flags were being added
> > > > to all invocations of $(CC), even though they will only be used during
> > > > the final vDSO link. Move those flags to ldflags-y.
> > > >
> > > > The second group of warnings are compiler or assembler flags that will
> > > > be unused during linking. Filter them out from KBUILD_CFLAGS so that
> > > > they are not used during linking.
> > > >
> > > > Additionally, '-z noexecstack' was added directly to the ld_and_check
> > > > rule in commit 1d53c0192b15 ("powerpc/vdso: link with -z noexecstack")
> > > > but now that there is a common ldflags variable, it can be moved there.
> > > >
> > > > Signed-off-by: Nathan Chancellor
> > > > Reviewed-by: Nick Desaulniers
> > > > ---
> > > > Cc: m...@ellerman.id.au
> > > > Cc: npig...@gmail.com
> > > > Cc: christophe.le...@csgroup.eu
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > ---
> > > > arch/powerpc/kernel/vdso/Makefile | 18 +++---
> > > > 1 file changed, 11 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/kernel/vdso/Makefile
> > > > b/arch/powerpc/kernel/vdso/Makefile
> > > > index 45c0cc5d34b6..4337b3aa9171 100644
> > > > --- a/arch/powerpc/kernel/vdso/Makefile
> > > > +++ b/arch/powerpc/kernel/vdso/Makefile
> > > > @@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n
> > > > UBSAN_SANITIZE := n
> > > > KASAN_SANITIZE := n
> > > >
> > > > -ccflags-y := -shared -fno-common -fno-builtin -nostdlib
> > > > -Wl,--hash-style=both
> > > > -ccflags-$(CONFIG_LD_IS_LLD) += $(call
> > > > cc-option,--ld-path=$(LD),-fuse-ld=lld)
> > > > -
> > > > -CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
> > > > +ccflags-y := -fno-common -fno-builtin
> > > > +ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack
> > > > +ldflags-$(CONFIG_LD_IS_LLD) += $(call
> > > > cc-option,--ld-path=$(LD),-fuse-ld=lld)
> > > > +# Filter flags that clang will warn are unused for linking
> > > > +ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%,
> > > > $(KBUILD_CFLAGS))
> > > > +
> > > > +CC32FLAGS := -m32
> > > > +LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
> > > > AS32FLAGS := -D__VDSO32__
> > > >
> > > > -CC64FLAGS := -Wl,-soname=linux-vdso64.so.1
> > >
> > > Set CC64FLAGS := -m64 ?
> >
> > I do not think it is necessary. ldflags-y is filtered from
> > KBUILD_CFLAGS, which should already include '-m64' (search for
> > 'HAS_BIARCH' in arch/powerpc/Makefile). We would have seen a problem
> > with this already if a 32-bit target (powerpc-linux-gnu-) CROSS_COMPILE
> > value since $(c_flags) uses the main kernel's CROSS_COMPILE value.
> >
> > > > +LD64FLAGS := -Wl,-soname=linux-vdso64.so.1
> > > > AS64FLAGS := -D__VDSO64__
> > > >
> > > > targets += vdso32.lds
> > > > @@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h:
> > > > $
Re: [PATCH] powerpc: add crtsavres.o to always-y instead of extra-y
On Thu, Jan 19, 2023 at 05:24:47PM +0900, Masahiro Yamada wrote:
> crtsavres.o is linked to modules, but as commit d0e628cd817f ("kbuild:
> doc: clarify the difference between extra-y and always-y") explained,
> 'make modules' does not build extra-y.
>
> The following command fails:
>
> $ make ARCH=powerpc LLVM=1 mrproper ps3_defconfig modules
> [snip]
> LD [M] arch/powerpc/platforms/cell/spufs/spufs.ko
> ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or
> directory
> make[1]: *** [scripts/Makefile.modfinal:61:
> arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
> make: *** [Makefile:1924: modules] Error 2
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Nathan Chancellor
> ---
>
> 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 c53618c34b70..aa34854bc9f5 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -43,7 +43,7 @@ obj-$(CONFIG_FUNCTION_ERROR_INJECTION) +=
> error-inject.o
> # so it is only needed for modules, and only for older linkers which
> # do not support --save-restore-funcs
> ifndef CONFIG_LD_IS_BFD
> -extra-$(CONFIG_PPC64)+= crtsavres.o
> +always-$(CONFIG_PPC64) += crtsavres.o
> endif
>
> obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \
> --
> 2.34.1
>
Re: [PATCH v2 07/14] powerpc/vdso: Improve linker flags
Hi Sedat,
On Thu, Jan 12, 2023 at 07:02:30PM +0100, Sedat Dilek wrote:
> On Thu, Jan 12, 2023 at 4:06 AM Nathan Chancellor wrote:
> >
> > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
> > are several warnings in the PowerPC vDSO:
> >
> > clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
> > [-Werror,-Wunused-command-line-argument]
> > clang-16: error: -Wl,--hash-style=both: 'linker' input unused
> > [-Werror,-Wunused-command-line-argument]
> > clang-16: error: argument unused during compilation: '-shared'
> > [-Werror,-Wunused-command-line-argument]
> >
> > clang-16: error: argument unused during compilation: '-nostdinc'
> > [-Werror,-Wunused-command-line-argument]
> > clang-16: error: argument unused during compilation: '-Wa,-maltivec'
> > [-Werror,-Wunused-command-line-argument]
> >
> > The first group of warnings point out that linker flags were being added
> > to all invocations of $(CC), even though they will only be used during
> > the final vDSO link. Move those flags to ldflags-y.
> >
> > The second group of warnings are compiler or assembler flags that will
> > be unused during linking. Filter them out from KBUILD_CFLAGS so that
> > they are not used during linking.
> >
> > Additionally, '-z noexecstack' was added directly to the ld_and_check
> > rule in commit 1d53c0192b15 ("powerpc/vdso: link with -z noexecstack")
> > but now that there is a common ldflags variable, it can be moved there.
> >
> > Signed-off-by: Nathan Chancellor
> > Reviewed-by: Nick Desaulniers
> > ---
> > Cc: m...@ellerman.id.au
> > Cc: npig...@gmail.com
> > Cc: christophe.le...@csgroup.eu
> > Cc: linuxppc-dev@lists.ozlabs.org
> > ---
> > arch/powerpc/kernel/vdso/Makefile | 18 +++---
> > 1 file changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/vdso/Makefile
> > b/arch/powerpc/kernel/vdso/Makefile
> > index 45c0cc5d34b6..4337b3aa9171 100644
> > --- a/arch/powerpc/kernel/vdso/Makefile
> > +++ b/arch/powerpc/kernel/vdso/Makefile
> > @@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n
> > UBSAN_SANITIZE := n
> > KASAN_SANITIZE := n
> >
> > -ccflags-y := -shared -fno-common -fno-builtin -nostdlib
> > -Wl,--hash-style=both
> > -ccflags-$(CONFIG_LD_IS_LLD) += $(call
> > cc-option,--ld-path=$(LD),-fuse-ld=lld)
> > -
> > -CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
> > +ccflags-y := -fno-common -fno-builtin
> > +ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack
> > +ldflags-$(CONFIG_LD_IS_LLD) += $(call
> > cc-option,--ld-path=$(LD),-fuse-ld=lld)
> > +# Filter flags that clang will warn are unused for linking
> > +ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%,
> > $(KBUILD_CFLAGS))
> > +
> > +CC32FLAGS := -m32
> > +LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
> > AS32FLAGS := -D__VDSO32__
> >
> > -CC64FLAGS := -Wl,-soname=linux-vdso64.so.1
>
> Set CC64FLAGS := -m64 ?
I do not think it is necessary. ldflags-y is filtered from
KBUILD_CFLAGS, which should already include '-m64' (search for
'HAS_BIARCH' in arch/powerpc/Makefile). We would have seen a problem
with this already if a 32-bit target (powerpc-linux-gnu-) CROSS_COMPILE
value since $(c_flags) uses the main kernel's CROSS_COMPILE value.
> > +LD64FLAGS := -Wl,-soname=linux-vdso64.so.1
> > AS64FLAGS := -D__VDSO64__
> >
> > targets += vdso32.lds
> > @@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h:
> > $(obj)/vdso64.so.dbg FORCE
> >
> > # actual build commands
> > quiet_cmd_vdso32ld_and_check = VDSO32L $@
> > - cmd_vdso32ld_and_check = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@
> > -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
> > + cmd_vdso32ld_and_check = $(VDSOCC) $(ldflags-y) $(CC32FLAGS)
> > $(LD32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^);
> > $(cmd_vdso_check)
> > quiet_cmd_vdso32as = VDSO32A $@
> >cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) $(AS32FLAGS) -c -o
> > $@ $<
> > quiet_cmd_vdso32cc = VDSO32C $@
> >cmd_vdso32cc = $(VDSOCC) $(c_flags) $(CC32FLAGS) -c -o $@ $<
> >
> > quiet_cmd_vdso64ld_and_check = VDSO64L $@
> > - cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@
> > -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
> > + cmd_vdso64ld_and_check = $(VDSOCC) $(ldflags-y) $(CC64FLAGS)
> > $(LD64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^);
> > $(cmd_vdso_check)
>
> If no CC64FLAGS := xxx is set, this can go?
Good catch! CC64FLAGS can be removed. Masahiro, I am happy to send a v3
when I am back online next week but if you are able to fix it up during
application, please feel free to do so (once the PowerPC folks give
their Acks of course).
> > quiet_cmd_vdso64as = VDSO64A $@
> >cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o
> > $@ $<
> >
> >
> > --
> > 2.39.0
> >
Thanks for the review, cheers!
Nathan
[PATCH v2 08/14] powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with clang
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] This warning happens because vgettimeofday-32.c gets its base CFLAGS from the main kernel, which may contain flags that are only supported on a 64-bit target but not a 32-bit one, which is the case here. -fstack-clash-protection and its negation are only suppported by the 64-bit powerpc target but that flag is included in an invocation for a 32-bit powerpc target, so clang points out that while the flag is one that it recognizes, it is not actually used by this compiler job. To eliminate the warning, remove -fno-stack-clash-protection from vgettimeofday-32.c's CFLAGS when using clang, as has been done for other flags previously. Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/vdso/Makefile | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 4337b3aa9171..e78a57e0a6c0 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -16,6 +16,11 @@ ifneq ($(c-gettimeofday-y),) CFLAGS_vgettimeofday-32.o += -ffreestanding -fasynchronous-unwind-tables CFLAGS_REMOVE_vgettimeofday-32.o = $(CC_FLAGS_FTRACE) CFLAGS_REMOVE_vgettimeofday-32.o += -mcmodel=medium -mabi=elfv1 -mabi=elfv2 -mcall-aixdesc + # This flag is supported by clang for 64-bit but not 32-bit so it will cause + # an unused command line flag warning for this file. + ifdef CONFIG_CC_IS_CLANG + CFLAGS_REMOVE_vgettimeofday-32.o += -fno-stack-clash-protection + endif CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) CFLAGS_vgettimeofday-64.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_vgettimeofday-64.o += $(call cc-option, -fno-stack-protector) -- 2.39.0
[PATCH v2 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
points out that KBUILD_AFLAGS contains a linker flag, which will be
used:
clang: error: -Wl,-a32: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is
unnecessary, as all supported versions of clang and gcc will pass '-a64'
or '-a32' to GNU as based on the value of '-m'; the behavior of the
latest stable release of the oldest supported major version of each
compiler is shown below and each compiler's latest release exhibits the
same behavior (GCC 12.2.0 and Clang 15.0.6).
$ powerpc64-linux-gcc --version | head -1
powerpc64-linux-gcc (GCC) 5.5.0
$ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s
$ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg
$ clang --version | head -1
Ubuntu clang version
11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o" "/dev/null"
"/tmp/null-80267c.s"
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "/dev/null"
"/tmp/null-ab8f8d.s"
Remove this flag altogether to avoid future issues.
Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than
overriding LD/CC/AS")
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: christophe.le...@csgroup.eu
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..4fd630efe39d 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -90,7 +90,7 @@ aflags-$(CONFIG_CPU_LITTLE_ENDIAN)+= -mlittle-endian
ifeq ($(HAS_BIARCH),y)
KBUILD_CFLAGS += -m$(BITS)
-KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
+KBUILD_AFLAGS += -m$(BITS)
KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
endif
--
2.39.0
[PATCH v2 07/14] powerpc/vdso: Improve linker flags
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there
are several warnings in the PowerPC vDSO:
clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
clang-16: error: -Wl,--hash-style=both: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-shared'
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-nostdinc'
[-Werror,-Wunused-command-line-argument]
clang-16: error: argument unused during compilation: '-Wa,-maltivec'
[-Werror,-Wunused-command-line-argument]
The first group of warnings point out that linker flags were being added
to all invocations of $(CC), even though they will only be used during
the final vDSO link. Move those flags to ldflags-y.
The second group of warnings are compiler or assembler flags that will
be unused during linking. Filter them out from KBUILD_CFLAGS so that
they are not used during linking.
Additionally, '-z noexecstack' was added directly to the ld_and_check
rule in commit 1d53c0192b15 ("powerpc/vdso: link with -z noexecstack")
but now that there is a common ldflags variable, it can be moved there.
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: christophe.le...@csgroup.eu
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/vdso/Makefile | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/vdso/Makefile
b/arch/powerpc/kernel/vdso/Makefile
index 45c0cc5d34b6..4337b3aa9171 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n
UBSAN_SANITIZE := n
KASAN_SANITIZE := n
-ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
-ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
-
-CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
+ccflags-y := -fno-common -fno-builtin
+ldflags-y := -Wl,--hash-style=both -nostdlib -shared -z noexecstack
+ldflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
+# Filter flags that clang will warn are unused for linking
+ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CFLAGS))
+
+CC32FLAGS := -m32
+LD32FLAGS := -Wl,-soname=linux-vdso32.so.1
AS32FLAGS := -D__VDSO32__
-CC64FLAGS := -Wl,-soname=linux-vdso64.so.1
+LD64FLAGS := -Wl,-soname=linux-vdso64.so.1
AS64FLAGS := -D__VDSO64__
targets += vdso32.lds
@@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h: $(obj)/vdso64.so.dbg
FORCE
# actual build commands
quiet_cmd_vdso32ld_and_check = VDSO32L $@
- cmd_vdso32ld_and_check = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@
-Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
+ cmd_vdso32ld_and_check = $(VDSOCC) $(ldflags-y) $(CC32FLAGS)
$(LD32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^); $(cmd_vdso_check)
quiet_cmd_vdso32as = VDSO32A $@
cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) $(AS32FLAGS) -c -o $@ $<
quiet_cmd_vdso32cc = VDSO32C $@
cmd_vdso32cc = $(VDSOCC) $(c_flags) $(CC32FLAGS) -c -o $@ $<
quiet_cmd_vdso64ld_and_check = VDSO64L $@
- cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@
-Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check)
+ cmd_vdso64ld_and_check = $(VDSOCC) $(ldflags-y) $(CC64FLAGS)
$(LD64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^); $(cmd_vdso_check)
quiet_cmd_vdso64as = VDSO64A $@
cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o $@ $<
--
2.39.0
[PATCH v2 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument] The compiler's '-s' flag is a linking option (it is passed along to the linker directly), which means it does nothing when the linker is not invoked by the compiler. The kernel builds all .o files with '-c', which stops the compilation pipeline before linking, so '-s' can be safely dropped from ASFLAGS. Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Segher Boessenkool --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org As I mentioned before, it is possible that we should add '-s' to ldflags-y in the following patch but I assume someone would have noticed by now if that was a problem. --- arch/powerpc/kernel/vdso/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 6a977b0d8ffc..45c0cc5d34b6 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -51,10 +51,10 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld) CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 -AS32FLAGS := -D__VDSO32__ -s +AS32FLAGS := -D__VDSO32__ CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 -AS64FLAGS := -D__VDSO64__ -s +AS64FLAGS := -D__VDSO64__ targets += vdso32.lds CPPFLAGS_vdso32.lds += -P -C -Upowerpc -- 2.39.0
[PATCH v2 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
Hi all,
Clang can emit a few different warnings when it encounters a flag that it
recognizes but does not support internally. These warnings are elevated to
errors within {as,cc}-option via -Werror to catch unsupported flags that should
not be added to KBUILD_{A,C}FLAGS; see commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").
If an unsupported flag is unconditionally to KBUILD_{A,C}FLAGS, all subsequent
{as,cc}-option will always fail, preventing supported and even potentially
necessary flags from getting adding to the tool flags.
One would expect these warnings to be visible in the kernel build logs since
they are added to KBUILD_{A,C}FLAGS but unfortunately, these warnings are
hidden with clang's -Qunused-arguments flag, which is added to KBUILD_CPPFLAGS
and used for both compiling and assembling files.
Patches 1-4 address the internal inconsistencies of invoking the assembler
within kbuild by using KBUILD_AFLAGS consistently and using '-x
assembler-with-cpp' over '-x assembler'. This matches how assembly files are
built across the kernel and helps avoid problems in situations where macro
definitions or warning flags are present in KBUILD_AFLAGS, which cause
instances of -Wunused-command-line-argument when the preprocessor is not called
to consume them. There were a couple of places in architecture code where this
change would break things so those are fixed first.
Patches 5-12 clean up warnings that will show up when -Qunused-argument is
dropped. I hope none of these are controversial.
Patch 13 turns two warnings into errors so that the presence of unused flags
cannot be easily ignored.
Patch 14 drops -Qunused-argument. This is done last so that it can be easily
reverted if need be.
This series has seen my personal test framework, which tests several different
configurations and architectures, with LLVM tip of tree (16.0.0). I have done
defconfig, allmodconfig, and allnoconfig builds for arm, arm64, i386, mips,
powerpc, riscv, s390, and x86_64 with GCC 12.2.0 as well but I am hoping the
rest of the test infrastructure will catch any lurking problems.
I would like this series to stay together so that there is no opportunity for
breakage so please consider giving acks so that this can be carried via the
kbuild tree (and many thanks to the people who have already provided such
tags).
---
Changes in v2:
- Pick up tags where provided (thank you everyone!)
- Patch 6 and 9: Clarify that '-s' is a compiler flag that is only relevant to
the linking phase and remove all mention of the assembler's '-s' flag, as the
assembler is never directly invoked (Nick, Segher)
- Patch 7: Move '-z noexecstack' into new ldflags-y variable (Nick)
- Patch 8: Reword commit message to explain the problem in a clearer manner
(Nick)
- Link to v1:
https://lore.kernel.org/r/20221228-drop-qunused-arguments-v1-0-658cbc8fc...@kernel.org
---
Nathan Chancellor (12):
MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT
MIPS: Prefer cc-option for additions to cflags
powerpc: Remove linker flag from KBUILD_AFLAGS
powerpc/vdso: Remove unused '-s' flag from ASFLAGS
powerpc/vdso: Improve linker flags
powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with
clang
s390/vdso: Drop unused '-s' flag from KBUILD_AFLAGS_64
s390/vdso: Drop '-shared' from KBUILD_CFLAGS_64
s390/purgatory: Remove unused '-MD' and unnecessary '-c' flags
drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
kbuild: Turn a couple more of clang's unused option warnings into errors
kbuild: Stop using '-Qunused-arguments' with clang
Nick Desaulniers (2):
x86/boot/compressed: prefer cc-option for CFLAGS additions
kbuild: Update assembler calls to use proper flags and language target
Makefile| 1 -
arch/mips/Makefile | 13 ++---
arch/mips/include/asm/asmmacro-32.h | 4 +--
arch/mips/include/asm/asmmacro.h| 42 ++---
arch/mips/include/asm/fpregdef.h| 14 --
arch/mips/include/asm/mipsregs.h| 20 +++---
arch/mips/kernel/genex.S| 2 +-
arch/mips/kernel/r2300_fpu.S| 4 +--
arch/mips/kernel/r4k_fpu.S | 12 -
arch/mips/kvm/fpu.S | 6 ++---
arch/mips/loongson2ef/Platform | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/kernel/vdso/Makefile | 25 +++--
arch/s390/kernel/vdso64/Makefile| 4 +--
arch/s390/purgatory/Makefile| 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dml/Makefile | 3 ++-
scripts/K
Re: [PATCH 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
On Tue, Jan 10, 2023 at 05:45:23AM -0600, Segher Boessenkool wrote: > On Mon, Jan 09, 2023 at 05:51:23PM -0700, Nathan Chancellor wrote: > > So for this patch, I have > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > > warns: > > > > clang-16: error: argument unused during compilation: '-s' > > [-Werror,-Wunused-command-line-argument] > > > > The compiler's '-s' flag is a linking option (it is passed along to the > > linker directly), which means it does nothing when the linker is not > > invoked by the compiler. The kernel builds all .o files with either '-c' > > or '-S', which do not run the linker, so '-s' can be safely dropped from > > ASFLAGS. > > > > as a new commit message. Is that sufficient for everyone? If so, I'll > > adjust the s390 commit to match, as it is the same exact problem. > > Almost? -S doesn't write .o files, it writes a .s file. To go from an > assembler file (.s, or .S if you want to run the C preprocessor on non-C > code for some strange reason, the assembler macro facilities are vastly > superior) to an object file is just -c as well. Heh, right, that is what I get for not paying attention and rushing at the end of my day :) thanks for being pendantic, I will get that ironed out for v2, which I should have out later today or tomorrow, time permitting. Cheers, Nathan
Re: [PATCH 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
On Mon, Jan 09, 2023 at 03:14:33PM -0800, Nick Desaulniers wrote: > On Mon, Jan 9, 2023 at 2:29 PM Segher Boessenkool > wrote: > > > > Hi! Happy new year all. > > HNY Segher! :) > > > > > On Mon, Jan 09, 2023 at 01:58:32PM -0800, Nick Desaulniers wrote: > > > On Wed, Jan 4, 2023 at 11:55 AM Nathan Chancellor > > > wrote: > > > > > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > > > > warns that ASFLAGS contains '-s', which is a linking phase option, so it > > > > is unused. > > > > > > > > clang-16: error: argument unused during compilation: '-s' > > > > [-Werror,-Wunused-command-line-argument] > > > > > > > > Looking at the GAS sources, '-s' is only useful when targeting Solaris > > > > and it is ignored for the powerpc target so just drop the flag > > > > altogether, as it is not needed. > > > > > > Do you have any more info where you found this? I don't see -s > > > documented as an assembler flag. > > > https://sourceware.org/binutils/docs/as/PowerPC_002dOpts.html > > > https://sourceware.org/binutils/docs/as/Invoking.html > > > > It is required by POSIX (for the c99 command, anyway). It *also* is > > required to be supported when producing object files (so when no linking > > is done). > > > > It is a GCC flag, and documented just fine: > > https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-s > > > > (Yes, that says it is for linking; but the option is allowed without > > error of any kind always). > > > > (ASFLAGS sounds like it is for assembler commands, but it really is > > for compiler commands that just happen to get .S input files). > > > > > The patch seems fine to me, but what was this ever supposed to be? > > > FWICT it predates git history (looking at > > > arch/powerpc/kernel/vdso32/Makefile at fc15351d9d63) > > > > Yeah, good question. This compiler flag does the moral equivalent of > > strip -s (aka --strip-all). Maybe this was needed at some point, or > > the symbol or debug info was just annoying (during bringup or similar)? > > Ah right! Ok then, I think we might keep the patch's diff, but update > the commit message to mention this is a linker flag that's unused > since the compiler is being invoked but not the linker (the compiler > is being used as the driver to assemble a single assembler source > without linking it; linking is then driven by the linker in a separate > make rule). Yes, sorry, I thought that was clear with the "which is a linking phase option" comment in the commit message but clearly not :) > Then we might want to revisit that s390 patch, too? > https://lore.kernel.org/llvm/20221228-drop-qunused-arguments-v1-9-658cbc8fc...@kernel.org/ So for this patch, I have When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument] The compiler's '-s' flag is a linking option (it is passed along to the linker directly), which means it does nothing when the linker is not invoked by the compiler. The kernel builds all .o files with either '-c' or '-S', which do not run the linker, so '-s' can be safely dropped from ASFLAGS. as a new commit message. Is that sufficient for everyone? If so, I'll adjust the s390 commit to match, as it is the same exact problem. Alternatively, if '-s' should actually remain around, we could move it to ldflags-y, which is added in patch 7. However, I assume that nobody has noticed that it has not been doing its job for a while, so it should be safe to remove. Cheers, Nathan
Re: [PATCH 08/14] powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with clang
On Mon, Jan 09, 2023 at 02:12:55PM -0800, Nick Desaulniers wrote: > On Wed, Jan 4, 2023 at 11:55 AM Nathan Chancellor wrote: > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > > warns: > > > > clang-16: error: argument unused during compilation: > > '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] > > > > This flag is supported for 64-bit powerpc but not 32-bit, hence the warning. > > Just remove the flag from vgettimeofday-32.o's CFLAGS when using clang, as > > has > > been done for other flags previously. > > > > Signed-off-by: Nathan Chancellor > > Hmm...so this was added by the top level Makefile doing a cc-option > test. How did the test pass if this was unsupported? That worries me > that perhaps other cc-option tests are passing erroneously for certain > ppc -m32/-m64 configs? Sure, that is a reasonable concern. I should have expanded upon this a little bit more in the commit message. Is this any better? When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] This warning happens because vgettimeofday-32.c gets its base CFLAGS from the main kernel, which may contain flags that are only supported on a 64-bit target but not a 32-bit one, which is the case here. -fstack-clash-protection and its negation are only suppported by the 64-bit powerpc target but that flag is included in an invocation for a 32-bit powerpc target, so clang points out that while the flag is one that it recognizes, it is not actually used by this compiler job. To eliminate the warning, remove -fno-stack-clash-protection from vgettimeofday-32.c's CFLAGS when using clang, as has been done for other flags previously. Cheers, Nathan > > --- > > Cc: m...@ellerman.id.au > > Cc: npig...@gmail.com > > Cc: christophe.le...@csgroup.eu > > Cc: linuxppc-dev@lists.ozlabs.org > > --- > > arch/powerpc/kernel/vdso/Makefile | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/arch/powerpc/kernel/vdso/Makefile > > b/arch/powerpc/kernel/vdso/Makefile > > index 769b62832b38..4ee7d36ce752 100644 > > --- a/arch/powerpc/kernel/vdso/Makefile > > +++ b/arch/powerpc/kernel/vdso/Makefile > > @@ -16,6 +16,11 @@ ifneq ($(c-gettimeofday-y),) > >CFLAGS_vgettimeofday-32.o += -ffreestanding -fasynchronous-unwind-tables > >CFLAGS_REMOVE_vgettimeofday-32.o = $(CC_FLAGS_FTRACE) > >CFLAGS_REMOVE_vgettimeofday-32.o += -mcmodel=medium -mabi=elfv1 > > -mabi=elfv2 -mcall-aixdesc > > + # This flag is supported by clang for 64-bit but not 32-bit so it will > > cause > > + # an unused command line flag warning for this file. > > + ifdef CONFIG_CC_IS_CLANG > > + CFLAGS_REMOVE_vgettimeofday-32.o += -fno-stack-clash-protection > > + endif > >CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) > >CFLAGS_vgettimeofday-64.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) > >CFLAGS_vgettimeofday-64.o += $(call cc-option, -fno-stack-protector) > > > > -- > > 2.39.0 > > > > -- > Thanks, > ~Nick Desaulniers
Re: [PATCH 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
On Mon, Jan 09, 2023 at 04:23:37PM -0600, Segher Boessenkool wrote: > Hi! Happy new year all. > > On Mon, Jan 09, 2023 at 01:58:32PM -0800, Nick Desaulniers wrote: > > On Wed, Jan 4, 2023 at 11:55 AM Nathan Chancellor wrote: > > > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > > > warns that ASFLAGS contains '-s', which is a linking phase option, so it > > > is unused. > > > > > > clang-16: error: argument unused during compilation: '-s' > > > [-Werror,-Wunused-command-line-argument] > > > > > > Looking at the GAS sources, '-s' is only useful when targeting Solaris > > > and it is ignored for the powerpc target so just drop the flag > > > altogether, as it is not needed. > > > > Do you have any more info where you found this? I don't see -s > > documented as an assembler flag. > > https://sourceware.org/binutils/docs/as/PowerPC_002dOpts.html > > https://sourceware.org/binutils/docs/as/Invoking.html > > It is required by POSIX (for the c99 command, anyway). It *also* is > required to be supported when producing object files (so when no linking > is done). > > It is a GCC flag, and documented just fine: > https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-s > > (Yes, that says it is for linking; but the option is allowed without > error of any kind always). > > (ASFLAGS sounds like it is for assembler commands, but it really is > for compiler commands that just happen to get .S input files). > > > The patch seems fine to me, but what was this ever supposed to be? > > FWICT it predates git history (looking at > > arch/powerpc/kernel/vdso32/Makefile at fc15351d9d63) > > Yeah, good question. This compiler flag does the moral equivalent of > strip -s (aka --strip-all). Maybe this was needed at some point, or > the symbol or debug info was just annoying (during bringup or similar)? > > > Reviewed-by: Nick Desaulniers > Reviewed-by: Segher Boessenkool Thank you for the review and extra explanation! I had kind of expanded on this in the s390 version of this patch [1], I will go ahead and do the same thing for the powerpc version too. [1]: https://lore.kernel.org/llvm/20221228-drop-qunused-arguments-v1-9-658cbc8fc...@kernel.org/ Cheers, Nathan
Re: [PATCH 07/14] powerpc/vdso: Improve linker flags
On Mon, Jan 09, 2023 at 02:08:41PM -0800, Nick Desaulniers wrote: > On Wed, Jan 4, 2023 at 11:55 AM Nathan Chancellor wrote: > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there > > are several warnings in the PowerPC vDSO: > > > > clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: -Wl,--hash-style=both: 'linker' input unused > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: argument unused during compilation: '-shared' > > [-Werror,-Wunused-command-line-argument] > > > > clang-16: error: argument unused during compilation: '-nostdinc' > > [-Werror,-Wunused-command-line-argument] > > clang-16: error: argument unused during compilation: '-Wa,-maltivec' > > [-Werror,-Wunused-command-line-argument] > > > > The first group of warnings point out that linker flags were being added > > to all invocations of $(CC), even though they will only be used during > > the final vDSO link. Move those flags to ldflags-y. > > > > The second group of warnings are compiler or assembler flags that will > > be unused during linking. Filter them out from KBUILD_CFLAGS so that > > they are not used during linking. > > > > Signed-off-by: Nathan Chancellor > > --- > > Cc: m...@ellerman.id.au > > Cc: npig...@gmail.com > > Cc: christophe.le...@csgroup.eu > > Cc: linuxppc-dev@lists.ozlabs.org > > --- > > arch/powerpc/kernel/vdso/Makefile | 18 +++--- > > 1 file changed, 11 insertions(+), 7 deletions(-) > > > > diff --git a/arch/powerpc/kernel/vdso/Makefile > > b/arch/powerpc/kernel/vdso/Makefile > > index 45c0cc5d34b6..769b62832b38 100644 > > --- a/arch/powerpc/kernel/vdso/Makefile > > +++ b/arch/powerpc/kernel/vdso/Makefile > > @@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n > > UBSAN_SANITIZE := n > > KASAN_SANITIZE := n > > > > -ccflags-y := -shared -fno-common -fno-builtin -nostdlib > > -Wl,--hash-style=both > > -ccflags-$(CONFIG_LD_IS_LLD) += $(call > > cc-option,--ld-path=$(LD),-fuse-ld=lld) > > - > > -CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 > > +ccflags-y := -fno-common -fno-builtin > > +ldflags-y := -Wl,--hash-style=both -nostdlib -shared > > +ldflags-$(CONFIG_LD_IS_LLD) += $(call > > cc-option,--ld-path=$(LD),-fuse-ld=lld) > > +# Filter flags that clang will warn are unused for linking > > +ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%, > > $(KBUILD_CFLAGS)) > > + > > +CC32FLAGS := -m32 > > +LD32FLAGS := -Wl,-soname=linux-vdso32.so.1 > > AS32FLAGS := -D__VDSO32__ > > > > -CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 > > +LD64FLAGS := -Wl,-soname=linux-vdso64.so.1 > > AS64FLAGS := -D__VDSO64__ > > > > targets += vdso32.lds > > @@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h: > > $(obj)/vdso64.so.dbg FORCE > > > > # actual build commands > > quiet_cmd_vdso32ld_and_check = VDSO32L $@ > > - cmd_vdso32ld_and_check = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@ > > -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) > > + cmd_vdso32ld_and_check = $(VDSOCC) $(ldflags-y) $(CC32FLAGS) > > $(LD32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack > > ; $(cmd_vdso_check) > > quiet_cmd_vdso32as = VDSO32A $@ > >cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) $(AS32FLAGS) -c -o > > $@ $< > > quiet_cmd_vdso32cc = VDSO32C $@ > >cmd_vdso32cc = $(VDSOCC) $(c_flags) $(CC32FLAGS) -c -o $@ $< > > > > quiet_cmd_vdso64ld_and_check = VDSO64L $@ > > - cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@ > > -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) > > + cmd_vdso64ld_and_check = $(VDSOCC) $(ldflags-y) $(CC64FLAGS) > > $(LD64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack > > ; $(cmd_vdso_check) > > Let's move `-z noexecstack` up into ldflags-y? (you may add my RB with > that modification) Ack, done locally, will be included in v2. > > quiet_cmd_vdso64as = VDSO64A $@ > >cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o > > $@ $< > > > > > > -- > > 2.39.0 > > > > -- > Thanks, > ~Nick Desaulniers
Re: [PATCH 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
On Mon, Jan 09, 2023 at 01:58:32PM -0800, Nick Desaulniers wrote: > On Wed, Jan 4, 2023 at 11:55 AM Nathan Chancellor wrote: > > > > When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it > > warns that ASFLAGS contains '-s', which is a linking phase option, so it > > is unused. > > > > clang-16: error: argument unused during compilation: '-s' > > [-Werror,-Wunused-command-line-argument] > > > > Looking at the GAS sources, '-s' is only useful when targeting Solaris > > and it is ignored for the powerpc target so just drop the flag > > altogether, as it is not needed. > > Do you have any more info where you found this? I don't see -s > documented as an assembler flag. > https://sourceware.org/binutils/docs/as/PowerPC_002dOpts.html > https://sourceware.org/binutils/docs/as/Invoking.html Sure thing, sorry I did not include it initially. See the section from line 1284 to 1291 or search for "case 's':": https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=9450fa74de1b61542c9a18babf8c8f621ef904fb;hb=HEAD > The patch seems fine to me, but what was this ever supposed to be? > FWICT it predates git history (looking at > arch/powerpc/kernel/vdso32/Makefile at fc15351d9d63) Right, I could not figure it out either, it has been there since the vDSO was introduced back in 2005 (I was three days away from 10!) and there is no comment about it so *shrug*: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=054eb7153aeb84cc92da84210cf93b0e2a34811b If someone else's archeological skills are better and can provide more information, I am happy to include that. > Reviewed-by: Nick Desaulniers Thanks as always for the review! I'll include this and a note about where in binutils I found that information for v2. > > > > Signed-off-by: Nathan Chancellor > > --- > > Cc: m...@ellerman.id.au > > Cc: npig...@gmail.com > > Cc: christophe.le...@csgroup.eu > > Cc: linuxppc-dev@lists.ozlabs.org > > --- > > arch/powerpc/kernel/vdso/Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/powerpc/kernel/vdso/Makefile > > b/arch/powerpc/kernel/vdso/Makefile > > index 6a977b0d8ffc..45c0cc5d34b6 100644 > > --- a/arch/powerpc/kernel/vdso/Makefile > > +++ b/arch/powerpc/kernel/vdso/Makefile > > @@ -51,10 +51,10 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib > > -Wl,--hash-style=both > > ccflags-$(CONFIG_LD_IS_LLD) += $(call > > cc-option,--ld-path=$(LD),-fuse-ld=lld) > > > > CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 > > -AS32FLAGS := -D__VDSO32__ -s > > +AS32FLAGS := -D__VDSO32__ > > > > CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 > > -AS64FLAGS := -D__VDSO64__ -s > > +AS64FLAGS := -D__VDSO64__ > > > > targets += vdso32.lds > > CPPFLAGS_vdso32.lds += -P -C -Upowerpc > > > > -- > > 2.39.0 > > > > -- > Thanks, > ~Nick Desaulniers
[PATCH 07/14] powerpc/vdso: Improve linker flags
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, there are several warnings in the PowerPC vDSO: clang-16: error: -Wl,-soname=linux-vdso32.so.1: 'linker' input unused [-Werror,-Wunused-command-line-argument] clang-16: error: -Wl,--hash-style=both: 'linker' input unused [-Werror,-Wunused-command-line-argument] clang-16: error: argument unused during compilation: '-shared' [-Werror,-Wunused-command-line-argument] clang-16: error: argument unused during compilation: '-nostdinc' [-Werror,-Wunused-command-line-argument] clang-16: error: argument unused during compilation: '-Wa,-maltivec' [-Werror,-Wunused-command-line-argument] The first group of warnings point out that linker flags were being added to all invocations of $(CC), even though they will only be used during the final vDSO link. Move those flags to ldflags-y. The second group of warnings are compiler or assembler flags that will be unused during linking. Filter them out from KBUILD_CFLAGS so that they are not used during linking. Signed-off-by: Nathan Chancellor --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/vdso/Makefile | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 45c0cc5d34b6..769b62832b38 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -47,13 +47,17 @@ KCOV_INSTRUMENT := n UBSAN_SANITIZE := n KASAN_SANITIZE := n -ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both -ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld) - -CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 +ccflags-y := -fno-common -fno-builtin +ldflags-y := -Wl,--hash-style=both -nostdlib -shared +ldflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld) +# Filter flags that clang will warn are unused for linking +ldflags-y += $(filter-out $(CC_FLAGS_FTRACE) -Wa$(comma)%, $(KBUILD_CFLAGS)) + +CC32FLAGS := -m32 +LD32FLAGS := -Wl,-soname=linux-vdso32.so.1 AS32FLAGS := -D__VDSO32__ -CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 +LD64FLAGS := -Wl,-soname=linux-vdso64.so.1 AS64FLAGS := -D__VDSO64__ targets += vdso32.lds @@ -92,14 +96,14 @@ include/generated/vdso64-offsets.h: $(obj)/vdso64.so.dbg FORCE # actual build commands quiet_cmd_vdso32ld_and_check = VDSO32L $@ - cmd_vdso32ld_and_check = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) + cmd_vdso32ld_and_check = $(VDSOCC) $(ldflags-y) $(CC32FLAGS) $(LD32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) quiet_cmd_vdso32as = VDSO32A $@ cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) $(AS32FLAGS) -c -o $@ $< quiet_cmd_vdso32cc = VDSO32C $@ cmd_vdso32cc = $(VDSOCC) $(c_flags) $(CC32FLAGS) -c -o $@ $< quiet_cmd_vdso64ld_and_check = VDSO64L $@ - cmd_vdso64ld_and_check = $(VDSOCC) $(c_flags) $(CC64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) + cmd_vdso64ld_and_check = $(VDSOCC) $(ldflags-y) $(CC64FLAGS) $(LD64FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^) -z noexecstack ; $(cmd_vdso_check) quiet_cmd_vdso64as = VDSO64A $@ cmd_vdso64as = $(VDSOCC) $(a_flags) $(CC64FLAGS) $(AS64FLAGS) -c -o $@ $< -- 2.39.0
[PATCH 06/14] powerpc/vdso: Remove unused '-s' flag from ASFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns that ASFLAGS contains '-s', which is a linking phase option, so it is unused. clang-16: error: argument unused during compilation: '-s' [-Werror,-Wunused-command-line-argument] Looking at the GAS sources, '-s' is only useful when targeting Solaris and it is ignored for the powerpc target so just drop the flag altogether, as it is not needed. Signed-off-by: Nathan Chancellor --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/vdso/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 6a977b0d8ffc..45c0cc5d34b6 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -51,10 +51,10 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld) CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32 -AS32FLAGS := -D__VDSO32__ -s +AS32FLAGS := -D__VDSO32__ CC64FLAGS := -Wl,-soname=linux-vdso64.so.1 -AS64FLAGS := -D__VDSO64__ -s +AS64FLAGS := -D__VDSO64__ targets += vdso32.lds CPPFLAGS_vdso32.lds += -P -C -Upowerpc -- 2.39.0
[PATCH 08/14] powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with clang
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it warns: clang-16: error: argument unused during compilation: '-fno-stack-clash-protection' [-Werror,-Wunused-command-line-argument] This flag is supported for 64-bit powerpc but not 32-bit, hence the warning. Just remove the flag from vgettimeofday-32.o's CFLAGS when using clang, as has been done for other flags previously. Signed-off-by: Nathan Chancellor --- Cc: m...@ellerman.id.au Cc: npig...@gmail.com Cc: christophe.le...@csgroup.eu Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/vdso/Makefile | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile index 769b62832b38..4ee7d36ce752 100644 --- a/arch/powerpc/kernel/vdso/Makefile +++ b/arch/powerpc/kernel/vdso/Makefile @@ -16,6 +16,11 @@ ifneq ($(c-gettimeofday-y),) CFLAGS_vgettimeofday-32.o += -ffreestanding -fasynchronous-unwind-tables CFLAGS_REMOVE_vgettimeofday-32.o = $(CC_FLAGS_FTRACE) CFLAGS_REMOVE_vgettimeofday-32.o += -mcmodel=medium -mabi=elfv1 -mabi=elfv2 -mcall-aixdesc + # This flag is supported by clang for 64-bit but not 32-bit so it will cause + # an unused command line flag warning for this file. + ifdef CONFIG_CC_IS_CLANG + CFLAGS_REMOVE_vgettimeofday-32.o += -fno-stack-clash-protection + endif CFLAGS_vgettimeofday-64.o += -include $(c-gettimeofday-y) CFLAGS_vgettimeofday-64.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_vgettimeofday-64.o += $(call cc-option, -fno-stack-protector) -- 2.39.0
[PATCH 05/14] powerpc: Remove linker flag from KBUILD_AFLAGS
When clang's -Qunused-arguments is dropped from KBUILD_CPPFLAGS, it
points out that KBUILD_AFLAGS contains a linker flag, which will be
used:
clang: error: -Wl,-a32: 'linker' input unused
[-Werror,-Wunused-command-line-argument]
This was likely supposed to be '-Wa,-a$(BITS)'. However, this change is
unnecessary, as all supported versions of clang and gcc will pass '-a64'
or '-a32' to GNU as based on the value of '-m'; the behavior of the
latest stable release of the oldest supported major version of each
compiler is shown below and each compiler's latest release exhibits the
same behavior (GCC 12.2.0 and Clang 15.0.6).
$ powerpc64-linux-gcc --version | head -1
powerpc64-linux-gcc (GCC) 5.5.0
$ powerpc64-linux-gcc -m64 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a64 -mppc64 -many -mbig -o /dev/null /tmp/cctwuBzZ.s
$ powerpc64-linux-gcc -m32 -### -x assembler-with-cpp -c -o /dev/null
/dev/null &| grep 'as '
.../as -a32 -mppc -many -mbig -o /dev/null /tmp/ccaZP4mF.sg
$ clang --version | head -1
Ubuntu clang version
11.1.0-++20211011094159+1fdec59bffc1-1~exp1~20211011214622.5
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a64" "-mppc64" "-many" "-o" "/dev/null"
"/tmp/null-80267c.s"
$ clang --target=powerpc64-linux-gnu -fno-integrated-as -m64 -### \
-x assembler-with-cpp -c -o /dev/null /dev/null &| grep gnu-as
"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "/dev/null"
"/tmp/null-ab8f8d.s"
Remove this flag altogether to avoid future issues.
Fixes: 1421dc6d4829 ("powerpc/kbuild: Use flags variables rather than
overriding LD/CC/AS")
Signed-off-by: Nathan Chancellor
---
Cc: m...@ellerman.id.au
Cc: npig...@gmail.com
Cc: christophe.le...@csgroup.eu
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index dc4cbf0a5ca9..4fd630efe39d 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -90,7 +90,7 @@ aflags-$(CONFIG_CPU_LITTLE_ENDIAN)+= -mlittle-endian
ifeq ($(HAS_BIARCH),y)
KBUILD_CFLAGS += -m$(BITS)
-KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
+KBUILD_AFLAGS += -m$(BITS)
KBUILD_LDFLAGS += -m elf$(BITS)$(LDEMULATION)
endif
--
2.39.0
[PATCH 00/14] Remove clang's -Qunused-arguments from KBUILD_CPPFLAGS
Hi all,
Clang can emit a few different warnings when it encounters a flag that it
recognizes but does not support internally. These warnings are elevated to
errors within {as,cc}-option via -Werror to catch unsupported flags that should
not be added to KBUILD_{A,C}FLAGS; see commit c3f0d0bc5b01 ("kbuild, LLVMLinux:
Add -Werror to cc-option to support clang").
If an unsupported flag is unconditionally to KBUILD_{A,C}FLAGS, all subsequent
{as,cc}-option will always fail, preventing supported and even potentially
necessary flags from getting adding to the tool flags.
One would expect these warnings to be visible in the kernel build logs since
they are added to KBUILD_{A,C}FLAGS but unfortunately, these warnings are
hidden with clang's -Qunused-arguments flag, which is added to KBUILD_CPPFLAGS
and used for both compiling and assembling files.
Patches 1-4 address the internal inconsistencies of invoking the assembler
within kbuild by using KBUILD_AFLAGS consistently and using '-x
assembler-with-cpp' over '-x assembler'. This matches how assembly files are
built across the kernel and helps avoid problems in situations where macro
definitions or warning flags are present in KBUILD_AFLAGS, which cause
instances of -Wunused-command-line-argument when the preprocessor is not called
to consume them. There were a couple of places in architecture code where this
change would break things so those are fixed first.
Patches 5-12 clean up warnings that will show up when -Qunused-argument is
dropped. I hope none of these are controversial.
Patch 13 turns two warnings into errors so that the presence of unused flags
cannot be easily ignored.
Patch 14 drops -Qunused-argument. This is done last so that it can be easily
reverted if need be.
This series has seen my personal test framework, which tests several different
configurations and architectures, with LLVM tip of tree (16.0.0). I have done
defconfig, allmodconfig, and allnoconfig builds for arm, arm64, i386, mips,
powerpc, riscv, s390, and x86_64 with GCC 12.2.0 as well but I am hoping the
rest of the test infrastructure will catch any lurking problems.
I would like this series to stay together so that there is no opportunity for
breakage so please consider giving acks so that this can be carried via the
kbuild tree.
---
Nathan Chancellor (12):
MIPS: Always use -Wa,-msoft-float and eliminate GAS_HAS_SET_HARDFLOAT
MIPS: Prefer cc-option for additions to cflags
powerpc: Remove linker flag from KBUILD_AFLAGS
powerpc/vdso: Remove unused '-s' flag from ASFLAGS
powerpc/vdso: Improve linker flags
powerpc/vdso: Remove an unsupported flag from vgettimeofday-32.o with
clang
s390/vdso: Drop unused '-s' flag from KBUILD_AFLAGS_64
s390/vdso: Drop '-shared' from KBUILD_CFLAGS_64
s390/purgatory: Remove unused '-MD' and unnecessary '-c' flags
drm/amd/display: Do not add '-mhard-float' to dml_ccflags for clang
kbuild: Turn a couple more of clang's unused option warnings into errors
kbuild: Stop using '-Qunused-arguments' with clang
Nick Desaulniers (2):
x86/boot/compressed: prefer cc-option for CFLAGS additions
kbuild: Update assembler calls to use proper flags and language target
Makefile| 1 -
arch/mips/Makefile | 13 ++---
arch/mips/include/asm/asmmacro-32.h | 4 +--
arch/mips/include/asm/asmmacro.h| 42 ++---
arch/mips/include/asm/fpregdef.h| 14 --
arch/mips/include/asm/mipsregs.h| 20 +++---
arch/mips/kernel/genex.S| 2 +-
arch/mips/kernel/r2300_fpu.S| 4 +--
arch/mips/kernel/r4k_fpu.S | 12 -
arch/mips/kvm/fpu.S | 6 ++---
arch/mips/loongson2ef/Platform | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/kernel/vdso/Makefile | 25 +++--
arch/s390/kernel/vdso64/Makefile| 4 +--
arch/s390/purgatory/Makefile| 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dml/Makefile | 3 ++-
scripts/Kconfig.include | 2 +-
scripts/Makefile.clang | 2 ++
scripts/Makefile.compiler | 8 +++---
scripts/as-version.sh | 2 +-
21 files changed, 74 insertions(+), 98 deletions(-)
---
base-commit: 88603b6dc419445847923fcb7fe5080067a30f98
change-id: 20221228-drop-qunused-arguments-0c5c7dae54fb
Best regards,
--
Nathan Chancellor
Re: [PATCH] fbdev: make offb driver tristate
On Sat, Dec 10, 2022 at 05:35:06PM +0100, Helge Deller wrote: > On 11/26/22 14:40, Thomas Zimmermann wrote: > > Am 26.11.22 um 01:04 schrieb Randy Dunlap: > > > Make the offb (Open Firmware frame buffer) driver tristate, > > > i.e., so that it can be built as a loadable module. > > > > > > However, it still depends on the setting of DRM_OFDRM > > > so that both of these drivers cannot be builtin at the same time > > > nor can one be builtin and the other one a loadable module. > > > > > > Build-tested successfully with all combination of DRM_OFDRM and FB_OF. > > > > > > This fixes a build issue that Michal reported when FB_OF=y and > > > DRM_OFDRM=m: > > > > > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): > > > undefined reference to `cfb_fillrect' > > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): > > > undefined reference to `cfb_copyarea' > > > powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): > > > undefined reference to `cfb_imageblit' > > > > > > Signed-off-by: Randy Dunlap > > > Suggested-by: Arnd Bergmann > > > Cc: Masahiro Yamada > > > Cc: Thomas Zimmermann > > > Cc: Michal Suchánek > > > Cc: linuxppc-dev@lists.ozlabs.org > > > Cc: Daniel Vetter > > > Cc: Helge Deller > > > Cc: linux-fb...@vger.kernel.org > > > Cc: dri-de...@lists.freedesktop.org > > > > Acked-by: Thomas Zimmermann > > applied. Is this going to make it to Linus soon? We are now seeing this error in our CI, which has the configuration describe in this commit. https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/3785609002/jobs/6437398666#step:5:149 https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2JUMSmjAoSJoKfl6PPjfU66JGit/build.log Cheers, Nathan > > > --- > > > drivers/video/fbdev/Kconfig | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > > > --- a/drivers/video/fbdev/Kconfig > > > +++ b/drivers/video/fbdev/Kconfig > > > @@ -456,8 +456,8 @@ config FB_ATARI > > > chipset found in Ataris. > > > config FB_OF > > > - bool "Open Firmware frame buffer device support" > > > - depends on (FB = y) && PPC && (!PPC_PSERIES || PCI) > > > + tristate "Open Firmware frame buffer device support" > > > + depends on FB && PPC && (!PPC_PSERIES || PCI) > > > depends on !DRM_OFDRM > > > select APERTURE_HELPERS > > > select FB_CFB_FILLRECT > > > >
Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
On Wed, Sep 28, 2022 at 12:13:53PM -0700, Josh Poimboeuf wrote:
> On Wed, Sep 28, 2022 at 08:44:27AM -0700, Nathan Chancellor wrote:
> > This crash appears to just be a symptom of objtool erroring throughout
> > the entire build, which means things like the jump label hacks do not
> > get applied. I see a flood of
> >
> > error: objtool: --mnop requires --mcount
> >
> > throughout the build because the configuration has
> > CONFIG_HAVE_NOP_MCOUNT=y because CONFIG_HAVE_OBJTOOL_MCOUNT is
> > unconditionally enabled for x86_64 due to CONFIG_HAVE_OBJTOOL but
> > '--mcount' is only actually used when CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
> > is enabled so '--mnop' gets passed in without '--mcount'. This should
> > obviously be fixed somehow, perhaps by moving the '--mnop' addition into
> > the '--mcount' if, even if that makes the line really long.
> >
> > A secondary issue is that it seems like if objtool encounters a fatal
> > error like this, it should completely fail the build to make it obvious
> > that something is wrong, rather than allowing it to continue and
> > generate a broken kernel, especially since x86_64 requires objtool to
> > build a working kernel at this point.
>
> Grrr... I really dislike that objtool is capable of bricking the kernel
> like this. We just saw something similar in RHEL.
>
> IMO, we should just get rid of this "short JMP" feature in the jump
> label code, those saved three bytes aren't worth the pain.
>
> But yes, we do need to fix that config issue.
Right, I actually see that the report I was CC'd on was a part of a
larger thread, where Naveen already suggested the fix for this problem,
which is not clang specific it seems:
https://lore.kernel.org/1663223588.wppdx3129x.nav...@linux.ibm.com/
> And yes, maybe fatal objtool warnings should cause a build failure. We
> used to do that, but it brought a different sort of pain. But if
> objtool is going to be in the kernel's critical boot path then I guess
> we have to do that.
Right, that was
644592d32837 ("objtool: Fail the kernel build on fatal errors")
which was reverted in
655cf86548a3 ("objtool: Don't fail the kernel build on fatal errors")
objtool should not error on warnings but it seems like it should error
for invalid option combinations and other misconfiguration problems? Did
this regress with commit b51277eb9775 ("objtool: Ditch subcommands")? I
can see that the return code of the subcommands would be passed back via
exit() (?) so objtool could fail the build if there was a true problem
but after that change, objtool_run() does not have its return code
checked so any errors that happen don't get passed back up. Perhaps just
the following diff would resolve this? I assume we would need to look at
all the different return values to know if this is safe though.
Cheers,
Nathan
diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c
index a7ecc32e3512..cda649644e32 100644
--- a/tools/objtool/objtool.c
+++ b/tools/objtool/objtool.c
@@ -146,7 +146,5 @@ int main(int argc, const char **argv)
exec_cmd_init("objtool", UNUSED, UNUSED, UNUSED);
pager_init(UNUSED);
- objtool_run(argc, argv);
-
- return 0;
+ return objtool_run(argc, argv);
}
Re: [objtool] ca5e2b42c0: kernel_BUG_at_arch/x86/kernel/jump_label.c
Hi all,
On Wed, Sep 28, 2022 at 08:48:53AM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed the following commit (built with clang-14):
>
> commit: ca5e2b42c0d4438ba93623579b6860b98f3598f3 ("[PATCH v3 11/16] objtool:
> Add --mnop as an option to --mcount")
> url:
> https://github.com/intel-lab-lkp/linux/commits/Sathvika-Vasireddy/objtool-Enable-and-implement-mcount-option-on-powerpc/20220912-163023
> base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git
> topic/ppc-kvm
> patch link:
> https://lore.kernel.org/linuxppc-dev/20220912082020.226755-12...@linux.ibm.com
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> [ 152.068363][T0] jump_label: Fatal kernel bug, unexpected op at
> trace_initcall_start+0xc/0x180 [810016ec] (e9 c9 00 00 00 != 0f 1f 44
> 00 00)) size:5 type:1
> [ 152.070368][T0] [ cut here ]
> [ 152.071050][T0] kernel BUG at arch/x86/kernel/jump_label.c:73!
> [ 152.071825][T0] invalid opcode: [#1] SMP KASAN PTI
> [ 152.072427][T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 6.0.0-rc2-00011-gca5e2b42c0d4 #1 96a19ca45386d518c4bccc5b3bc53f548a2dc122
> [ 152.073837][T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [ 152.075461][T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.076162][T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83
> 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08
> <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.078374][T0] RSP: :84607cb8 EFLAGS: 00010086
> [ 152.079159][T0] RAX: 0092 RBX: 8380f62a RCX:
> 84634d80
> [ 152.080100][T0] RDX: RSI: ffea RDI:
> fffe
> [ 152.081020][T0] RBP: 855d9f60 R08: 8124f17c R09:
> fbfff08c0f53
> [ 152.081936][T0] R10: d7fff08c0f54 R11: 108c0f52 R12:
> 0001
> [ 152.082832][T0] R13: 0005 R14: 8380f62a R15:
> 810016ec
> [ 152.083744][T0] FS: () GS:8883aee0()
> knlGS:
> [ 152.084763][T0] CS: 0010 DS: ES: CR0: 80050033
> [ 152.085567][T0] CR2: 88843000 CR3: 04628000 CR4:
> 000406b0
> [ 152.086472][T0] DR0: DR1: DR2:
>
> [ 152.087407][T0] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 152.088326][T0] Call Trace:
> [ 152.088702][T0]
> [ 152.089042][T0] ? trace_initcall_start+0xc/0x180
> [ 152.089660][T0] ? trace_initcall_start+0x1b/0x180
> [ 152.090281][T0] ? trace_initcall_start+0x11/0x180
> [ 152.091237][T0] ? jump_label_transform+0x25/0xd0
> [ 152.091923][T0] ? arch_jump_label_transform_queue+0x87/0xd0
> [ 152.092651][T0] ? __jump_label_update+0x192/0x3b0
> [ 152.093320][T0] ? static_key_enable_cpuslocked+0x129/0x250
> [ 152.094020][T0] ? rcu_lock_release+0x20/0x20
> [ 152.094573][T0] ? static_key_enable+0x16/0x20
> [ 152.095167][T0] ? tracepoint_add_func+0x87e/0x9d0
> [ 152.095822][T0] ? rcu_lock_release+0x20/0x20
> [ 152.096394][T0] ? tracepoint_probe_register+0x99/0xd0
> [ 152.097055][T0] ? rcu_lock_release+0x20/0x20
> [ 152.097606][T0] ? initcall_debug_enable+0x21/0x6b
> [ 152.098305][T0] ? start_kernel+0x24b/0x4e6
> [ 152.098861][T0] ? secondary_startup_64_no_verify+0xce/0xdb
> [ 152.099556][T0]
> [ 152.099891][T0] Modules linked in:
> [ 152.100352][T0] ---[ end trace ]---
> [ 152.100980][T0] RIP: 0010:__jump_label_patch+0x340/0x350
> [ 152.101652][T0] Code: 00 48 89 da e9 51 fe ff ff 48 c7 c7 00 d1 80 83
> 4c 89 fe 4c 89 fa 4c 89 f9 49 89 d8 45 89 e9 41 54 e8 f2 91 34 02 48 83 c4 08
> <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 84 00 00 00 00 00 48 c7 c7 00 09 69
> [ 152.103892][T0] RSP: :84607cb8 EFLAGS: 00010086
> [ 152.104544][T0] RAX: 0092 RBX: 8380f62a RCX:
> 84634d80
> [ 152.105421][T0] RDX: RSI: ffea RDI:
> fffe
> [ 152.106280][T0] RBP: 855d9f60 R08: 8124f17c R09:
> fbfff08c0f53
> [ 152.107182][T0] R10: d7fff08c0f54 R11: 108c0f52 R12:
> 0001
> [ 152.108110][T0] R13: 0005 R14: 8380f62a R15:
> 810016ec
> [ 152.109002][T0] FS: () GS:8883aee0()
> knlGS:
> [ 152.109986][T0] CS: 0010 DS: ES: CR0: 80050033
> [ 152.110796][T0] CR2: 88843000 CR3: 04628000
Re: [PATCH] powerpc/pseries: Fix plpks crash on non-pseries
On Wed, Sep 07, 2022 at 04:50:38PM +1000, Michael Ellerman wrote:
> As reported[1] by Nathan, the recently added plpks driver will crash if
> it's built into the kernel and booted on a non-pseries machine, eg
> powernv:
>
> kernel BUG at arch/powerpc/kernel/syscall.c:39!
> Oops: Exception in kernel mode, sig: 5 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
> ...
> NIP system_call_exception+0x90/0x3d0
> LR system_call_common+0xec/0x250
> Call Trace:
> 0xc35c3e10 (unreliable)
> system_call_common+0xec/0x250
> --- interrupt: c00 at plpar_hcall+0x38/0x60
> NIP: c00e4300 LR: c202945c CTR:
> REGS: c35c3e80 TRAP: 0c00 Not tainted (6.0.0-rc4)
> MSR: 92009033 CR: 28000284 XER:
>
> ...
> NIP plpar_hcall+0x38/0x60
> LR pseries_plpks_init+0x64/0x23c
> --- interrupt: c00
>
> On powernv Linux is the hypervisor, so a hypercall just ends up going to
> the syscall path, which BUGs if the syscall (hypercall) didn't come from
> userspace.
>
> The fix is simply to not probe the plpks driver on non-pseries machines.
>
> [1]
> https://lore.kernel.org/linuxppc-dev/Yxe06fbq18Wv9y3W@dev-arch.thelio-3990X/
>
> Fixes: 2454a7af0f2a ("powerpc/pseries: define driver for Platform KeyStore")
> Reported-by: Nathan Chancellor
> Signed-off-by: Michael Ellerman
Tested-by: Nathan Chancellor
Thanks!
> ---
> arch/powerpc/platforms/pseries/plpks.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/plpks.c
> b/arch/powerpc/platforms/pseries/plpks.c
> index 52aaa2894606..f4b5b5a64db3 100644
> --- a/arch/powerpc/platforms/pseries/plpks.c
> +++ b/arch/powerpc/platforms/pseries/plpks.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include "plpks.h"
>
> @@ -457,4 +458,4 @@ static __init int pseries_plpks_init(void)
>
> return rc;
> }
> -arch_initcall(pseries_plpks_init);
> +machine_arch_initcall(pseries, pseries_plpks_init);
> --
> 2.37.2
>
Re: [PATCH v2 1/3] powerpc/pseries: define driver for Platform KeyStore
On Wed, Sep 07, 2022 at 09:23:02AM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > Hi all,
> >
> > On Sat, Jul 23, 2022 at 07:30:46AM -0400, Nayna Jain wrote:
> >> PowerVM provides an isolated Platform Keystore(PKS) storage allocation
> >> for each LPAR with individually managed access controls to store
> >> sensitive information securely. It provides a new set of hypervisor
> >> calls for Linux kernel to access PKS storage.
> >>
> >> Define POWER LPAR Platform KeyStore(PLPKS) driver using H_CALL interface
> >> to access PKS storage.
> >>
> >> Signed-off-by: Nayna Jain
> >
> > This commit is now in mainline as commit 2454a7af0f2a ("powerpc/pseries:
> > define driver for Platform KeyStore") and I just bisected a crash while
> > boot testing Fedora's configuration [1] in QEMU to it. I initially
> > noticed this in ClangBuiltLinux's CI but this doesn't appear to be clang
> > specific since I can reproduce with GCC 12.2.1 from Fedora. I can
> > reproduce with just powernv_defconfig + CONFIG_PPC_PSERIES=y +
> > CONFIG_PSERIES_PLPKS=y. Our firmware and rootfs are available in our
> > boot-utils repository [2].
>
> Thanks, classic bug I should have spotted.
>
> I didn't catch it in my testing because PLPKS isn't enabled in
> our defconfigs.
>
> Does your CI enable new options by default? Or are you booting
> allyesconfig?
Neither actually. We just test a bunch of in-tree and distribution
configurations. The distribution configurations are fetched straight
from their URLs on gitweb so we get any updates that they do, which is
how we noticed this (CONFIG_PSERIES_PLPKS was recently enabled in
Fedora):
https://src.fedoraproject.org/rpms/kernel/c/a73f6858a2cbd16bbcc6d305d6c43aab6f59d0b1
> I'll send a fix.
Thanks for the quick response!
Cheers,
Nathan
Re: [PATCH v2 1/3] powerpc/pseries: define driver for Platform KeyStore
Hi all,
On Sat, Jul 23, 2022 at 07:30:46AM -0400, Nayna Jain wrote:
> PowerVM provides an isolated Platform Keystore(PKS) storage allocation
> for each LPAR with individually managed access controls to store
> sensitive information securely. It provides a new set of hypervisor
> calls for Linux kernel to access PKS storage.
>
> Define POWER LPAR Platform KeyStore(PLPKS) driver using H_CALL interface
> to access PKS storage.
>
> Signed-off-by: Nayna Jain
This commit is now in mainline as commit 2454a7af0f2a ("powerpc/pseries:
define driver for Platform KeyStore") and I just bisected a crash while
boot testing Fedora's configuration [1] in QEMU to it. I initially
noticed this in ClangBuiltLinux's CI but this doesn't appear to be clang
specific since I can reproduce with GCC 12.2.1 from Fedora. I can
reproduce with just powernv_defconfig + CONFIG_PPC_PSERIES=y +
CONFIG_PSERIES_PLPKS=y. Our firmware and rootfs are available in our
boot-utils repository [2].
$ qemu-system-ppc64 \
-device ipmi-bmc-sim,id=bmc0 \
-device isa-ipmi-bt,bmc=bmc0,irq=10 \
-L .../boot-utils/images/ppc64le \
-bios skiboot.lid \
-machine powernv8 \
-kernel arch/powerpc/boot/zImage.epapr \
-display none \
-initrd .../boot-utils/images/ppc64le/rootfs.cpio \
-m 2G \
-nodefaults \
-no-reboot \
-serial mon:stdio
...
[0.00][T0] Linux version 5.19.0-rc2-00179-g2454a7af0f2a
(tuxmake@tuxmake) (powerpc64le-linux-gnu-gcc (GCC) 12.2.1 20220819 (Red Hat
Cross 12.2.1-1), GNU ld version 2.38-4.fc37) #1 SMP @1658989333
...
[0.144318][T1] EEH: PowerNV platform initialized
[0.145204][T1] [ cut here ]
[0.145400][T1] kernel BUG at arch/powerpc/kernel/interrupt.c:96!
[0.145674][T1] Oops: Exception in kernel mode, sig: 5 [#1]
[0.147691][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[0.148177][T1] Modules linked in:
[0.148619][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.19.0-rc2-00179-g2454a7af0f2a #1
[0.149328][T1] NIP: c002ea2c LR: c000c63c CTR:
c000c540
[0.149851][T1] REGS: c2a03b10 TRAP: 0700 Not tainted
(5.19.0-rc2-00179-g2454a7af0f2a)
[0.150478][T1] MSR: 90029033 CR:
24000282 XER: 2000
[0.151240][T1] CFAR: c000c638 IRQMASK: 3
[0.151240][T1] GPR00: c000c63c c2a03db0
c240ba00 041c
[0.151240][T1] GPR04: 02a03b98 0020
7dcf
[0.151240][T1] GPR08:
0001 0003
[0.151240][T1] GPR12: c25c
c00125f8
[0.151240][T1] GPR16:
[0.151240][T1] GPR20:
[0.151240][T1] GPR24:
7dcf 0020
[0.151240][T1] GPR28: 02a03b98 041c
24000282 c2a03e80
[0.156459][T1] NIP [c002ea2c] system_call_exception+0x7c/0x370
[0.157366][T1] LR [c000c63c] system_call_common+0xec/0x250
[0.157991][T1] Call Trace:
[0.158255][T1] [c2a03db0] [c0012620]
kernel_init+0x30/0x1a0 (unreliable)
[0.158936][T1] [c2a03e10] [c000c63c]
system_call_common+0xec/0x250
[0.159514][T1] --- interrupt: c00 at plpar_hcall+0x38/0x60
[0.159956][T1] NIP: c00d4bc0 LR: c2021664 CTR:
[0.160469][T1] REGS: c2a03e80 TRAP: 0c00 Not tainted
(5.19.0-rc2-00179-g2454a7af0f2a)
[0.161068][T1] MSR: 92009033
CR: 24000282 XER:
[0.161792][T1] IRQMASK: 0
[0.161792][T1] GPR00: 24000282 c2a03b30
c240ba00 041c
[0.161792][T1] GPR04: 02a03b98 0020
7dcf
[0.161792][T1] GPR08:
[0.161792][T1] GPR12: c25c
c00125f8
[0.161792][T1] GPR16:
[0.161792][T1] GPR20:
[0.161792][T1] GPR24: c200015c
cccd c2071048
[0.161792][T1] GPR28: c2071088
0003 c20215f0
[0.166796][T1] NIP [c00d4bc0] plpar_hcall+0x38/0x60
[0.167215][T1] LR [c2021664] pseries_plpks_init+0x74/0x268
[0.167705][T1] --- interrupt: c00
[0.167959][T1] [c2a03b30] [7dcf] 0x7dcf
(unreliable)
[0.168763][T1] Instruction dump:
[0.169099][T1]
Re: [PATCH v2 2/2] powerpc/math-emu: Remove -w build flag and fix warnings
On Fri, Sep 02, 2022 at 10:59:54AM -0500, Segher Boessenkool wrote: > On Fri, Sep 02, 2022 at 08:37:23AM -0700, Nathan Chancellor wrote: > > On Fri, Sep 02, 2022 at 12:08:55PM +0200, Christophe Leroy wrote: > > > This should have been detected by gcc at build time, but due to > > > '-w' flag it went undetected. > > > > > > Removing that flag leads to many warnings hence errors. > > > Thanks for figuring out what was going on here! I took this patch for a > > spin with clang and it has a few more errors around > > -Wimplicit-fallthrough: > > Maybe add -Wno-implicit-fallthrough? This code is a copy from outside > the kernel, no one has ever wanted to maintain it, if nothing else (the > more politically correct formulation is "we cannot as easily pick up > improvements from upstream if we modify stuff"). Sure, we could do something like this if you preferred: diff --git a/arch/powerpc/math-emu/Makefile b/arch/powerpc/math-emu/Makefile index 26fef2e5672e..ed775747a2a5 100644 --- a/arch/powerpc/math-emu/Makefile +++ b/arch/powerpc/math-emu/Makefile @@ -16,3 +16,7 @@ obj-$(CONFIG_SPE) += math_efp.o CFLAGS_fabs.o = -fno-builtin-fabs CFLAGS_math.o = -fno-builtin-fabs + +ifdef CONFIG_CC_IS_CLANG +ccflags-remove-y := $(CONFIG_CC_IMPLICIT_FALLTHROUGH) +endif At the same time, I see other modifications to these files that appear to be for the kernel only so I suspect that this is already in the "we cannot as easily pick up improvements from upstream" category, regardless of that diff. No strong opinion from me, although I see Christophe already included my suggestion in the most recent series: https://lore.kernel.org/2663961738a46073713786d4efeb53100ca156e7.1662134272.git.christophe.le...@csgroup.eu/ Cheers, Nathan
Re: [PATCH v2 2/2] powerpc/math-emu: Remove -w build flag and fix warnings
Hi Christophe, On Fri, Sep 02, 2022 at 12:08:55PM +0200, Christophe Leroy wrote: > As reported by Nathan, the module_init() macro was not taken into > account because the header was missing. That means spe_mathemu_init() > was never called. > > This should have been detected by gcc at build time, but due to > '-w' flag it went undetected. > > Removing that flag leads to many warnings hence errors. > > Fix those warnings then remove the -w flag. > > Reported-by: Nathan Chancellor > Signed-off-by: Christophe Leroy Thanks for figuring out what was going on here! I took this patch for a spin with clang and it has a few more errors around -Wimplicit-fallthrough: arch/powerpc/math-emu/fctiw.c:18:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] FP_TO_INT_D(r, B, 32, 1); ^ ./include/math-emu/double.h:120:34: note: expanded from macro 'FP_TO_INT_D' #define FP_TO_INT_D(r,X,rsz,rsg)_FP_TO_INT(D,2,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:665:4: note: expanded from macro '_FP_TO_INT' case FP_CLS_ZERO: \ ^ arch/powerpc/math-emu/fctiw.c:18:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] ./include/math-emu/double.h:120:34: note: expanded from macro 'FP_TO_INT_D' #define FP_TO_INT_D(r,X,rsz,rsg)_FP_TO_INT(D,2,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:671:4: note: expanded from macro '_FP_TO_INT' case FP_CLS_NAN: \ ^ 2 errors generated. arch/powerpc/math-emu/fctiwz.c:23:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] FP_TO_INT_D(r, B, 32, 1); ^ ./include/math-emu/double.h:120:34: note: expanded from macro 'FP_TO_INT_D' #define FP_TO_INT_D(r,X,rsz,rsg)_FP_TO_INT(D,2,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:665:4: note: expanded from macro '_FP_TO_INT' case FP_CLS_ZERO: \ ^ arch/powerpc/math-emu/fctiwz.c:23:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] ./include/math-emu/double.h:120:34: note: expanded from macro 'FP_TO_INT_D' #define FP_TO_INT_D(r,X,rsz,rsg)_FP_TO_INT(D,2,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:671:4: note: expanded from macro '_FP_TO_INT' case FP_CLS_NAN: \ ^ 2 errors generated. make[3]: *** [scripts/Makefile.build:249: arch/powerpc/math-emu/fctiw.o] Error 1 make[3]: *** [scripts/Makefile.build:249: arch/powerpc/math-emu/fctiwz.o] Error 1 arch/powerpc/math-emu/math_efp.c:282:5: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] FP_TO_INT_ROUND_S(vc.wp[1], SB, 32, ^ ./include/math-emu/single.h:110:40: note: expanded from macro 'FP_TO_INT_ROUND_S' #define FP_TO_INT_ROUND_S(r,X,rsz,rsg) _FP_TO_INT_ROUND(S,1,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:770:4: note: expanded from macro '_FP_TO_INT_ROUND' case FP_CLS_NAN: \ ^ arch/powerpc/math-emu/math_efp.c:305:5: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] FP_TO_INT_ROUND_S(vc.wp[1], SB, 32, ^ ./include/math-emu/single.h:110:40: note: expanded from macro 'FP_TO_INT_ROUND_S' #define FP_TO_INT_ROUND_S(r,X,rsz,rsg) _FP_TO_INT_ROUND(S,1,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:770:4: note: expanded from macro '_FP_TO_INT_ROUND' case FP_CLS_NAN: \ ^ arch/powerpc/math-emu/math_efp.c:316:5: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] FP_TO_INT_S(vc.wp[1], SB, 32, ^ ./include/math-emu/single.h:109:34: note: expanded from macro 'FP_TO_INT_S' #define FP_TO_INT_S(r,X,rsz,rsg)_FP_TO_INT(S,1,r,X,rsz,rsg) ^ ./include/math-emu/op-common.h:665:4: note: expand
[PATCH] powerpc/math_emu/efp: Include module.h
When building with a recent version of clang, there are a couple of
errors around the call to module_init():
arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing,
defaults to 'int'; ISO C99 and later do not support implicit int
[-Wimplicit-int]
module_init(spe_mathemu_init);
^
int
arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without
types is only allowed in a function definition
module_init(spe_mathemu_init);
^
2 errors generated.
module_init() is a macro, which is not getting expanded because module.h
is not included in this file. Add the include so that the macro can
expand properly, clearing up the build failure.
Reported-by: kernel test robot
Signed-off-by: Nathan Chancellor
---
No Fixes tag because it seems likely that this is a transient include
issue (the code builds with GCC). The robot blamed commit e8c07082a810
("Kbuild: move to -std=gnu11") but I think that just exposed these
errors, not caused them.
arch/powerpc/math-emu/math_efp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/math-emu/math_efp.c b/arch/powerpc/math-emu/math_efp.c
index 39b84e7452e1..aa3bb8da1cb9 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
base-commit: dcf8e5633e2e69ad60b730ab5905608b756a032f
--
2.37.3
Re: [PATCH 2/2] powerpc: remove old code for binutils < 2.25
On Tue, Aug 30, 2022 at 02:13:20PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 30, 2022 at 12:10 PM Masahiro Yamada wrote:
> >
> > The minimum supported version of binutils has been raised to 2.25.1.
> > Drop the old code.
> >
> > PPC is the last user of ld-ifversion. With all the callers removed,
> > the macro definition in scripts/Makefile.compiler can go away.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > arch/powerpc/Makefile | 21 -
> > arch/powerpc/lib/Makefile | 8
> > scripts/Makefile.compiler | 4
> > 3 files changed, 33 deletions(-)
> >
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 02742facf895..fb607758eeca 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -46,13 +46,7 @@ UTS_MACHINE := $(subst $(space),,$(machine-y))
> > ifdef CONFIG_PPC32
> > KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> > else
> > -ifeq ($(call ld-ifversion, -ge, 22500, y),y)
> > -# Have the linker provide sfpr if possible.
>
> ^ Perhaps this comment is still relevant and should not yet be
> discarded? Or updated, dropping " if possible".
>
> Either way:
> Reviewed-by: Nick Desaulniers
I think we still want this block for ld.lld. Prior to this change,
ld.lld would fail the ld-ifversion check and use crtsavres.o. Now, it
will try to use '--save-restore-funcs', which it doesn't have support
for, breaking the build for at least powernv_defconfig:
ld.lld: error: unknown argument '--save-restore-funcs'
> > -# There is a corresponding test in arch/powerpc/lib/Makefile
> > KBUILD_LDFLAGS_MODULE += --save-restore-funcs
> > -else
> > -KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
> > -endif
> > endif
> >
> > ifdef CONFIG_CPU_LITTLE_ENDIAN
> > @@ -395,8 +389,6 @@ vdso_prepare: prepare0
> > $(build)=arch/powerpc/kernel/vdso
> > include/generated/vdso64-offsets.h)
> > endif
> >
> > -archprepare: checkbin
> > -
> > archheaders:
> > $(Q)$(MAKE) $(build)=arch/powerpc/kernel/syscalls all
> >
> > @@ -411,16 +403,3 @@ else
> > $(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk
> > '{if ($$2 == "TASK_CANARY") print $$3;}' include/generated/asm-offsets.h))
> > endif
> > endif
> > -
> > -PHONY += checkbin
> > -# Check toolchain versions:
> > -# - gcc-4.6 is the minimum kernel-wide version so nothing required.
> > -checkbin:
> > - @if test "x${CONFIG_LD_IS_LLD}" != "xy" -a \
> > - "x$(call ld-ifversion, -le, 22400, y)" = "xy" ; then \
> > - echo -n '*** binutils 2.24 miscompiles weak symbols ' ; \
> > - echo 'in some circumstances.' ; \
> > - echo'*** binutils 2.23 do not define the TOC symbol ' ;
> > \
> > - echo -n '*** Please use a different binutils version.' ; \
> > - false ; \
> > - fi
> > diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> > index 8560c912186d..5eb3971ccb9c 100644
> > --- a/arch/powerpc/lib/Makefile
> > +++ b/arch/powerpc/lib/Makefile
> > @@ -38,14 +38,6 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o crtsavres.o
> >
> > obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
> >
> > -# See corresponding test in arch/powerpc/Makefile
> > -# 64-bit linker creates .sfpr on demand for final link (vmlinux),
> > -# so it is only needed for modules, and only for older linkers which
> > -# do not support --save-restore-funcs
> > -ifeq ($(call ld-ifversion, -lt, 22500, y),y)
> > -extra-$(CONFIG_PPC64) += crtsavres.o
> > -endif
> > -
> > obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \
> >memcpy_power7.o restart_table.o
> >
> > diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
> > index 94d0d40cddb3..63e7d79dd877 100644
> > --- a/scripts/Makefile.compiler
> > +++ b/scripts/Makefile.compiler
> > @@ -68,7 +68,3 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1)
> > $(2)000 ] && echo $(3) || e
> > # ld-option
> > # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
> > ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
> > -
> > -# ld-ifversion
> > -# Usage: $(call ld-ifversion, -ge, 22252, y)
> > -ld-ifversion = $(shell [ $(CONFIG_LD_VERSION)0 $(1) $(2)0 ] && echo $(3)
> > || echo $(4))
> > --
> > 2.34.1
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
[PATCH] powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register()
Clang warns:
arch/powerpc/platforms/pseries/papr_scm.c:492:6: warning: variable 'rc' is
used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (!p->stat_buffer_len)
^~~
arch/powerpc/platforms/pseries/papr_scm.c:523:64: note: uninitialized use
occurs here
dev_info(&p->pdev->dev, "nvdimm pmu didn't register rc=%d\n", rc);
^~
include/linux/dev_printk.h:150:67: note: expanded from macro 'dev_info'
dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt),
##__VA_ARGS__)
^~~
include/linux/dev_printk.h:110:23: note: expanded from macro
'dev_printk_index_wrap'
_p_func(dev, fmt, ##__VA_ARGS__); \
^~~
arch/powerpc/platforms/pseries/papr_scm.c:492:2: note: remove the 'if' if its
condition is always false
if (!p->stat_buffer_len)
^~~~
arch/powerpc/platforms/pseries/papr_scm.c:484:8: note: initialize the
variable 'rc' to silence this warning
int rc, nodeid;
^
= 0
1 warning generated.
The call to papr_scm_pmu_check_events() was eliminated but a return code
was not added to the if statement. Add the same return code from
papr_scm_pmu_check_events() for this condition so there is no more
warning.
Fixes: 9b1ac04698a4 ("powerpc/papr_scm: Fix nvdimm event mappings")
Link: https://github.com/ClangBuiltLinux/linux/issues/1701
Signed-off-by: Nathan Chancellor
---
arch/powerpc/platforms/pseries/papr_scm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c
b/arch/powerpc/platforms/pseries/papr_scm.c
index 54740af21557..2f8385523a13 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -489,8 +489,10 @@ static void papr_scm_pmu_register(struct papr_scm_priv *p)
goto pmu_err_print;
}
- if (!p->stat_buffer_len)
+ if (!p->stat_buffer_len) {
+ rc = -ENOENT;
goto pmu_check_events_err;
+ }
nd_pmu->pmu.task_ctx_nr = perf_invalid_context;
nd_pmu->pmu.name = nvdimm_name(p->nvdimm);
base-commit: 91926d8b7e71aaf5f84f0cf208fc5a8b7a761050
--
2.37.2
Re: [PATCH v2] powerpc/kexec: Fix build failure from uninitialised variable
On Wed, Aug 10, 2022 at 03:43:31PM +1000, Russell Currey wrote:
> clang 14 won't build because ret is uninitialised and can be returned if
> both prop and fdtprop are NULL. Drop the ret variable and return an
> error in that failure case.
>
> Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of
> ibm,dma-window")
> Suggested-by: Christophe Leroy
> Signed-off-by: Russell Currey
Reviewed-by: Nathan Chancellor
Thanks for the patch!
> ---
> v2: adopt Christophe's suggestion, which is better
>
> arch/powerpc/kexec/file_load_64.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index 683462e4556b..349a781cea0b 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -1043,17 +1043,17 @@ static int copy_property(void *fdt, int node_offset,
> const struct device_node *d
>const char *propname)
> {
> const void *prop, *fdtprop;
> - int len = 0, fdtlen = 0, ret;
> + int len = 0, fdtlen = 0;
>
> prop = of_get_property(dn, propname, &len);
> fdtprop = fdt_getprop(fdt, node_offset, propname, &fdtlen);
>
> if (fdtprop && !prop)
> - ret = fdt_delprop(fdt, node_offset, propname);
> + return fdt_delprop(fdt, node_offset, propname);
> else if (prop)
> - ret = fdt_setprop(fdt, node_offset, propname, prop, len);
> -
> - return ret;
> + return fdt_setprop(fdt, node_offset, propname, prop, len);
> + else
> + return -FDT_ERR_NOTFOUND;
> }
>
> static int update_pci_dma_nodes(void *fdt, const char *dmapropname)
> --
> 2.37.1
>
Re: [PATCH kernel v2] pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window
Hi Alexey,
This change is now in mainline as commit b1fc44eaa9ba
("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window").
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index b4981b651d9a..5d2c22aa34fb 100644
> --- a/arch/powerpc/kexec/file_load_64.c
> +++ b/arch/powerpc/kexec/file_load_64.c
> @@ -1038,6 +1038,48 @@ static int update_cpus_node(void *fdt)
> return ret;
> }
>
> +static int copy_property(void *fdt, int node_offset, const struct
> device_node *dn,
> + const char *propname)
> +{
> + const void *prop, *fdtprop;
> + int len = 0, fdtlen = 0, ret;
> +
> + prop = of_get_property(dn, propname, &len);
> + fdtprop = fdt_getprop(fdt, node_offset, propname, &fdtlen);
> +
> + if (fdtprop && !prop)
> + ret = fdt_delprop(fdt, node_offset, propname);
> + else if (prop)
> + ret = fdt_setprop(fdt, node_offset, propname, prop, len);
> +
> + return ret;
> +}
clang now warns/errors:
arch/powerpc/kexec/file_load_64.c:1053:11: error: variable 'ret' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
else if (prop)
^~~~
arch/powerpc/kexec/file_load_64.c:1056:9: note: uninitialized use occurs here
return ret;
^~~
arch/powerpc/kexec/file_load_64.c:1053:7: note: remove the 'if' if its
condition is always true
else if (prop)
^
arch/powerpc/kexec/file_load_64.c:1046:30: note: initialize the variable
'ret' to silence this warning
int len = 0, fdtlen = 0, ret;
^
= 0
1 error generated.
Is !fdtprop && !prop a concern? What should a sensible default for ret
be?
Cheers,
Nathan
Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful
On Wed, Jun 01, 2022 at 08:21:41PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 11:11:57AM -0700, Nathan Chancellor wrote:
> > On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote:
> > > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote:
> > > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote:
> > > > > Can you send me the full dmesg and the content of
> > > > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot?
> > > >
> > > > Sure thing, they are attached! If there is anything else I can provide
> > > > or test, I am more than happy to do so.
> > >
> > > Nothing interesting. But the performance numbers almost look like
> > > swiotlb=force got ignored before (even if I can't explain why).
> >
> > I was able to get my performance back with this diff but I don't know if
> > this is a hack or a proper fix in the context of the series.
>
> This looks good, but needs a little tweak. I'd go for this variant of
> it:
Tested-by: Nathan Chancellor
Thanks a lot for the quick fix!
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index dfa1de89dc944..cb50f8d383606 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -192,7 +192,7 @@ void __init swiotlb_update_mem_attributes(void)
> }
>
> static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t
> start,
> - unsigned long nslabs, bool late_alloc)
> + unsigned long nslabs, unsigned int flags, bool late_alloc)
> {
> void *vaddr = phys_to_virt(start);
> unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> @@ -203,8 +203,7 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem
> *mem, phys_addr_t start,
> mem->index = 0;
> mem->late_alloc = late_alloc;
>
> - if (swiotlb_force_bounce)
> - mem->force_bounce = true;
> + mem->force_bounce = swiotlb_force_bounce || (flags & SWIOTLB_FORCE);
>
> spin_lock_init(&mem->lock);
> for (i = 0; i < mem->nslabs; i++) {
> @@ -275,8 +274,7 @@ void __init swiotlb_init_remap(bool addressing_limit,
> unsigned int flags,
> panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> __func__, alloc_size, PAGE_SIZE);
>
> - swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
> - mem->force_bounce = flags & SWIOTLB_FORCE;
> + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, flags, false);
>
> if (flags & SWIOTLB_VERBOSE)
> swiotlb_print_info();
> @@ -348,7 +346,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
>
> set_memory_decrypted((unsigned long)vstart,
>(nslabs << IO_TLB_SHIFT) >> PAGE_SHIFT);
> - swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, true);
> + swiotlb_init_io_tlb_mem(mem, virt_to_phys(vstart), nslabs, 0, true);
>
> swiotlb_print_info();
> return 0;
> @@ -835,8 +833,8 @@ static int rmem_swiotlb_device_init(struct reserved_mem
> *rmem,
>
> set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
>rmem->size >> PAGE_SHIFT);
> - swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
> - mem->force_bounce = true;
> + swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, SWIOTLB_FORCE,
> + false);
> mem->for_alloc = true;
>
> rmem->priv = mem;
>
Cheers,
Nathan
Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful
On Wed, Jun 01, 2022 at 07:57:43PM +0200, Christoph Hellwig wrote: > On Wed, Jun 01, 2022 at 10:46:54AM -0700, Nathan Chancellor wrote: > > On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > > > Can you send me the full dmesg and the content of > > > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot? > > > > Sure thing, they are attached! If there is anything else I can provide > > or test, I am more than happy to do so. > > Nothing interesting. But the performance numbers almost look like > swiotlb=force got ignored before (even if I can't explain why). I was able to get my performance back with this diff but I don't know if this is a hack or a proper fix in the context of the series. diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index dfa1de89dc94..0bfb2fe3d8c5 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -276,7 +276,7 @@ void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags, __func__, alloc_size, PAGE_SIZE); swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false); - mem->force_bounce = flags & SWIOTLB_FORCE; + mem->force_bounce = swiotlb_force_bounce || (flags & SWIOTLB_FORCE); if (flags & SWIOTLB_VERBOSE) swiotlb_print_info(); > Do you get a similar performance with the new kernel without > swiotlb=force as the old one with that argument by any chance? I'll see if I can test that, as I am not sure I have control over those cmdline arguments. Cheers, Nathan
Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful
On Wed, Jun 01, 2022 at 07:34:41PM +0200, Christoph Hellwig wrote: > Can you send me the full dmesg and the content of > /sys/kernel/debug/swiotlb/io_tlb_nslabs for a good and a bad boot? Sure thing, they are attached! If there is anything else I can provide or test, I am more than happy to do so. Cheers, Nathan # cat /sys/kernel/debug/swiotlb/io_tlb_nslabs 32768 # dmesg [0.00] Linux version 5.18.0-rc3-microsoft-standard-WSL2-8-ga3e230926708 (nathan@dev-arch.thelio-3990X) (gcc (GCC) 12.1.0, GNU ld (GNU Binutils) 2.38) #1 SMP PREEMPT_DYNAMIC Wed Jun 1 10:38:34 MST 2022 [0.00] Command line: initrd=\initrd.img panic=-1 nr_cpus=8 swiotlb=force earlycon=uart8250,io,0x3f8,115200 console=hvc0 debug pty.legacy_count=0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. [0.00] signal: max sigframe size: 1776 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x000e-0x000e0fff] reserved [0.00] BIOS-e820: [mem 0x0010-0x001f] ACPI data [0.00] BIOS-e820: [mem 0x0020-0xf7ff] usable [0.00] BIOS-e820: [mem 0x0001-0x000407ff] usable [0.00] earlycon: uart8250 at I/O port 0x3f8 (options '115200') [0.00] printk: bootconsole [uart8250] enabled [0.00] NX (Execute Disable) protection: active [0.00] DMI not present or invalid. [0.00] Hypervisor detected: Microsoft Hyper-V [0.00] Hyper-V: privilege flags low 0xae7f, high 0x3b8030, hints 0xc2c, misc 0xe0bed7b6 [0.00] Hyper-V: Host Build 10.0.22000.708-0-0 [0.00] Hyper-V: Nested features: 0x4a [0.00] Hyper-V: LAPIC Timer Frequency: 0x1e8480 [0.00] Hyper-V: Using hypercall for remote TLB flush [0.00] clocksource: hyperv_clocksource_tsc_page: mask: 0x max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns [0.05] tsc: Detected 3800.008 MHz processor [0.001901] e820: update [mem 0x-0x0fff] usable ==> reserved [0.004593] e820: remove [mem 0x000a-0x000f] usable [0.006806] last_pfn = 0x408000 max_arch_pfn = 0x4 [0.009042] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.011760] last_pfn = 0xf8000 max_arch_pfn = 0x4 [0.013959] Using GB pages for direct mapping [0.015749] RAMDISK: [mem 0x0371f000-0x03779fff] [0.017616] ACPI: Early table checksum verification disabled [0.019854] ACPI: RSDP 0x000E 24 (v02 VRTUAL) [0.022162] ACPI: XSDT 0x0010 44 (v01 VRTUAL MICROSFT 0001 MSFT 0001) [0.025624] ACPI: FACP 0x00101000 000114 (v06 VRTUAL MICROSFT 0001 MSFT 0001) [0.029022] ACPI: DSDT 0x001011B8 01E184 (v02 MSFTVM DSDT01 0001 MSFT 0500) [0.032413] ACPI: FACS 0x00101114 40 [0.034280] ACPI: OEM0 0x00101154 64 (v01 VRTUAL MICROSFT 0001 MSFT 0001) [0.037699] ACPI: SRAT 0x0011F33C 000330 (v02 VRTUAL MICROSFT 0001 MSFT 0001) [0.041089] ACPI: APIC 0x0011F66C 88 (v04 VRTUAL MICROSFT 0001 MSFT 0001) [0.044475] ACPI: Reserving FACP table memory at [mem 0x101000-0x101113] [0.047159] ACPI: Reserving DSDT table memory at [mem 0x1011b8-0x11f33b] [0.049905] ACPI: Reserving FACS table memory at [mem 0x101114-0x101153] [0.052693] ACPI: Reserving OEM0 table memory at [mem 0x101154-0x1011b7] [0.055404] ACPI: Reserving SRAT table memory at [mem 0x11f33c-0x11f66b] [0.058040] ACPI: Reserving APIC table memory at [mem 0x11f66c-0x11f6f3] [0.061078] Zone ranges: [0.062074] DMA [mem 0x1000-0x00ff] [0.066106] DMA32[mem 0x0100-0x] [0.068763] Normal [mem 0x0001-0x000407ff] [0.071235] Device empty [0.072384] Movable zone start for each node [0.074058] Early memory node ranges [0.075515] node 0: [mem 0x1000-0x0009] [0.077979] node 0: [mem 0x0020-0xf7ff] [0.080483] node 0: [mem 0x0001-0x000407ff] [0.082980] Initmem setup node 0 [mem 0x1000-0x000407ff] [0.085954] On node 0, zone DMA: 1 pages in unavailable ranges [0.085972] On node 0, zone DMA: 352 pages
Re: [PATCH 09/15] swiotlb: make the swiotlb_init interface more useful
Hi Christoph,
On Mon, Apr 04, 2022 at 07:05:53AM +0200, Christoph Hellwig wrote:
> Pass a bool to pass if swiotlb needs to be enabled based on the
> addressing needs and replace the verbose argument with a set of
> flags, including one to force enable bounce buffering.
>
> Note that this patch removes the possibility to force xen-swiotlb
> use using swiotlb=force on the command line on x86 (arm and arm64
> never supported that), but this interface will be restored shortly.
>
> Signed-off-by: Christoph Hellwig
I bisected a performance regression in WSL2 to this change as commit
c6af2aa9ffc9 ("swiotlb: make the swiotlb_init interface more useful") in
mainline (bisect log below). I initially noticed it because accessing the
Windows filesystem through the /mnt/c mount is about 40x slower if I am doing
my math right based on the benchmarks below.
Before:
$ uname -r; and hyperfine "ls -l /mnt/c/Users/natec/Downloads"
5.18.0-rc3-microsoft-standard-WSL2-8-ga3e230926708
Benchmark 1: ls -l /mnt/c/Users/natec/Downloads
Time (mean ± σ): 564.5 ms ± 24.1 ms[User: 2.5 ms, System: 130.3 ms]
Range (min … max): 510.2 ms … 588.0 ms10 runs
After
$ uname -r; and hyperfine "ls -l /mnt/c/Users/natec/Downloads"
5.18.0-rc3-microsoft-standard-WSL2-9-gc6af2aa9ffc9
Benchmark 1: ls -l /mnt/c/Users/natec/Downloads
Time (mean ± σ): 23.282 s ± 1.220 s[User: 0.013 s, System: 0.101 s]
Range (min … max): 21.793 s … 25.317 s10 runs
I do see 'swiotlb=force' on the cmdline:
$ cat /proc/cmdline
initrd=\initrd.img panic=-1 nr_cpus=8 swiotlb=force
earlycon=uart8250,io,0x3f8,115200 console=hvc0 debug pty.legacy_count=0
/mnt/c appears to be a 9p mount, not sure if that is relevant here:
$ mount &| grep /mnt/c
drvfs on /mnt/c type 9p
(rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=262144,trans=virtio)
If there is any other information I can provide, please let me know.
Cheers,
Nathan
# bad: [700170bf6b4d773e328fa54ebb70ba444007c702] Merge tag 'nfs-for-5.19-1' of
git://git.linux-nfs.org/projects/anna/linux-nfs
# good: [4b0986a3613c92f4ec1bdc7f60ec66fea135991f] Linux 5.18
git bisect start '700170bf6b4d773e328fa54ebb70ba444007c702' 'v5.18'
# good: [86c87bea6b42100c67418af690919c44de6ede6e] Merge tag
'devicetree-for-5.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
git bisect good 86c87bea6b42100c67418af690919c44de6ede6e
# bad: [ae862183285cbb2ef9032770d98ffa9becffe9d5] Merge tag 'arm-dt-5.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad ae862183285cbb2ef9032770d98ffa9becffe9d5
# good: [2518f226c60d8e04d18ba4295500a5b0b8ac7659] Merge tag
'drm-next-2022-05-25' of git://anongit.freedesktop.org/drm/drm
git bisect good 2518f226c60d8e04d18ba4295500a5b0b8ac7659
# bad: [babf0bb978e3c9fce6c4eba6b744c8754fd43d8e] Merge tag
'xfs-5.19-for-linus' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad babf0bb978e3c9fce6c4eba6b744c8754fd43d8e
# good: [beed983621fbdfd291e6e3a0cdc4d10517e60af8] ASoC: Intel: avs: Machine
board registration
git bisect good beed983621fbdfd291e6e3a0cdc4d10517e60af8
# good: [fbe86daca0ba878b04fa241b85e26e54d17d4229] Merge tag 'scsi-misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good fbe86daca0ba878b04fa241b85e26e54d17d4229
# good: [166afc45ed5523298541fd0297f9ad585cc2708c] Merge tag
'reflink-speedups-5.19_2022-04-28' of
git://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux into
xfs-5.19-for-next
git bisect good 166afc45ed5523298541fd0297f9ad585cc2708c
# bad: [e375780b631a5fc2a61a3b4fa12429255361a31e] Merge tag
'fsnotify_for_v5.19-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect bad e375780b631a5fc2a61a3b4fa12429255361a31e
# bad: [4a37f3dd9a83186cb88d44808ab35b78375082c9] dma-direct: don't
over-decrypt memory
git bisect bad 4a37f3dd9a83186cb88d44808ab35b78375082c9
# bad: [742519538e6b07250c8085bbff4bd358bc03bf16] swiotlb: pass a gfp_mask
argument to swiotlb_init_late
git bisect bad 742519538e6b07250c8085bbff4bd358bc03bf16
# good: [9bbe7a7fc126e3d14fefa4b035854aba080926d9] arm/xen: don't check for
xen_initial_domain() in xen_create_contiguous_region
git bisect good 9bbe7a7fc126e3d14fefa4b035854aba080926d9
# good: [a3e230926708125205ffd06d3dc2175a8263ae7e] x86: centralize setting
SWIOTLB_FORCE when guest memory encryption is enabled
git bisect good a3e230926708125205ffd06d3dc2175a8263ae7e
# bad: [8ba2ed1be90fc210126f68186564707478552c95] swiotlb: add a SWIOTLB_ANY
flag to lift the low memory restriction
git bisect bad 8ba2ed1be90fc210126f68186564707478552c95
# bad: [c6af2aa9ffc9763826607bc2664ef3ea4475ed18] swiotlb: make the
swiotlb_init interface more useful
git bisect bad c6af2aa9ffc9763826607bc2664ef3ea4475ed18
# first bad commit: [c6af2aa9ffc9763826607bc2664ef3ea4475ed18] swiotlb: make
the swiotlb_init interface more useful
