[PATCH linux-next] powerpc: disable sanitizer in irq_soft_mask_set
In ppc, compiler based sanitizer will generate instrument instructions
around statement WRITE_ONCE(local_paca->irq_soft_mask, mask):
0xc0295cb0 <+0>: addis r2,r12,774
0xc0295cb4 <+4>: addir2,r2,16464
0xc0295cb8 <+8>: mflrr0
0xc0295cbc <+12>:bl 0xc008bb4c
0xc0295cc0 <+16>:mflrr0
0xc0295cc4 <+20>:std r31,-8(r1)
0xc0295cc8 <+24>:addir3,r13,2354
0xc0295ccc <+28>:mr r31,r13
0xc0295cd0 <+32>:std r0,16(r1)
0xc0295cd4 <+36>:stdur1,-48(r1)
0xc0295cd8 <+40>:bl 0xc0609b98 <__asan_store1+8>
0xc0295cdc <+44>:nop
0xc0295ce0 <+48>:li r9,1
0xc0295ce4 <+52>:stb r9,2354(r31)
0xc0295ce8 <+56>:addir1,r1,48
0xc0295cec <+60>:ld r0,16(r1)
0xc0295cf0 <+64>:ld r31,-8(r1)
0xc0295cf4 <+68>:mtlrr0
If there is a context switch before "stb r9,2354(r31)", r31 may
not equal to r13, in such case, irq soft mask will not work.
This patch disable sanitizer in irq_soft_mask_set.
Signed-off-by: Zhouyi Zhou
---
Dear PPC developers
I found this bug when trying to do rcutorture tests in ppc VM of
Open Source Lab of Oregon State University following Paul E. McKenny's guidance.
console.log report following bug:
[ 346.527467][ T100] BUG: using smp_processor_id() in preemptible []
code: rcu_torture_rea/100^M
[ 346.529416][ T100] caller is rcu_preempt_deferred_qs_irqrestore+0x74/0xed0^M
[ 346.531157][ T100] CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: G
W 5.19.0-rc5-next-20220708-dirty #253^M
[ 346.533620][ T100] Call Trace:^M
[ 346.534449][ T100] [c94876c0] [c0ce2b68]
dump_stack_lvl+0xbc/0x108 (unreliable)^M
[ 346.536632][ T100] [c9487710] [c1712954]
check_preemption_disabled+0x154/0x160^M
[ 346.538665][ T100] [c94877a0] [c02ce2d4]
rcu_preempt_deferred_qs_irqrestore+0x74/0xed0^M
[ 346.540830][ T100] [c94878b0] [c02cf3c0]
__rcu_read_unlock+0x290/0x3b0^M
[ 346.542746][ T100] [c9487910] [c02bb330]
rcu_torture_read_unlock+0x30/0xb0^M
[ 346.544779][ T100] [c9487930] [c02b7ff8]
rcutorture_one_extend+0x198/0x810^M
[ 346.546851][ T100] [c9487a10] [c02b8bfc]
rcu_torture_one_read+0x58c/0xc90^M
[ 346.548844][ T100] [c9487ca0] [c02b942c]
rcu_torture_reader+0x12c/0x360^M
[ 346.550784][ T100] [c9487db0] [c01de978]
kthread+0x1e8/0x220^M
[ 346.552555][ T100] [c9487e10] [c000cd54]
ret_from_kernel_thread+0x5c/0x64^M
After 12 days debugging, I finally narrow the problem to irq_soft_mask_set.
I am a beginner, hope I can be of some beneficial to the community ;-)
Thanks
Zhouyi
--
arch/powerpc/include/asm/hw_irq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h
b/arch/powerpc/include/asm/hw_irq.h
index 26ede09c521d..a5ae8d82cc9d 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -121,7 +121,7 @@ static inline notrace unsigned long
irq_soft_mask_return(void)
* for the critical section and as a clobber because
* we changed paca->irq_soft_mask
*/
-static inline notrace void irq_soft_mask_set(unsigned long mask)
+static inline notrace __no_kcsan __no_sanitize_address void
irq_soft_mask_set(unsigned long mask)
{
/*
* The irq mask must always include the STD bit if any are set.
--
2.34.1
[PATCH] i2c: pasemi: Add IRQ support for Apple Silicon
This is the first time I'm interacting with the Linux mailing lists, so
please don't eviscerate me *too much* if I get the formatting wrong.
Of course I'm always willing to take criticism and improve my formatting
in the future.
This patch adds support for IRQs to the PASemi I2C controller driver.
This will allow for faster performing I2C transactions on Apple Silicon
hardware, as previously, the driver was forced to poll the SMSTA register
for a set amount of time.
With this patchset the driver on Apple silicon hardware will instead wait
for an interrupt which will signal the completion of the I2C transaction.
The timeout value for this completion will be the same as the current
amount of time the I2C driver polls for.
This will result in some performance improvement since the driver will be
waiting for less time than it does right now on Apple Silicon hardware.
The patch right now will only enable IRQs for Apple Silicon I2C chips,
and only if it's able to successfully request the IRQ from the kernel.
=== Testing ===
This patch has been tested on both the mainline Linux kernel tree and
the Asahi branch (https://github.com/AsahiLinux/linux.git) on both an
M1 and M2 MacBook Air, and it compiles successfully as both a module and
built-in to the kernel itself. The patch in both trees successfully boots
to userspace without any hitch.
I do not have PASemi hardware on hand unfortunately, so I'm unable to test
the impact of this patch on old PASemi hardware. This is also why I've
elected to do the IRQ request and enablement on the Apple platform driver
and not in the common file, as I'm not sure if PASemi hardware supports
IRQs.
I also fixed a quick checkpatch warning on line 303. "i ++" is now "i++".
Any and all critiques of the patch would be well appreciated.
Signed-off-by: Arminder Singh
---
drivers/i2c/busses/i2c-pasemi-core.c | 29
drivers/i2c/busses/i2c-pasemi-core.h | 5
drivers/i2c/busses/i2c-pasemi-platform.c | 8 +++
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pasemi-core.c
b/drivers/i2c/busses/i2c-pasemi-core.c
index 9028ffb58cc0..375aa9528233 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.c
+++ b/drivers/i2c/busses/i2c-pasemi-core.c
@@ -21,6 +21,7 @@
#define REG_MTXFIFO0x00
#define REG_MRXFIFO0x04
#define REG_SMSTA 0x14
+#define REG_IMASK 0x18
#define REG_CTL0x1c
#define REG_REV0x28
@@ -80,14 +81,21 @@ static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
{
int timeout = 10;
unsigned int status;
+ unsigned int bitmask = SMSTA_XEN | SMSTA_MTN;
- status = reg_read(smbus, REG_SMSTA);
-
- while (!(status & SMSTA_XEN) && timeout--) {
- msleep(1);
+ if (smbus->use_irq) {
+ reinit_completion(>irq_completion);
+ reg_write(smbus, REG_IMASK, bitmask);
+ wait_for_completion_timeout(>irq_completion,
msecs_to_jiffies(10));
status = reg_read(smbus, REG_SMSTA);
+ } else {
+ while (!(status & SMSTA_XEN) && timeout--) {
+ msleep(1);
+ status = reg_read(smbus, REG_SMSTA);
+ }
}
+
/* Got NACK? */
if (status & SMSTA_MTN)
return -ENXIO;
@@ -300,7 +308,7 @@ static int pasemi_smb_xfer(struct i2c_adapter *adapter,
case I2C_SMBUS_BLOCK_DATA:
case I2C_SMBUS_BLOCK_PROC_CALL:
data->block[0] = len;
- for (i = 1; i <= len; i ++) {
+ for (i = 1; i <= len; i++) {
rd = RXFIFO_RD(smbus);
if (rd & MRXFIFO_EMPTY) {
err = -ENODATA;
@@ -348,6 +356,8 @@ int pasemi_i2c_common_probe(struct pasemi_smbus *smbus)
if (smbus->hw_rev != PASEMI_HW_REV_PCI)
smbus->hw_rev = reg_read(smbus, REG_REV);
+ reg_write(smbus, REG_IMASK, 0);
+
pasemi_reset(smbus);
error = devm_i2c_add_adapter(smbus->dev, >adapter);
@@ -356,3 +366,12 @@ int pasemi_i2c_common_probe(struct pasemi_smbus *smbus)
return 0;
}
+
+irqreturn_t pasemi_irq_handler(int irq, void *dev_id)
+{
+ struct pasemi_smbus *smbus = (struct pasemi_smbus *)dev_id;
+
+ reg_write(smbus, REG_IMASK, 0);
+ complete(>irq_completion);
+ return IRQ_HANDLED;
+}
diff --git a/drivers/i2c/busses/i2c-pasemi-core.h
b/drivers/i2c/busses/i2c-pasemi-core.h
index 4655124a37f3..045e4a9a3d13 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.h
+++ b/drivers/i2c/busses/i2c-pasemi-core.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#define PASEMI_HW_REV_PCI -1
@@ -16,6 +17,10 @@ struct pasemi_smbus {
void __iomem*ioaddr;
unsigned int clk_div;
int hw_rev;
+ int use_irq;
+ struct completion
RE: [PATCH] kernel: exit: cleanup release_thread()
> -Original Message- > From: Kefeng Wang ... > Only x86 has own release_thread(), introduce a new weak > release_thread() function to clean empty definitions in > other ARCHs. > > Signed-off-by: Kefeng Wang > --- Acked-by: Brian Cain
Re: [PATCH] i2c: pasemi: Add IRQ support for Apple Silicon
Hi Arminder, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on powerpc/next] [also build test WARNING on linus/master v6.0-rc1 next-20220819] [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/Arminder-Singh/i2c-pasemi-Add-IRQ-support-for-Apple-Silicon/20220821-034703 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: riscv-randconfig-r042-20220821 (https://download.01.org/0day-ci/archive/20220821/202208210548.mcoiwyql-...@intel.com/config) compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project c9a41fe60ab62f7a40049c100adcc8087a47669b) 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 # install riscv cross compiling tool for clang build # apt-get install binutils-riscv64-linux-gnu # https://github.com/intel-lab-lkp/linux/commit/98584b2b51d808ab582798c7a50511e8c1889ced git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Arminder-Singh/i2c-pasemi-Add-IRQ-support-for-Apple-Silicon/20220821-034703 git checkout 98584b2b51d808ab582798c7a50511e8c1889ced # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/i2c/busses/ If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from drivers/i2c/busses/i2c-pasemi-core.c:9: In file included from include/linux/pci.h:38: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:11: In file included from ./arch/riscv/include/generated/asm/hardirq.h:1: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __raw_readb(PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu' #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) ^ In file included from drivers/i2c/busses/i2c-pasemi-core.c:9: In file included from include/linux/pci.h:38: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:11: In file included from ./arch/riscv/include/generated/asm/hardirq.h:1: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) ^ In file included from drivers/i2c/busses/i2c-pasemi-core.c:9: In file included from include/linux/pci.h:38: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:11: In file included from ./arch/riscv/include/generated/asm/hardirq.h:1: In file included from include/asm-generic/hardirq.h:17: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/riscv/include/asm/io.h:136: include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] __raw_writeb(value, PCI_IOBASE + addr); ~~ ^ include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.0-3 tag
The pull request you sent on Sat, 20 Aug 2022 15:03:18 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.0-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/32dd68f11058652a37152aed12bf552455914b40 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
Le 20/08/2022 à 19:01, Masahiro Yamada a écrit :
> On Sat, Aug 20, 2022 at 11:15 PM Christophe Leroy
> wrote:
>>
>>
>>
>> Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
>>> On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
>>> wrote:
Hi,
Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> as a placeholder.
>
> Genksyms writes the version CRCs into the linker script, which will be
> used for filling the __crc_* symbols. The linker script format depends
> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> to the reference of CRC.
>
> It is time to get rid of this complexity.
>
> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> it can generate C code that will be linked to the vmlinux or modules.
>
> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> symbols exported by vmlinux. It is compiled and linked to vmlinux in
> scripts/link-vmlinux.sh.
>
> Put the CRCs of symbols exported by modules into the existing *.mod.c
> files. No additional build step is needed for modules. As before,
> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>
> No linker magic is used here. The new C implementation works in the
> same way, whether CONFIG_RELOCATABLE is enabled or not.
> CONFIG_MODULE_REL_CRCS is no longer needed.
>
> Previously, Kbuild invoked additional $(LD) to update the CRCs in
> objects, but this step is unneeded too.
>
> Signed-off-by: Masahiro Yamada
> Tested-by: Nathan Chancellor
> Tested-by: Nicolas Schier
> Reviewed-by: Nicolas Schier
Problem with v6.0-rc1
Problem with v5.19
No problem with v5.18
Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
removing CONFIG_MODULE_REL_CRCS")
The above patch leads to the following problem building
mpc85xx_defconfig + CONFIG_RELOCATABLE
>>>
>>>
>>>
>>> Is this because the relocation implementation on ppc is incomplete?
>>> (and is it the reason why relock_check.sh exists?)
>>>
>>> arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
>>>
>>>
>>
>> Might be the reason.
>>
>> Is it expected that your patch adds an unsupported relocation ?
>>
>> Why was that relocation type unneeded before ?
>>
>> Thanks
>> Christophe
>
>
> I posted a patch (although I believe my commit is innocent).
>
> https://lore.kernel.org/lkml/20220820165129.1147589-1-masahi...@kernel.org/T/#u
>
> The relocs_check.sh warnings are gone.
> Please do a boot test.
> Thanks.
>
Yes it works, many Thanks.
The fixes tag should probably be c857c43b34ec ("powerpc: Don't use a
function descriptor for system call table")
Christophe
Re: [PATCH] powerpc: align syscall table for ppc32
Le 20/08/2022 à 18:51, Masahiro Yamada a écrit :
> Christophe Leroy reported that commit 7b4537199a4a ("kbuild: link
> symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") broke
> mpc85xx_defconfig + CONFIG_RELOCATABLE=y.
>
> LD vmlinux
> SYSMAP System.map
> SORTTAB vmlinux
> CHKREL vmlinux
>WARNING: 451 bad relocations
>c0b312a9 R_PPC_UADDR32 .head.text-0x3ff9ed54
>c0b312ad R_PPC_UADDR32 .head.text-0x3ffac224
>c0b312b1 R_PPC_UADDR32 .head.text-0x3ffb09f4
>c0b312b5 R_PPC_UADDR32 .head.text-0x3fe184dc
>c0b312b9 R_PPC_UADDR32 .head.text-0x3fe183a8
>...
>
> The compiler emits a bunch of R_PPC_UADDR32, which is not supported by
> arch/powerpc/kernel/reloc_32.S.
>
> The reason is there exists an unaligned symbol.
>
>$ powerpc-linux-gnu-nm -n vmlinux
> ...
>c0b31258 d spe_aligninfo
>c0b31298 d __func__.0
>c0b312a9 D sys_call_table
>c0b319b8 d __func__.0
>
> Commit 7b4537199a4a is not the root cause. Even before that, I can
> reproduce the same issue for mpc85xx_defconfig + CONFIG_RELOCATABLE=y
> + CONFIG_MODVERSIONS=n.
>
> It is just that nobody did not notice it because when CONFIG_MODVERSIONS
> is enabled, a __crc_* symbol inserted before sys_call_table was hiding
> the unalignment issue.
>
> I checked the commit history, but I could not understand commit
> 46b45b10f142 ("[POWERPC] Align the sys_call_table").
>
> It said 'Our _GLOBAL macro does a ".align 2" so the alignment is fine
> for 32 bit'. I checked the _GLOBAL in include/asm-powerpc/ppc_asm.h
> at that time. _GLOBAL specifies ".align 2" for ppc64, but no .align
> for ppc32.
>
> Commit c857c43b34ec ("powerpc: Don't use a function descriptor for
> system call table") removed _GLOBAL from the syscall table.
>
> Anyway, adding alignment to the syscall table for ppc32 fixes the issue.
>
> I am not giving Fixes tag because I do not know since when it has been
> broken, but presumably it has been for a long while.
>
> Link:
> https://lore.kernel.org/lkml/38605f6a-a568-f884-f06f-ea4da5b21...@csgroup.eu/
> Reported-by: Christophe Leroy
> Signed-off-by: Masahiro Yamada
Tested-by: Christophe Leroy
> ---
>
> arch/powerpc/kernel/systbl.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
> index cb3358886203..6c1db3b6de2d 100644
> --- a/arch/powerpc/kernel/systbl.S
> +++ b/arch/powerpc/kernel/systbl.S
> @@ -18,6 +18,7 @@
> .p2align3
> #define __SYSCALL(nr, entry).8byte entry
> #else
> + .p2align2
> #define __SYSCALL(nr, entry).long entry
> #endif
>
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
On Sat, Aug 20, 2022 at 11:15 PM Christophe Leroy
wrote:
>
>
>
> Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
> > On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
> > wrote:
> >>
> >> Hi,
> >>
> >> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> >>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> >>> as a placeholder.
> >>>
> >>> Genksyms writes the version CRCs into the linker script, which will be
> >>> used for filling the __crc_* symbols. The linker script format depends
> >>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> >>> to the reference of CRC.
> >>>
> >>> It is time to get rid of this complexity.
> >>>
> >>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> >>> it can generate C code that will be linked to the vmlinux or modules.
> >>>
> >>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> >>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
> >>> scripts/link-vmlinux.sh.
> >>>
> >>> Put the CRCs of symbols exported by modules into the existing *.mod.c
> >>> files. No additional build step is needed for modules. As before,
> >>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >>>
> >>> No linker magic is used here. The new C implementation works in the
> >>> same way, whether CONFIG_RELOCATABLE is enabled or not.
> >>> CONFIG_MODULE_REL_CRCS is no longer needed.
> >>>
> >>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
> >>> objects, but this step is unneeded too.
> >>>
> >>> Signed-off-by: Masahiro Yamada
> >>> Tested-by: Nathan Chancellor
> >>> Tested-by: Nicolas Schier
> >>> Reviewed-by: Nicolas Schier
> >>
> >> Problem with v6.0-rc1
> >> Problem with v5.19
> >> No problem with v5.18
> >>
> >> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> >> removing CONFIG_MODULE_REL_CRCS")
> >>
> >> The above patch leads to the following problem building
> >> mpc85xx_defconfig + CONFIG_RELOCATABLE
> >
> >
> >
> > Is this because the relocation implementation on ppc is incomplete?
> > (and is it the reason why relock_check.sh exists?)
> >
> > arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
> >
> >
>
> Might be the reason.
>
> Is it expected that your patch adds an unsupported relocation ?
>
> Why was that relocation type unneeded before ?
>
> Thanks
> Christophe
I posted a patch (although I believe my commit is innocent).
https://lore.kernel.org/lkml/20220820165129.1147589-1-masahi...@kernel.org/T/#u
The relocs_check.sh warnings are gone.
Please do a boot test.
Thanks.
--
Best Regards
Masahiro Yamada
[PATCH] powerpc: align syscall table for ppc32
Christophe Leroy reported that commit 7b4537199a4a ("kbuild: link
symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") broke
mpc85xx_defconfig + CONFIG_RELOCATABLE=y.
LD vmlinux
SYSMAP System.map
SORTTAB vmlinux
CHKREL vmlinux
WARNING: 451 bad relocations
c0b312a9 R_PPC_UADDR32 .head.text-0x3ff9ed54
c0b312ad R_PPC_UADDR32 .head.text-0x3ffac224
c0b312b1 R_PPC_UADDR32 .head.text-0x3ffb09f4
c0b312b5 R_PPC_UADDR32 .head.text-0x3fe184dc
c0b312b9 R_PPC_UADDR32 .head.text-0x3fe183a8
...
The compiler emits a bunch of R_PPC_UADDR32, which is not supported by
arch/powerpc/kernel/reloc_32.S.
The reason is there exists an unaligned symbol.
$ powerpc-linux-gnu-nm -n vmlinux
...
c0b31258 d spe_aligninfo
c0b31298 d __func__.0
c0b312a9 D sys_call_table
c0b319b8 d __func__.0
Commit 7b4537199a4a is not the root cause. Even before that, I can
reproduce the same issue for mpc85xx_defconfig + CONFIG_RELOCATABLE=y
+ CONFIG_MODVERSIONS=n.
It is just that nobody did not notice it because when CONFIG_MODVERSIONS
is enabled, a __crc_* symbol inserted before sys_call_table was hiding
the unalignment issue.
I checked the commit history, but I could not understand commit
46b45b10f142 ("[POWERPC] Align the sys_call_table").
It said 'Our _GLOBAL macro does a ".align 2" so the alignment is fine
for 32 bit'. I checked the _GLOBAL in include/asm-powerpc/ppc_asm.h
at that time. _GLOBAL specifies ".align 2" for ppc64, but no .align
for ppc32.
Commit c857c43b34ec ("powerpc: Don't use a function descriptor for
system call table") removed _GLOBAL from the syscall table.
Anyway, adding alignment to the syscall table for ppc32 fixes the issue.
I am not giving Fixes tag because I do not know since when it has been
broken, but presumably it has been for a long while.
Link:
https://lore.kernel.org/lkml/38605f6a-a568-f884-f06f-ea4da5b21...@csgroup.eu/
Reported-by: Christophe Leroy
Signed-off-by: Masahiro Yamada
---
arch/powerpc/kernel/systbl.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index cb3358886203..6c1db3b6de2d 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -18,6 +18,7 @@
.p2align3
#define __SYSCALL(nr, entry) .8byte entry
#else
+ .p2align2
#define __SYSCALL(nr, entry) .long entry
#endif
--
2.34.1
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
Le 20/08/2022 à 14:51, Masahiro Yamada a écrit :
> On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
> wrote:
>>
>> Hi,
>>
>> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
>>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
>>> as a placeholder.
>>>
>>> Genksyms writes the version CRCs into the linker script, which will be
>>> used for filling the __crc_* symbols. The linker script format depends
>>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
>>> to the reference of CRC.
>>>
>>> It is time to get rid of this complexity.
>>>
>>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
>>> it can generate C code that will be linked to the vmlinux or modules.
>>>
>>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
>>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
>>> scripts/link-vmlinux.sh.
>>>
>>> Put the CRCs of symbols exported by modules into the existing *.mod.c
>>> files. No additional build step is needed for modules. As before,
>>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>>>
>>> No linker magic is used here. The new C implementation works in the
>>> same way, whether CONFIG_RELOCATABLE is enabled or not.
>>> CONFIG_MODULE_REL_CRCS is no longer needed.
>>>
>>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
>>> objects, but this step is unneeded too.
>>>
>>> Signed-off-by: Masahiro Yamada
>>> Tested-by: Nathan Chancellor
>>> Tested-by: Nicolas Schier
>>> Reviewed-by: Nicolas Schier
>>
>> Problem with v6.0-rc1
>> Problem with v5.19
>> No problem with v5.18
>>
>> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>> removing CONFIG_MODULE_REL_CRCS")
>>
>> The above patch leads to the following problem building
>> mpc85xx_defconfig + CONFIG_RELOCATABLE
>
>
>
> Is this because the relocation implementation on ppc is incomplete?
> (and is it the reason why relock_check.sh exists?)
>
> arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
>
>
Might be the reason.
Is it expected that your patch adds an unsupported relocation ?
Why was that relocation type unneeded before ?
Thanks
Christophe
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
Le 20/08/2022 à 14:05, Sedat Dilek a écrit :
> On Sat, Aug 20, 2022 at 12:04 PM Christophe Leroy
> wrote:
>>
>> Hi,
>>
>> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
>>> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
>>> as a placeholder.
>>>
>>> Genksyms writes the version CRCs into the linker script, which will be
>>> used for filling the __crc_* symbols. The linker script format depends
>>> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
>>> to the reference of CRC.
>>>
>>> It is time to get rid of this complexity.
>>>
>>> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
>>> it can generate C code that will be linked to the vmlinux or modules.
>>>
>>> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
>>> symbols exported by vmlinux. It is compiled and linked to vmlinux in
>>> scripts/link-vmlinux.sh.
>>>
>>> Put the CRCs of symbols exported by modules into the existing *.mod.c
>>> files. No additional build step is needed for modules. As before,
>>> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>>>
>>> No linker magic is used here. The new C implementation works in the
>>> same way, whether CONFIG_RELOCATABLE is enabled or not.
>>> CONFIG_MODULE_REL_CRCS is no longer needed.
>>>
>>> Previously, Kbuild invoked additional $(LD) to update the CRCs in
>>> objects, but this step is unneeded too.
>>>
>>> Signed-off-by: Masahiro Yamada
>>> Tested-by: Nathan Chancellor
>>> Tested-by: Nicolas Schier
>>> Reviewed-by: Nicolas Schier
>>
>> Problem with v6.0-rc1
>> Problem with v5.19
>> No problem with v5.18
>>
>> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
>> removing CONFIG_MODULE_REL_CRCS")
>>
>
> What you are looking for is...
>
> commit 7d13fd96df875a9d786ee6dcc8fec460d35d4b12
> ("modpost: fix module versioning when a symbol lacks valid CRC")
>
> It's pending in kbuild.git#fixes.
>
> -Sedat-
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes=7d13fd96df875a9d786ee6dcc8fec460d35d4b12
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=fixes
>
That patch doesn't fix the problem.
Christophe
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
On Sat, Aug 20, 2022 at 7:02 PM Christophe Leroy
wrote:
>
> Hi,
>
> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> > include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> > as a placeholder.
> >
> > Genksyms writes the version CRCs into the linker script, which will be
> > used for filling the __crc_* symbols. The linker script format depends
> > on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> > to the reference of CRC.
> >
> > It is time to get rid of this complexity.
> >
> > Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> > it can generate C code that will be linked to the vmlinux or modules.
> >
> > Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> > symbols exported by vmlinux. It is compiled and linked to vmlinux in
> > scripts/link-vmlinux.sh.
> >
> > Put the CRCs of symbols exported by modules into the existing *.mod.c
> > files. No additional build step is needed for modules. As before,
> > *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >
> > No linker magic is used here. The new C implementation works in the
> > same way, whether CONFIG_RELOCATABLE is enabled or not.
> > CONFIG_MODULE_REL_CRCS is no longer needed.
> >
> > Previously, Kbuild invoked additional $(LD) to update the CRCs in
> > objects, but this step is unneeded too.
> >
> > Signed-off-by: Masahiro Yamada
> > Tested-by: Nathan Chancellor
> > Tested-by: Nicolas Schier
> > Reviewed-by: Nicolas Schier
>
> Problem with v6.0-rc1
> Problem with v5.19
> No problem with v5.18
>
> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> removing CONFIG_MODULE_REL_CRCS")
>
> The above patch leads to the following problem building
> mpc85xx_defconfig + CONFIG_RELOCATABLE
Is this because the relocation implementation on ppc is incomplete?
(and is it the reason why relock_check.sh exists?)
arch/powerpc/kernel/reloc_32.S does not support R_PPC_UADDR32
--
Best Regards
Masahiro Yamada
[powerpc:next-test] BUILD SUCCESS bbee0d0affda40bb0917813cf416ac6ccbe1d5fa
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: bbee0d0affda40bb0917813cf416ac6ccbe1d5fa powerpc/vdso: Don't map VDSO at a fixed address on PPC32 elapsed time: 1479m configs tested: 171 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: um x86_64_defconfig um i386_defconfig i386 allyesconfig i386defconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 x86_64 rhel-8.3-kvm x86_64 rhel-8.3-func x86_64 rhel-8.3-syz x86_64rhel-8.3-kselftests x86_64 rhel-8.3-kunit csky allnoconfig alpha allnoconfig arc allnoconfig riscv allnoconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 mipsmaltaup_xpa_defconfig openrisc or1klitex_defconfig arm at91_dt_defconfig powerpc tqm8xx_defconfig openriscdefconfig sh lboxre2_defconfig arm64allyesconfig arm defconfig arm allyesconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 riscv nommu_k210_sdcard_defconfig i386 randconfig-c001 loongarch defconfig loongarch allnoconfig riscvrandconfig-r042-20220820 s390 randconfig-r044-20220820 arc randconfig-r043-20220820 i386 debian-10.3-kvm i386debian-10.3-kunit i386 debian-10.3-func powerpcamigaone_defconfig arm lpc18xx_defconfig arm iop32x_defconfig armmini2440_defconfig microblaze defconfig powerpc linkstation_defconfig arm ezx_defconfig ia64defconfig riscvnommu_virt_defconfig riscv rv32_defconfig riscvnommu_k210_defconfig i386 debian-10.3-kselftests i386 debian-10.3 arm u8500_defconfig ia64generic_defconfig powerpc storcenter_defconfig arcvdk_hs38_smp_defconfig powerpc mpc834x_itx_defconfig m68kdefconfig powerpc asp8347_defconfig mips allmodconfig powerpc wii_defconfig powerpc ep8248e_defconfig mips db1xxx_defconfig s390 debug_defconfig powerpc rainier_defconfig cskydefconfig loongarch loongson3_defconfig openrisc simple_smp_defconfig s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig m68k alldefconfig sh se7722_defconfig armspear6xx_defconfig shhp6xx_defconfig sh sh7710voipgw_defconfig xtensageneric_kc705_defconfig um defconfig arm simpad_defconfig powerpc iss476-smp_defconfig s390 zfcpdump_defconfig mips jazz_defconfig m68kmac_defconfig powerpc stx_gp3_defconfig m68k amiga_defconfig arm
[powerpc:merge] BUILD SUCCESS 171ad2c21268b329c0a92707f7642f588ab77926
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 171ad2c21268b329c0a92707f7642f588ab77926 Automatic merge of 'fixes' into merge (2022-08-19 21:17) elapsed time: 1478m configs tested: 52 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: powerpc allmodconfig mips allyesconfig um x86_64_defconfig um i386_defconfig powerpc allnoconfig sh allmodconfig m68k allmodconfig alphaallyesconfig arc allyesconfig m68k allyesconfig x86_64randconfig-a002 i386defconfig x86_64randconfig-a006 x86_64randconfig-a004 i386 allyesconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 riscvrandconfig-r042-20220820 s390 randconfig-r044-20220820 arc randconfig-r043-20220820 x86_64randconfig-a013 x86_64randconfig-a011 x86_64randconfig-a015 i386 randconfig-a014 i386 randconfig-a001 i386 randconfig-a012 i386 randconfig-a003 i386 randconfig-a016 arm defconfig i386 randconfig-a005 arm64allyesconfig arm allyesconfig ia64 allmodconfig csky allnoconfig alpha allnoconfig arc allnoconfig riscv allnoconfig clang tested configs: x86_64randconfig-a005 x86_64randconfig-a001 x86_64randconfig-a003 i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 i386 randconfig-a011 i386 randconfig-a013 i386 randconfig-a015 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 hexagon randconfig-r041-20220820 hexagon randconfig-r045-20220820 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[PATCH] powerpc/fsl-pci: Choose PCI host bridge with alias pci0 as the primary
If there's no PCI host bridge with ISA then check for PCI host bridge with
alias "pci0" (first PCI host bridge) and if it exists then choose it as the
primary PCI host bridge.
This makes choice of primary PCI host bridge more stable across boots and
updates as the last fallback candidate for primary PCI host bridge (if
there is no choice) is selected arbitrary.
Signed-off-by: Pali Rohár
---
arch/powerpc/sysdev/fsl_pci.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 1011cfea2e32..e4b703943dd3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1125,6 +1125,19 @@ void __init fsl_pci_assign_primary(void)
return;
}
+ /*
+* If there's no PCI host bridge with ISA then check for
+* PCI host bridge with alias "pci0" (first PCI host bridge).
+*/
+ np = of_find_node_by_path("pci0");
+ if (np && of_match_node(pci_ids, np) && of_device_is_available(np)) {
+ fsl_pci_primary = np;
+ of_node_put(np);
+ return;
+ }
+ if (np)
+ of_node_put(np);
+
/*
* If there's no PCI host bridge with ISA, arbitrarily
* designate one as primary. This can go away once
--
2.20.1
Re: Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
On Sat, Aug 20, 2022 at 12:04 PM Christophe Leroy
wrote:
>
> Hi,
>
> Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> > include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> > as a placeholder.
> >
> > Genksyms writes the version CRCs into the linker script, which will be
> > used for filling the __crc_* symbols. The linker script format depends
> > on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> > to the reference of CRC.
> >
> > It is time to get rid of this complexity.
> >
> > Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> > it can generate C code that will be linked to the vmlinux or modules.
> >
> > Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> > symbols exported by vmlinux. It is compiled and linked to vmlinux in
> > scripts/link-vmlinux.sh.
> >
> > Put the CRCs of symbols exported by modules into the existing *.mod.c
> > files. No additional build step is needed for modules. As before,
> > *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
> >
> > No linker magic is used here. The new C implementation works in the
> > same way, whether CONFIG_RELOCATABLE is enabled or not.
> > CONFIG_MODULE_REL_CRCS is no longer needed.
> >
> > Previously, Kbuild invoked additional $(LD) to update the CRCs in
> > objects, but this step is unneeded too.
> >
> > Signed-off-by: Masahiro Yamada
> > Tested-by: Nathan Chancellor
> > Tested-by: Nicolas Schier
> > Reviewed-by: Nicolas Schier
>
> Problem with v6.0-rc1
> Problem with v5.19
> No problem with v5.18
>
> Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
> removing CONFIG_MODULE_REL_CRCS")
>
What you are looking for is...
commit 7d13fd96df875a9d786ee6dcc8fec460d35d4b12
("modpost: fix module versioning when a symbol lacks valid CRC")
It's pending in kbuild.git#fixes.
-Sedat-
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes=7d13fd96df875a9d786ee6dcc8fec460d35d4b12
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=fixes
> The above patch leads to the following problem building
> mpc85xx_defconfig + CONFIG_RELOCATABLE
>
>LD vmlinux
>SYSMAP System.map
>SORTTAB vmlinux
>CHKREL vmlinux
> WARNING: 451 bad relocations
> c0b0f26d R_PPC_UADDR32 .head.text-0x3ff9f2bc
> c0b0f271 R_PPC_UADDR32 .head.text-0x3ffac300
> c0b0f275 R_PPC_UADDR32 .head.text-0x3ffb0bdc
> c0b0f279 R_PPC_UADDR32 .head.text-0x3fe1e080
> c0b0f27d R_PPC_UADDR32 .head.text-0x3fe1df4c
> c0b0f281 R_PPC_UADDR32 .head.text-0x3fe21514
> c0b0f285 R_PPC_UADDR32 .head.text-0x3fe211c0
> c0b0f289 R_PPC_UADDR32 .head.text-0x3ffabda0
> c0b0f28d R_PPC_UADDR32 .head.text-0x3fe21258
> c0b0f291 R_PPC_UADDR32 .head.text-0x3fe074d0
> c0b0f295 R_PPC_UADDR32 .head.text-0x3fe07ad4
> c0b0f299 R_PPC_UADDR32 .head.text-0x3fe13470
> c0b0f29d R_PPC_UADDR32 .head.text-0x3fe22700
> c0b0f2a1 R_PPC_UADDR32 .head.text-0x3ff4b8e0
> c0b0f2a5 R_PPC_UADDR32 .head.text-0x3fe08320
> c0b0f2a9 R_PPC_UADDR32 .head.text-0x3fe220dc
> c0b0f2ad R_PPC_UADDR32 .head.text-0x3fe21da0
> c0b0f2b1 R_PPC_UADDR32 .head.text-0x3ff89dc0
> c0b0f2b5 R_PPC_UADDR32 .head.text-0x3fe16524
> c0b0f2b9 R_PPC_UADDR32 .head.text-0x3fe1ef74
> c0b0f2bd R_PPC_UADDR32 .head.text-0x3ff98b84
> c0b0f2c1 R_PPC_UADDR32 .head.text-0x3fdef9a0
> c0b0f2c5 R_PPC_UADDR32 .head.text-0x3fdf21ac
> c0b0f2c9 R_PPC_UADDR32 .head.text-0x3ff993c4
> ...
> c0b0f969 R_PPC_UADDR32 .head.text-0x3ff89dc0
> c0b0f96d R_PPC_UADDR32 .head.text-0x3fe9ad40
> c0b0f971 R_PPC_UADDR32 .head.text-0x3ff2eb00
> c0b0f975 R_PPC_UADDR32 .head.text-0x3ff89dc0
>
> And boot fails:
>
> Run /init as init process
> kernel tried to execute user page (0) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch (NULL pointer?)
> Faulting instruction address: 0x
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=4K MPC8544 DS
> Modules linked in:
> CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc1-00054-g7b4537199a4a #1523
> NIP: LR: c00150e4 CTR:
> REGS: c3091e10 TRAP: 0400 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
> MSR: 9000 CR: 88000422 XER: 2000
>
> GPR00: 4000 c3091f00 c30c8000 0013 b7bb9f4c b7bd8f60
> bfee6650
> GPR08: 0054 c0b0f26d c13b bfee6668
>
> GPR16: 84e08000 0800 0064 00102000 0001
> 0001
> GPR24: 0001 0001 b7b9c7d0 1034 0009 b7bd8f38 b7bd9854
> b7bd8688
> NIP [] 0x0
> LR [c00150e4] ret_from_syscall+0x0/0x28
> Call Trace:
> [c3091f00] [caf0] InstructionStorage+0x150/0x160 (unreliable)
> --- interrupt: c00 at 0xb7bb28e8
> NIP: b7bb28e8 LR: b7bb1384 CTR: b7bb1218
> REGS: c3091f10 TRAP: 0c00 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
> MSR: 0002d000 CR:
[PATCH] powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
On 32-bit powerpc systems with more PCIe controllers and more PCI domains,
where on more PCI domains are same PCI numbers, when kernel is compiled
with CONFIG_PROC_FS=y and CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT=y
options, kernel prints "proc_dir_entry 'pci/01' already registered" error
message.
[1.708861] [ cut here ]
[1.713429] proc_dir_entry 'pci/01' already registered
[1.718595] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:377
proc_register+0x1a8/0x1ac
[1.726361] Modules linked in:
[1.729404] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
5.19.0-rc5-0caacb197b677410bdac81bc34f05235+ #109
[1.740183] NIP: c02846e8 LR: c02846e8 CTR: c0015154
[1.745225] REGS: c146fc90 TRAP: 0700 Tainted: GW
(5.19.0-rc5-0caacb197b677410bdac81bc34f05235+)
[1.755657] MSR: 00029000 CR: 28000822 XER:
[1.761829]
[1.761829] GPR00: c02846e8 c146fd80 c14a8000 002a 3fffefff c146fc40
c146fc38
[1.761829] GPR08: 3fffefff c10ac04c 24000824
c0004548
[1.761829] GPR16:
0007
[1.761829] GPR24: c1d0 c167da54 c167da00 c112 c167dd6c c10b4abc
c167dc58 c167dd00
[1.796707] NIP [c02846e8] proc_register+0x1a8/0x1ac
[1.801663] LR [c02846e8] proc_register+0x1a8/0x1ac
[1.806532] Call Trace:
[1.808966] [c146fd80] [c02846e8] proc_register+0x1a8/0x1ac (unreliable)
[1.815659] [c146fdb0] [c028481c] _proc_mkdir+0x78/0xa4
[1.820875] [c146fdd0] [c05a92e4] pci_proc_attach_device+0x11c/0x168
[1.827221] [c146fe10] [c101f7a4] pci_proc_init+0x80/0x98
[1.832611] [c146fe30] [c0004150] do_one_initcall+0x80/0x284
[1.838262] [c146fea0] [c10011a8] kernel_init_freeable+0x1f4/0x2a0
[1.844434] [c146fee0] [c000456c] kernel_init+0x24/0x150
[1.849737] [c146ff00] [c001326c] ret_from_kernel_thread+0x5c/0x64
[1.855910] Instruction dump:
[1.858866] 83810020 83a10024 83c10028 83e1002c 38210030 4e800020 809a0064
3c60c0a8
[1.866602] 7f85e378 3863af28 4cc63182 4bdb8155 <0fe0> 9421ffe0
3920 7c0802a6
[1.874513] ---[ end trace ]---
This regression started appearing after commit 566356813082 ("powerpc/pci:
Add config option for using all 256 PCI buses") in case in each mPCIe slot
is connected PCIe card and therefore PCI bus 1 is populated in for every
PCIe controller / PCI domain.
The reason is that PCI procfs code expects that when PCI bus numbers are
not unique across all PCI domains, function pci_proc_domain() returns true
for domain dependent buses.
Fix this issue by setting PCI_ENABLE_PROC_DOMAINS and PCI_COMPAT_DOMAIN_0
flags for 32-bit powerpc code when CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
is enabled. Same approach is already implemented for 64-bit powerpc code
(where PCI bus numbers are always domain dependent).
Fixes: 566356813082 ("powerpc/pci: Add config option for using all 256 PCI
buses")
Signed-off-by: Pali Rohár
---
arch/powerpc/kernel/pci_32.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index ffc4e1928c80..8acbc9592ebb 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -249,6 +249,15 @@ static int __init pcibios_init(void)
printk(KERN_INFO "PCI: Probing PCI hardware\n");
+#ifdef CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT
+ /*
+* Enable PCI domains in /proc when PCI bus numbers are not unique
+* across all PCI domains to prevent conflicts. And keep PCI domain 0
+* backward compatible in /proc for video cards.
+*/
+ pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
+#endif
+
if (pci_has_flag(PCI_REASSIGN_ALL_BUS))
pci_assign_all_buses = 1;
--
2.20.1
Re: [PATCH v1 2/5] powerpc/32: Don't always pass -mcpu=powerpc to the compiler
On Thursday 18 August 2022 19:46:34 Pali Rohár wrote:
> On Monday 11 July 2022 16:19:30 Christophe Leroy wrote:
> > Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic
> > machine type for 32-bit compile"), when building a 32 bits kernel
> > with a bi-arch version of GCC, or when building a book3s/32 kernel,
> > the option -mcpu=powerpc is passed to GCC at all time, relying on it
> > being eventually overriden by a subsequent -mcpu=.
> >
> > But when building the same kernel with a 32 bits only version of GCC,
> > that is not done, relying on gcc being built with the expected default
> > CPU.
> >
> > This logic has two problems. First, it is a bit fragile to rely on
> > whether the GCC version is bi-arch or not, because today we can have
> > bi-arch versions of GCC configured with a 32 bits default. Second,
> > there are some versions of GCC which don't support -mcpu=powerpc,
> > for instance for e500 SPE-only versions.
> >
> > So, stop relying on this approximative logic and allow the user to
> > decide whether he/she wants to use the toolchain's default CPU or if
> > he/she wants to set one, and allow only possible CPUs based on the
> > selected target.
>
> Hello! Exactly same issue is still in file arch/powerpc/boot/Makefile:
>
> ifdef CONFIG_PPC64_BOOT_WRAPPER
> ifdef CONFIG_CPU_LITTLE_ENDIAN
> BOOTCFLAGS += -m64 -mcpu=powerpc64le
> else
> BOOTCFLAGS += -m64 -mcpu=powerpc64
> endif
> else
> BOOTCFLAGS += -m32 -mcpu=powerpc
> endif
>
> It cause compile error:
>
> make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnuspe- mpc85xx_smp_defconfig
> uImage
> ...
> BOOTAS arch/powerpc/boot/crt0.o
> powerpc-linux-gnuspe-gcc: error: unrecognized argument in option
> ‘-mcpu=powerpc’
> powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548
> native
> make[1]: *** [arch/powerpc/boot/Makefile:231: arch/powerpc/boot/crt0.o]
> Error 1
Now I have sent patch for this issue:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220820105200.30425-1-p...@kernel.org/
> > Reported-by: Pali Rohár
> > Tested-by: Pali Rohár
> > Reviewed-by: Arnd Bergmann
> > Cc: Segher Boessenkool
> > Signed-off-by: Christophe Leroy
> > ---
> > arch/powerpc/Makefile | 26 +-
> > arch/powerpc/platforms/Kconfig.cputype | 21 ++---
> > 2 files changed, 19 insertions(+), 28 deletions(-)
[PATCH] powerpc/boot: Fix compilation of uImage for e500 platforms
Commit 40a75584e526 ("powerpc/boot: Build wrapper for an appropriate CPU")
broke compilation of uImage target for mpc85xx platforms by powerpc e500
SPE capable cross compilers. After that commit build process throws error:
BOOTAS arch/powerpc/boot/crt0.o
powerpc-linux-gnuspe-gcc: error: unrecognized argument in option
‘-mcpu=powerpc’
powerpc-linux-gnuspe-gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548
native
make[1]: *** [arch/powerpc/boot/Makefile:231: arch/powerpc/boot/crt0.o] Error
1
Fix this issue by checking for CONFIG_PPC_E500MC / CONFIG_E500 options and
applying appropriate -mcpu options for building uImage boot code.
Fixes: 40a75584e526 ("powerpc/boot: Build wrapper for an appropriate CPU")
Cc: sta...@vger.kernel.org
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/Makefile | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index a9cd2ea4a861..d7cf5d87e4bc 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -44,8 +44,14 @@ else
BOOTCFLAGS += -m64 -mcpu=powerpc64
endif
else
+ifdef CONFIG_PPC_E500MC
+BOOTCFLAGS += -m32 $(call cc-option,-mcpu=e500mc,-mcpu=powerpc)
+else ifdef CONFIG_E500
+BOOTCFLAGS += -m32 $(call cc-option,-mcpu=8540 -msoft-float,-mcpu=powerpc)
+else
BOOTCFLAGS += -m32 -mcpu=powerpc
endif
+endif
BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
--
2.20.1
[PATCH 3/3] powerpc: dts: turris1x.dts: Set lower priority for CPLD syscon-reboot
Due to CPLD firmware bugs, set CPLD syscon-reboot priority level to 64
(between rstcr and watchdog) to ensure that rstcr's global-utilities reset
method which is preferred stay as default one, and to ensure that CPLD
syscon-reboot is more preferred than watchdog reset method.
Fixes: 0531a4abd1c6 ("powerpc: dts: turris1x.dts: Add CPLD reboot node")
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/dts/turris1x.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/powerpc/boot/dts/turris1x.dts
b/arch/powerpc/boot/dts/turris1x.dts
index 69c38ed8a3a5..c189293d5a1e 100644
--- a/arch/powerpc/boot/dts/turris1x.dts
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -353,11 +353,34 @@
};
reboot@d {
+ /*
+* CPLD firmware which manages system reset and
+* watchdog registers has bugs. It does not
+* autoclear system reset register after change
+* and watchdog ignores reset line on immediate
+* succeeding reset cycle triggered by watchdog.
+* These bugs have to be workarounded in U-Boot
+* bootloader. So use system reset via syscon as
+* a last resort because older U-Boot versions
+* do not have workaround for watchdog.
+*
+* Reset method via rstcr's global-utilities
+* (the preferred one) has priority level 128,
+* watchdog has priority level 0 and default
+* syscon-reboot priority level is 192.
+*
+* So define syscon-reboot with custom priority
+* level 64 (between rstcr and watchdog) because
+* rstcr should stay as default preferred reset
+* method and reset via watchdog is more broken
+* than system reset via syscon.
+*/
compatible = "syscon-reboot";
reg = <0x0d 0x01>;
offset = <0x0d>;
mask = <0x01>;
value = <0x01>;
+ priority = <64>;
};
led-controller@13 {
--
2.20.1
[PATCH 2/3] power: reset: syscon-reboot: Add support for specifying priority
Read new optional device tree property priority for specifying priority level of reset handler. Default value is 192 as before. Signed-off-by: Pali Rohár --- drivers/power/reset/syscon-reboot.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/power/reset/syscon-reboot.c b/drivers/power/reset/syscon-reboot.c index 510e363381ca..45e34e6885f7 100644 --- a/drivers/power/reset/syscon-reboot.c +++ b/drivers/power/reset/syscon-reboot.c @@ -44,6 +44,7 @@ static int syscon_reboot_probe(struct platform_device *pdev) struct syscon_reboot_context *ctx; struct device *dev = >dev; int mask_err, value_err; + int priority; int err; ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL); @@ -57,6 +58,9 @@ static int syscon_reboot_probe(struct platform_device *pdev) return PTR_ERR(ctx->map); } + if (of_property_read_s32(pdev->dev.of_node, "priority", )) + priority = 192; + if (of_property_read_u32(pdev->dev.of_node, "offset", >offset)) return -EINVAL; @@ -77,7 +81,7 @@ static int syscon_reboot_probe(struct platform_device *pdev) } ctx->restart_handler.notifier_call = syscon_restart_handle; - ctx->restart_handler.priority = 192; + ctx->restart_handler.priority = priority; err = register_restart_handler(>restart_handler); if (err) dev_err(dev, "can't register restart notifier (err=%d)\n", err); -- 2.20.1
[PATCH 1/3] dt-bindings: reset: syscon-reboot: Add priority property
This new optional priority property allows to specify custom priority level of reset device. Default level was always 192. Signed-off-by: Pali Rohár --- .../devicetree/bindings/power/reset/syscon-reboot.yaml| 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml index da2509724812..d905133aab27 100644 --- a/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml @@ -42,6 +42,10 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: The reset value written to the reboot register (32 bit access). + priority: +$ref: /schemas/types.yaml#/definitions/sint32 +description: Priority level of this syscon reset device. Default 192. + required: - compatible - offset -- 2.20.1
Build/boot problem with 7b4537199a4a (Re: [PATCH v6 02/10] kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS)
Hi,
Le 13/05/2022 à 13:39, Masahiro Yamada a écrit :
> include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
> as a placeholder.
>
> Genksyms writes the version CRCs into the linker script, which will be
> used for filling the __crc_* symbols. The linker script format depends
> on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
> to the reference of CRC.
>
> It is time to get rid of this complexity.
>
> Now that modpost parses text files (.*.cmd) to collect all the CRCs,
> it can generate C code that will be linked to the vmlinux or modules.
>
> Generate a new C file, .vmlinux.export.c, which contains the CRCs of
> symbols exported by vmlinux. It is compiled and linked to vmlinux in
> scripts/link-vmlinux.sh.
>
> Put the CRCs of symbols exported by modules into the existing *.mod.c
> files. No additional build step is needed for modules. As before,
> *.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
>
> No linker magic is used here. The new C implementation works in the
> same way, whether CONFIG_RELOCATABLE is enabled or not.
> CONFIG_MODULE_REL_CRCS is no longer needed.
>
> Previously, Kbuild invoked additional $(LD) to update the CRCs in
> objects, but this step is unneeded too.
>
> Signed-off-by: Masahiro Yamada
> Tested-by: Nathan Chancellor
> Tested-by: Nicolas Schier
> Reviewed-by: Nicolas Schier
Problem with v6.0-rc1
Problem with v5.19
No problem with v5.18
Bisected to 7b4537199a4a ("kbuild: link symbol CRCs at final link,
removing CONFIG_MODULE_REL_CRCS")
The above patch leads to the following problem building
mpc85xx_defconfig + CONFIG_RELOCATABLE
LD vmlinux
SYSMAP System.map
SORTTAB vmlinux
CHKREL vmlinux
WARNING: 451 bad relocations
c0b0f26d R_PPC_UADDR32 .head.text-0x3ff9f2bc
c0b0f271 R_PPC_UADDR32 .head.text-0x3ffac300
c0b0f275 R_PPC_UADDR32 .head.text-0x3ffb0bdc
c0b0f279 R_PPC_UADDR32 .head.text-0x3fe1e080
c0b0f27d R_PPC_UADDR32 .head.text-0x3fe1df4c
c0b0f281 R_PPC_UADDR32 .head.text-0x3fe21514
c0b0f285 R_PPC_UADDR32 .head.text-0x3fe211c0
c0b0f289 R_PPC_UADDR32 .head.text-0x3ffabda0
c0b0f28d R_PPC_UADDR32 .head.text-0x3fe21258
c0b0f291 R_PPC_UADDR32 .head.text-0x3fe074d0
c0b0f295 R_PPC_UADDR32 .head.text-0x3fe07ad4
c0b0f299 R_PPC_UADDR32 .head.text-0x3fe13470
c0b0f29d R_PPC_UADDR32 .head.text-0x3fe22700
c0b0f2a1 R_PPC_UADDR32 .head.text-0x3ff4b8e0
c0b0f2a5 R_PPC_UADDR32 .head.text-0x3fe08320
c0b0f2a9 R_PPC_UADDR32 .head.text-0x3fe220dc
c0b0f2ad R_PPC_UADDR32 .head.text-0x3fe21da0
c0b0f2b1 R_PPC_UADDR32 .head.text-0x3ff89dc0
c0b0f2b5 R_PPC_UADDR32 .head.text-0x3fe16524
c0b0f2b9 R_PPC_UADDR32 .head.text-0x3fe1ef74
c0b0f2bd R_PPC_UADDR32 .head.text-0x3ff98b84
c0b0f2c1 R_PPC_UADDR32 .head.text-0x3fdef9a0
c0b0f2c5 R_PPC_UADDR32 .head.text-0x3fdf21ac
c0b0f2c9 R_PPC_UADDR32 .head.text-0x3ff993c4
...
c0b0f969 R_PPC_UADDR32 .head.text-0x3ff89dc0
c0b0f96d R_PPC_UADDR32 .head.text-0x3fe9ad40
c0b0f971 R_PPC_UADDR32 .head.text-0x3ff2eb00
c0b0f975 R_PPC_UADDR32 .head.text-0x3ff89dc0
And boot fails:
Run /init as init process
kernel tried to execute user page (0) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K MPC8544 DS
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc1-00054-g7b4537199a4a #1523
NIP: LR: c00150e4 CTR:
REGS: c3091e10 TRAP: 0400 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
MSR: 9000 CR: 88000422 XER: 2000
GPR00: 4000 c3091f00 c30c8000 0013 b7bb9f4c b7bd8f60
bfee6650
GPR08: 0054 c0b0f26d c13b bfee6668
GPR16: 84e08000 0800 0064 00102000 0001
0001
GPR24: 0001 0001 b7b9c7d0 1034 0009 b7bd8f38 b7bd9854
b7bd8688
NIP [] 0x0
LR [c00150e4] ret_from_syscall+0x0/0x28
Call Trace:
[c3091f00] [caf0] InstructionStorage+0x150/0x160 (unreliable)
--- interrupt: c00 at 0xb7bb28e8
NIP: b7bb28e8 LR: b7bb1384 CTR: b7bb1218
REGS: c3091f10 TRAP: 0c00 Not tainted (5.18.0-rc1-00054-g7b4537199a4a)
MSR: 0002d000 CR: 28000422 XER: 2000
GPR00: 002d bfee61f0 0013 b7bb9f4c b7bd8f60
bfee6650
GPR08: 0054 0020 bfee6648 0001 bfee6668
GPR16: 84e08000 0800 0064 00102000 0001
0001
GPR24: 0001 0001 b7b9c7d0 1034 0009 b7bd8f38 b7bd9854
b7bd8688
NIP [b7bb28e8] 0xb7bb28e8
LR [b7bb1384] 0xb7bb1384
--- interrupt: c00
Instruction dump:
---[ end trace ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
Re: [PATCH v4 2/2] selftests/powerpc: Add a test for execute-only memory
Nicholas Miehlbradt writes: > On 17/8/2022 4:15 pm, Jordan Niethe wrote: >> On Wed, 2022-08-17 at 15:06 +1000, Russell Currey wrote: >>> From: Nicholas Miehlbradt >>> >>> This selftest is designed to cover execute-only protections >>> on the Radix MMU but will also work with Hash. >>> >>> The tests are based on those found in pkey_exec_test with modifications >>> to use the generic mprotect() instead of the pkey variants. >> >> Would it make sense to rename pkey_exec_test to exec_test and have this test >> be apart of that? >> > I think might make it unnecessarily complex. The checks needed when > testing with pkeys would mean that it would be necessary to check if > pkeys are enabled and choose which set of tests to run depending on the > result. The differences are substantial enough that it would be > challenging to combine them into a single set of tests. Yeah I think I agree. Having each test stand on its own is nice for debugging also. In general I'm less bothered about code duplication in tests. We should try and share code where we can, but it's more important that we have tests at all, rather than blocking new tests because they duplicate some code from another test. So I'm inclined to merge this as-is, we can always refactor it to share code in future if we think there's enough commonality to warrant it. cheers
