* Re: [PATCH] powerpc/rtas: Introduce rtas_get_sensor_nonblocking() for pci hotplug driver.
From: Tyrel Datwyler @ 2021-11-30 1:21 UTC (permalink / raw)
To: Nathan Lynch, Mahesh Salgaonkar, linuxppc-dev; +Cc: lxie, Oliver O'Halloran
In-Reply-To: <87sfveo3je.fsf@linux.ibm.com>
On 11/29/21 5:06 PM, Nathan Lynch wrote:
> Tyrel Datwyler <tyreld@linux.ibm.com> writes:
>> On 11/29/21 12:58 AM, Mahesh Salgaonkar wrote:
>>> -int rtas_get_sensor_fast(int sensor, int index, int *state)
>>> +static int
>>> +__rtas_get_sensor(int sensor, int index, int *state, bool warn_on)
>>> {
>>> int token = rtas_token("get-sensor-state");
>>> int rc;
>>> @@ -618,14 +619,26 @@ int rtas_get_sensor_fast(int sensor, int index, int *state)
>>> return -ENOENT;
>>>
>>> rc = rtas_call(token, 2, 2, state, sensor, index);
>>> - WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
>>> - rc <= RTAS_EXTENDED_DELAY_MAX));
>>> + WARN_ON(warn_on &&
>>> + (rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
>>> + rc <= RTAS_EXTENDED_DELAY_MAX)));
>>
>> The whole point of rtas_get_sensor_fast() is that on busy we will just let it
>> error out because we don't want to wait. I'm not sure I see the point of the
>> spurious WARN_ONs anytime we hit a BUSY or DELAY return code. Maybe converting
>> that to a pr_debug() might be better and save expanding the API with a _fast and
>> _nonblocking variant that do the same thing minus one surpressing a
>> WARN_ON splat.
>
> There is a subset of sensors that are specified to not ever return busy
> or delay statuses. rtas_get_sensor_fast() is meant to be used with
> those, and it would be an error to use it on a sensor not in that set.
> So the WARN_ON() is appropriate IMO; if it triggers it indicates either
> a misuse of the API or a firmware bug. See commit 1c2cb594441d
> "powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers"
>
Fair enough. Seems I misremembered the nature of the original problem and should
have looked back at the commit to completely jog my memory.
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS aebd1fb45c622e9a2b06fb70665d084d3a8d6c78
From: kernel test robot @ 2021-11-30 1:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: aebd1fb45c622e9a2b06fb70665d084d3a8d6c78 powerpc: flexible GPR range save/restore macros
elapsed time: 730m
configs tested: 187
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211128
powerpc pasemi_defconfig
powerpc mpc832x_mds_defconfig
xtensa smp_lx200_defconfig
arm iop32x_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
sh se7751_defconfig
xtensa nommu_kc705_defconfig
mips capcella_defconfig
powerpc tqm8555_defconfig
arm mv78xx0_defconfig
i386 defconfig
arm multi_v5_defconfig
m68k sun3_defconfig
powerpc tqm8540_defconfig
um defconfig
arm davinci_all_defconfig
mips malta_qemu_32r6_defconfig
powerpc cm5200_defconfig
mips qi_lb60_defconfig
mips cobalt_defconfig
powerpc akebono_defconfig
powerpc xes_mpc85xx_defconfig
powerpc ebony_defconfig
mips rm200_defconfig
sh sh7770_generic_defconfig
arm lpd270_defconfig
mips tb0219_defconfig
arm qcom_defconfig
mips xway_defconfig
parisc generic-64bit_defconfig
powerpc makalu_defconfig
arm axm55xx_defconfig
arm rpc_defconfig
nios2 3c120_defconfig
arc allyesconfig
xtensa xip_kc705_defconfig
powerpc mpc836x_mds_defconfig
s390 zfcpdump_defconfig
mips pic32mzda_defconfig
sparc64 alldefconfig
arm viper_defconfig
arm realview_defconfig
powerpc taishan_defconfig
arm palmz72_defconfig
powerpc wii_defconfig
mips rbtx49xx_defconfig
sh rsk7201_defconfig
arm mvebu_v7_defconfig
x86_64 defconfig
arm versatile_defconfig
microblaze mmu_defconfig
arm orion5x_defconfig
mips ip22_defconfig
sh se7722_defconfig
arc defconfig
mips omega2p_defconfig
mips ip28_defconfig
mips maltasmvp_eva_defconfig
m68k m5407c3_defconfig
arc nsim_700_defconfig
arm lubbock_defconfig
sh magicpanelr2_defconfig
mips gcw0_defconfig
arm imx_v6_v7_defconfig
mips rs90_defconfig
arm h5000_defconfig
arm imx_v4_v5_defconfig
arm simpad_defconfig
m68k m5249evb_defconfig
mips bmips_stb_defconfig
arm ep93xx_defconfig
arm neponset_defconfig
arm milbeaut_m10v_defconfig
sh shmin_defconfig
m68k m5272c3_defconfig
arm trizeps4_defconfig
powerpc mpc834x_itx_defconfig
m68k atari_defconfig
sh se7712_defconfig
arm ixp4xx_defconfig
powerpc ep88xc_defconfig
powerpc redwood_defconfig
sh sh7785lcr_32bit_defconfig
arm randconfig-c002-20211128
arm randconfig-c002-20211130
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 allnoconfig
nios2 defconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20211129
i386 randconfig-a002-20211129
i386 randconfig-a006-20211129
i386 randconfig-a005-20211129
i386 randconfig-a004-20211129
i386 randconfig-a003-20211129
x86_64 randconfig-a011-20211128
x86_64 randconfig-a014-20211128
x86_64 randconfig-a012-20211128
x86_64 randconfig-a016-20211128
x86_64 randconfig-a013-20211128
x86_64 randconfig-a015-20211128
i386 randconfig-a015-20211128
i386 randconfig-a016-20211128
i386 randconfig-a013-20211128
i386 randconfig-a012-20211128
i386 randconfig-a014-20211128
i386 randconfig-a011-20211128
arc randconfig-r043-20211128
s390 randconfig-r044-20211128
riscv randconfig-r042-20211128
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
s390 randconfig-c005-20211128
i386 randconfig-c001-20211128
riscv randconfig-c006-20211128
arm randconfig-c002-20211128
powerpc randconfig-c003-20211128
x86_64 randconfig-c007-20211128
mips randconfig-c004-20211128
x86_64 randconfig-a001-20211128
x86_64 randconfig-a006-20211128
x86_64 randconfig-a003-20211128
x86_64 randconfig-a005-20211128
x86_64 randconfig-a004-20211128
x86_64 randconfig-a002-20211128
i386 randconfig-a001-20211128
i386 randconfig-a002-20211128
i386 randconfig-a006-20211128
i386 randconfig-a005-20211128
i386 randconfig-a004-20211128
i386 randconfig-a003-20211128
i386 randconfig-a015-20211129
i386 randconfig-a016-20211129
i386 randconfig-a013-20211129
i386 randconfig-a012-20211129
i386 randconfig-a014-20211129
i386 randconfig-a011-20211129
hexagon randconfig-r045-20211129
hexagon randconfig-r041-20211129
s390 randconfig-r044-20211129
riscv randconfig-r042-20211129
hexagon randconfig-r045-20211128
hexagon randconfig-r041-20211128
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS af3fdce4ab0781ea183107c90de9cbf21d701c54
From: kernel test robot @ 2021-11-30 1:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: af3fdce4ab0781ea183107c90de9cbf21d701c54 Revert "powerpc/code-patching: Improve verification of patchability"
elapsed time: 730m
configs tested: 224
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211128
powerpc pasemi_defconfig
powerpc mpc832x_mds_defconfig
xtensa smp_lx200_defconfig
arm iop32x_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
sh se7751_defconfig
xtensa nommu_kc705_defconfig
mips capcella_defconfig
powerpc tqm8555_defconfig
arm mv78xx0_defconfig
i386 defconfig
arm multi_v5_defconfig
m68k sun3_defconfig
powerpc tqm8540_defconfig
um defconfig
sh kfr2r09-romimage_defconfig
arm mxs_defconfig
mips ath79_defconfig
arm alldefconfig
arm davinci_all_defconfig
mips malta_qemu_32r6_defconfig
powerpc cm5200_defconfig
mips qi_lb60_defconfig
mips cobalt_defconfig
powerpc akebono_defconfig
powerpc xes_mpc85xx_defconfig
powerpc ebony_defconfig
mips rm200_defconfig
sh sh7770_generic_defconfig
arm lpd270_defconfig
arm xcep_defconfig
mips loongson3_defconfig
arm integrator_defconfig
arm multi_v7_defconfig
powerpc mpc836x_rdk_defconfig
arm exynos_defconfig
powerpc canyonlands_defconfig
sh sh7710voipgw_defconfig
mips tb0219_defconfig
arm qcom_defconfig
mips xway_defconfig
parisc generic-64bit_defconfig
powerpc makalu_defconfig
arm axm55xx_defconfig
arm rpc_defconfig
nios2 3c120_defconfig
arc allyesconfig
xtensa xip_kc705_defconfig
powerpc mpc836x_mds_defconfig
s390 zfcpdump_defconfig
mips pic32mzda_defconfig
sparc64 alldefconfig
arm viper_defconfig
m68k alldefconfig
mips maltaup_defconfig
sh sh7785lcr_32bit_defconfig
arm realview_defconfig
powerpc taishan_defconfig
arm palmz72_defconfig
powerpc wii_defconfig
mips rbtx49xx_defconfig
sh rsk7201_defconfig
arm mvebu_v7_defconfig
x86_64 defconfig
arm versatile_defconfig
microblaze mmu_defconfig
arm orion5x_defconfig
mips ip22_defconfig
powerpc socrates_defconfig
riscv nommu_k210_sdcard_defconfig
sparc sparc32_defconfig
sh se7722_defconfig
arc defconfig
mips omega2p_defconfig
mips ip28_defconfig
mips maltasmvp_eva_defconfig
m68k m5407c3_defconfig
arc nsim_700_defconfig
arm lubbock_defconfig
sh magicpanelr2_defconfig
mips gcw0_defconfig
arm imx_v6_v7_defconfig
mips rs90_defconfig
arm h5000_defconfig
s390 debug_defconfig
arc haps_hs_smp_defconfig
m68k bvme6000_defconfig
openrisc defconfig
arm pcm027_defconfig
powerpc warp_defconfig
mips decstation_r4k_defconfig
nds32 defconfig
arm imx_v4_v5_defconfig
arm simpad_defconfig
m68k m5249evb_defconfig
mips bmips_stb_defconfig
arm ep93xx_defconfig
arm neponset_defconfig
arm milbeaut_m10v_defconfig
sh shmin_defconfig
m68k m5272c3_defconfig
arm trizeps4_defconfig
powerpc maple_defconfig
openrisc or1klitex_defconfig
sparc allyesconfig
xtensa defconfig
powerpc mpc837x_rdb_defconfig
powerpc mpc834x_itx_defconfig
m68k atari_defconfig
sh se7712_defconfig
arm ixp4xx_defconfig
powerpc ep88xc_defconfig
powerpc redwood_defconfig
arm shannon_defconfig
sh rsk7203_defconfig
arm u8500_defconfig
arm cerfcube_defconfig
arm randconfig-c002-20211128
arm randconfig-c002-20211129
arm randconfig-c002-20211130
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20211129
i386 randconfig-a002-20211129
i386 randconfig-a006-20211129
i386 randconfig-a005-20211129
i386 randconfig-a004-20211129
i386 randconfig-a003-20211129
x86_64 randconfig-a011-20211128
x86_64 randconfig-a014-20211128
x86_64 randconfig-a012-20211128
x86_64 randconfig-a016-20211128
x86_64 randconfig-a013-20211128
x86_64 randconfig-a015-20211128
i386 randconfig-a015-20211128
i386 randconfig-a016-20211128
i386 randconfig-a013-20211128
i386 randconfig-a012-20211128
i386 randconfig-a014-20211128
i386 randconfig-a011-20211128
arc randconfig-r043-20211128
s390 randconfig-r044-20211128
riscv randconfig-r042-20211128
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
s390 randconfig-c005-20211128
i386 randconfig-c001-20211128
riscv randconfig-c006-20211128
arm randconfig-c002-20211128
powerpc randconfig-c003-20211128
x86_64 randconfig-c007-20211128
mips randconfig-c004-20211128
x86_64 randconfig-a001-20211128
x86_64 randconfig-a006-20211128
x86_64 randconfig-a003-20211128
x86_64 randconfig-a005-20211128
x86_64 randconfig-a004-20211128
x86_64 randconfig-a002-20211128
i386 randconfig-a001-20211128
i386 randconfig-a002-20211128
i386 randconfig-a006-20211128
i386 randconfig-a005-20211128
i386 randconfig-a004-20211128
i386 randconfig-a003-20211128
x86_64 randconfig-a011-20211129
x86_64 randconfig-a014-20211129
x86_64 randconfig-a012-20211129
x86_64 randconfig-a016-20211129
x86_64 randconfig-a013-20211129
x86_64 randconfig-a015-20211129
i386 randconfig-a015-20211129
i386 randconfig-a016-20211129
i386 randconfig-a013-20211129
i386 randconfig-a012-20211129
i386 randconfig-a014-20211129
i386 randconfig-a011-20211129
hexagon randconfig-r045-20211129
hexagon randconfig-r041-20211129
s390 randconfig-r044-20211129
riscv randconfig-r042-20211129
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 3dc709e518b47386e6af937eaec37bb36539edfd
From: kernel test robot @ 2021-11-30 1:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 3dc709e518b47386e6af937eaec37bb36539edfd powerpc/85xx: Fix oops when CONFIG_FSL_PMC=n
elapsed time: 733m
configs tested: 225
configs skipped: 111
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211128
powerpc pasemi_defconfig
powerpc mpc832x_mds_defconfig
xtensa smp_lx200_defconfig
arm iop32x_defconfig
mips vocore2_defconfig
powerpc mpc5200_defconfig
sh se7751_defconfig
xtensa nommu_kc705_defconfig
mips capcella_defconfig
powerpc tqm8555_defconfig
arm mv78xx0_defconfig
i386 defconfig
arm multi_v5_defconfig
m68k sun3_defconfig
powerpc tqm8540_defconfig
um defconfig
arm mini2440_defconfig
powerpc mpc85xx_cds_defconfig
arm spear3xx_defconfig
arc axs103_defconfig
arm davinci_all_defconfig
mips malta_qemu_32r6_defconfig
powerpc cm5200_defconfig
mips qi_lb60_defconfig
mips cobalt_defconfig
powerpc akebono_defconfig
powerpc xes_mpc85xx_defconfig
powerpc ebony_defconfig
mips rm200_defconfig
sh sh7770_generic_defconfig
arm lpd270_defconfig
arm xcep_defconfig
mips loongson3_defconfig
arm integrator_defconfig
arm multi_v7_defconfig
h8300 h8s-sim_defconfig
sh ap325rxa_defconfig
mips decstation_64_defconfig
powerpc skiroot_defconfig
powerpc kmeter1_defconfig
powerpc mpc836x_rdk_defconfig
arm exynos_defconfig
powerpc canyonlands_defconfig
sh sh7710voipgw_defconfig
mips tb0219_defconfig
arm qcom_defconfig
mips xway_defconfig
parisc generic-64bit_defconfig
powerpc makalu_defconfig
arm axm55xx_defconfig
arm rpc_defconfig
nios2 3c120_defconfig
arc allyesconfig
xtensa xip_kc705_defconfig
powerpc mpc836x_mds_defconfig
s390 zfcpdump_defconfig
mips pic32mzda_defconfig
sparc64 alldefconfig
arm viper_defconfig
arm realview_defconfig
powerpc taishan_defconfig
arm palmz72_defconfig
powerpc wii_defconfig
mips rbtx49xx_defconfig
sh rsk7201_defconfig
arm mvebu_v7_defconfig
x86_64 defconfig
arm versatile_defconfig
microblaze mmu_defconfig
arm orion5x_defconfig
mips ip22_defconfig
powerpc socrates_defconfig
riscv nommu_k210_sdcard_defconfig
sparc sparc32_defconfig
mips ip28_defconfig
mips maltasmvp_eva_defconfig
m68k m5407c3_defconfig
arc nsim_700_defconfig
arm lubbock_defconfig
sh magicpanelr2_defconfig
powerpc redwood_defconfig
powerpc linkstation_defconfig
arm am200epdkit_defconfig
powerpc ksi8560_defconfig
mips gcw0_defconfig
arm imx_v6_v7_defconfig
mips omega2p_defconfig
mips rs90_defconfig
arm h5000_defconfig
openrisc defconfig
arm pcm027_defconfig
powerpc warp_defconfig
mips decstation_r4k_defconfig
nds32 defconfig
arm imx_v4_v5_defconfig
arm simpad_defconfig
m68k m5249evb_defconfig
mips bmips_stb_defconfig
arm ep93xx_defconfig
arm neponset_defconfig
arm milbeaut_m10v_defconfig
sh shmin_defconfig
m68k m5272c3_defconfig
arm trizeps4_defconfig
powerpc maple_defconfig
openrisc or1klitex_defconfig
sparc allyesconfig
xtensa defconfig
powerpc mpc837x_rdb_defconfig
powerpc mpc834x_itx_defconfig
m68k atari_defconfig
sh se7712_defconfig
arm ixp4xx_defconfig
powerpc ep88xc_defconfig
sh sh7785lcr_32bit_defconfig
arm shannon_defconfig
sh rsk7203_defconfig
arm u8500_defconfig
arm cerfcube_defconfig
arm randconfig-c002-20211128
arm randconfig-c002-20211130
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20211129
i386 randconfig-a002-20211129
i386 randconfig-a006-20211129
i386 randconfig-a005-20211129
i386 randconfig-a004-20211129
i386 randconfig-a003-20211129
x86_64 randconfig-a011-20211128
x86_64 randconfig-a014-20211128
x86_64 randconfig-a012-20211128
x86_64 randconfig-a016-20211128
x86_64 randconfig-a013-20211128
x86_64 randconfig-a015-20211128
i386 randconfig-a015-20211128
i386 randconfig-a016-20211128
i386 randconfig-a013-20211128
i386 randconfig-a012-20211128
i386 randconfig-a014-20211128
i386 randconfig-a011-20211128
arc randconfig-r043-20211128
s390 randconfig-r044-20211128
riscv randconfig-r042-20211128
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
s390 randconfig-c005-20211128
i386 randconfig-c001-20211128
riscv randconfig-c006-20211128
arm randconfig-c002-20211128
powerpc randconfig-c003-20211128
x86_64 randconfig-c007-20211128
mips randconfig-c004-20211128
x86_64 randconfig-a001-20211128
x86_64 randconfig-a006-20211128
x86_64 randconfig-a003-20211128
x86_64 randconfig-a005-20211128
x86_64 randconfig-a004-20211128
x86_64 randconfig-a002-20211128
i386 randconfig-a001-20211128
i386 randconfig-a002-20211128
i386 randconfig-a006-20211128
i386 randconfig-a005-20211128
i386 randconfig-a004-20211128
i386 randconfig-a003-20211128
x86_64 randconfig-a011-20211129
x86_64 randconfig-a014-20211129
x86_64 randconfig-a012-20211129
x86_64 randconfig-a016-20211129
x86_64 randconfig-a013-20211129
x86_64 randconfig-a015-20211129
i386 randconfig-a015-20211129
i386 randconfig-a016-20211129
i386 randconfig-a013-20211129
i386 randconfig-a012-20211129
i386 randconfig-a014-20211129
i386 randconfig-a011-20211129
hexagon randconfig-r045-20211129
hexagon randconfig-r041-20211129
s390 randconfig-r044-20211129
riscv randconfig-r042-20211129
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 260ac081931897ee7f554740c6cfc01c475aa703
From: kernel test robot @ 2021-11-30 1:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 260ac081931897ee7f554740c6cfc01c475aa703 Automatic merge of 'master' into merge (2021-11-29 16:53)
elapsed time: 730m
configs tested: 146
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211128
mips capcella_defconfig
powerpc tqm8555_defconfig
i386 defconfig
arm mv78xx0_defconfig
arm multi_v5_defconfig
m68k sun3_defconfig
powerpc tqm8540_defconfig
um defconfig
arm vt8500_v6_v7_defconfig
arm ep93xx_defconfig
xtensa common_defconfig
arm s3c2410_defconfig
powerpc kilauea_defconfig
mips malta_defconfig
arm davinci_all_defconfig
mips malta_qemu_32r6_defconfig
powerpc cm5200_defconfig
mips qi_lb60_defconfig
mips tb0219_defconfig
arm qcom_defconfig
mips xway_defconfig
parisc generic-64bit_defconfig
powerpc makalu_defconfig
mips tb0287_defconfig
arm s5pv210_defconfig
powerpc currituck_defconfig
arm imote2_defconfig
s390 zfcpdump_defconfig
powerpc socrates_defconfig
riscv nommu_k210_sdcard_defconfig
sparc sparc32_defconfig
mips cobalt_defconfig
mips gcw0_defconfig
arm imx_v6_v7_defconfig
mips omega2p_defconfig
arm h5000_defconfig
mips rs90_defconfig
sh se7722_defconfig
m68k m5307c3_defconfig
powerpc ebony_defconfig
arm omap1_defconfig
powerpc mpc83xx_defconfig
sh urquell_defconfig
powerpc ep88xc_defconfig
powerpc redwood_defconfig
sh sh7785lcr_32bit_defconfig
arm simpad_defconfig
arm shannon_defconfig
sh rsk7203_defconfig
arm u8500_defconfig
arm cerfcube_defconfig
m68k m5272c3_defconfig
arm randconfig-c002-20211128
arm randconfig-c002-20211130
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
arc defconfig
sh allmodconfig
h8300 allyesconfig
xtensa allyesconfig
parisc defconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
s390 allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20211129
i386 randconfig-a002-20211129
i386 randconfig-a006-20211129
i386 randconfig-a005-20211129
i386 randconfig-a004-20211129
i386 randconfig-a003-20211129
x86_64 randconfig-a011-20211128
x86_64 randconfig-a014-20211128
x86_64 randconfig-a012-20211128
x86_64 randconfig-a016-20211128
x86_64 randconfig-a013-20211128
x86_64 randconfig-a015-20211128
arc randconfig-r043-20211129
arc randconfig-r043-20211128
s390 randconfig-r044-20211128
riscv randconfig-r042-20211128
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
x86_64 randconfig-a001-20211128
x86_64 randconfig-a006-20211128
x86_64 randconfig-a003-20211128
x86_64 randconfig-a005-20211128
x86_64 randconfig-a004-20211128
x86_64 randconfig-a002-20211128
i386 randconfig-a001-20211128
i386 randconfig-a002-20211128
i386 randconfig-a003-20211128
i386 randconfig-a005-20211128
i386 randconfig-a004-20211128
i386 randconfig-a006-20211128
i386 randconfig-a015-20211129
i386 randconfig-a016-20211129
i386 randconfig-a013-20211129
i386 randconfig-a012-20211129
i386 randconfig-a014-20211129
i386 randconfig-a011-20211129
hexagon randconfig-r045-20211129
hexagon randconfig-r041-20211129
s390 randconfig-r044-20211129
riscv randconfig-r042-20211129
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] powerpc/rtas: Introduce rtas_get_sensor_nonblocking() for pci hotplug driver.
From: Nathan Lynch @ 2021-11-30 4:53 UTC (permalink / raw)
To: Mahesh Salgaonkar, linuxppc-dev; +Cc: Oliver O'Halloran
In-Reply-To: <163817631601.2016996.16085383012429651821.stgit@jupiter>
Mahesh Salgaonkar <mahesh@linux.ibm.com> writes:
> When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> state as temporarily unavailable until recovery is complete. This also
> triggers an EEH handler in Linux which needs to notify drivers, and perform
> recovery. But before notifying the driver about the pci error it uses
> get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to
> determine if the slot contains a device or not. if the slot is empty, the
> recovery is skipped entirely.
>
> However on certain PHB failures, the rtas call get-sesnor-state() returns
> extended busy error (9902) until PHB is recovered by phyp. Once PHB is
> recovered, the get-sensor-state() returns success with correct presence
> status. The rtas call interface rtas_get_sensor() loops over the rtas call
> on extended delay return code (9902) until the return value is either
> success (0) or error (-1). This causes the EEH handler to get stuck for ~6
> seconds before it could notify that the pci error has been detected and
> stop any active operations.
I am curious whether you see any difference with "powerpc/rtas:
rtas_busy_delay() improvements" which was recently applied. It will
cause the the calling task to sleep in response to a 990x status instead
of immediately retrying:
https://git.kernel.org/powerpc/c/38f7b7067dae0c101be573106018e8af22a90fdf
If that commit helps then maybe this change isn't needed.
Otherwise, see my comments below.
> -int rtas_get_sensor_fast(int sensor, int index, int *state)
> +static int
> +__rtas_get_sensor(int sensor, int index, int *state, bool warn_on)
Boolean flag parameters in this style are undesirable. As a reader you
can't infer the significance of a 'true' or 'false' in the argument list
at the call site.
> {
> int token = rtas_token("get-sensor-state");
> int rc;
> @@ -618,14 +619,26 @@ int rtas_get_sensor_fast(int sensor, int index, int *state)
> return -ENOENT;
>
> rc = rtas_call(token, 2, 2, state, sensor, index);
> - WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
> - rc <= RTAS_EXTENDED_DELAY_MAX));
> + WARN_ON(warn_on &&
> + (rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
> + rc <= RTAS_EXTENDED_DELAY_MAX)));
>
> if (rc < 0)
> return rtas_error_rc(rc);
> return rc;
> }
Issues I see with this, in terms of correctness and convention:
* On non-negative status from rtas_call(), including 990x,
__rtas_get_sensor() returns the RTAS status unchanged. On a negative
status, it returns a Linux errno value. On a -2 (busy) status
rtas_error_rc() prints an error message and returns -ERANGE. Seems
difficult for a caller to handle. Generally we want rtas_* APIs to
adhere to a Linux 0/-errno convention or to return the RTAS
status unchanged, but not a mixture.
* __rtas_get_sensor() is called by rtas_get_sensor_fast() and
rtas_get_sensor_nonblocking(), but is not called by rtas_get_sensor(),
despite common practice with __-prefixed functions.
> +int rtas_get_sensor_fast(int sensor, int index, int *state)
> +{
> + return __rtas_get_sensor(sensor, index, state, true);
> +}
> +
> +int rtas_get_sensor_nonblocking(int sensor, int index, int *state)
> +{
> + return __rtas_get_sensor(sensor, index, state, false);
> +}
> +EXPORT_SYMBOL(rtas_get_sensor_nonblocking);
> +
> bool rtas_indicator_present(int token, int *maxindex)
> {
> int proplen, count, i;
> diff --git a/drivers/pci/hotplug/rpaphp_pci.c b/drivers/pci/hotplug/rpaphp_pci.c
> index c380bdacd1466..8a7d681254ce9 100644
> --- a/drivers/pci/hotplug/rpaphp_pci.c
> +++ b/drivers/pci/hotplug/rpaphp_pci.c
> @@ -23,7 +23,7 @@ int rpaphp_get_sensor_state(struct slot *slot, int *state)
> int rc;
> int setlevel;
>
> - rc = rtas_get_sensor(DR_ENTITY_SENSE, slot->index, state);
> + rc = rtas_get_sensor_nonblocking(DR_ENTITY_SENSE, slot->index, state);
>
> if (rc < 0) {
> if (rc == -EFAULT || rc == -EEXIST) {
> @@ -38,10 +38,10 @@ int rpaphp_get_sensor_state(struct slot *slot, int *state)
> if (rc < 0) {
> dbg("%s: power on slot[%s] failed rc=%d.\n",
> __func__, slot->name, rc);
> - } else {
> - rc = rtas_get_sensor(DR_ENTITY_SENSE,
> - slot->index, state);
> + return rc;
> }
> + rc = rtas_get_sensor_nonblocking(DR_ENTITY_SENSE,
> + slot->index, state);
> } else if (rc == -ENODEV)
> info("%s: slot is unusable\n", __func__);
> else
If I'm reading it right rpaphp_get_sensor_state() now returns 9902 in
the situation this change is trying to address. I checked a couple of
its call sites and it seems like this is going to propagate back into
the PCI hotplug core which of course doesn't understand RTAS call
statuses. So this doesn't seem right.
Maybe it would be better to have rpaphp_get_sensor_state() invoke
rtas_call("get-sensor-state", ...) directly and code whatever special
behavior is needed there, instead of introducing a new exported API. The
driver seems to want to deal with the RTAS return values anyway - it's
implicitly mapping ENODEV, EFAULT, EEXIST from rtas_get_sensor() back to
-9002, -9000, -9001 respectively.
^ permalink raw reply
* Re: [PATCH v5 5/5] powerpc/inst: Optimise copy_inst_from_kernel_nofault()
From: Christophe Leroy @ 2021-11-30 5:58 UTC (permalink / raw)
To: kernel test robot, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Nick Desaulniers
Cc: linuxppc-dev, llvm, kbuild-all, linux-kernel
In-Reply-To: <202111300652.0yDBNvyJ-lkp@intel.com>
Le 29/11/2021 à 23:55, kernel test robot a écrit :
> Hi Christophe,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on powerpc/next]
> [also build test WARNING on v5.16-rc3 next-20211129]
> [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]
>
> url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-inst-Refactor-___get_user_instr/20211130-015346
> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> config: powerpc-randconfig-r023-20211129 (https://download.01.org/0day-ci/archive/20211130/202111300652.0yDBNvyJ-lkp@intel.com/config)
> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e)
> 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 powerpc cross compiling tool for clang build
> # apt-get install binutils-powerpc-linux-gnu
> # https://github.com/0day-ci/linux/commit/fb7bff30cc0efc7e4df1b48bb69de1f325eee826
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Christophe-Leroy/powerpc-inst-Refactor-___get_user_instr/20211130-015346
> git checkout fb7bff30cc0efc7e4df1b48bb69de1f325eee826
> # save the config file to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=powerpc prepare
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> In file included from arch/powerpc/kernel/asm-offsets.c:71:
> In file included from arch/powerpc/kernel/../xmon/xmon_bpts.h:7:
>>> arch/powerpc/include/asm/inst.h:165:20: warning: variable 'val' is uninitialized when used here [-Wuninitialized]
> *inst = ppc_inst(val);
> ^~~
> arch/powerpc/include/asm/inst.h:53:22: note: expanded from macro 'ppc_inst'
> #define ppc_inst(x) (x)
> ^
> arch/powerpc/include/asm/inst.h:155:18: note: initialize the variable 'val' to silence this warning
> unsigned int val, suffix;
> ^
> = 0
I can't understand what's wrong here.
We have
__get_kernel_nofault(&val, src, u32, Efault);
if (IS_ENABLED(CONFIG_PPC64) && get_op(val) == OP_PREFIX) {
__get_kernel_nofault(&suffix, src + 1, u32, Efault);
*inst = ppc_inst_prefix(val, suffix);
} else {
*inst = ppc_inst(val);
}
With
#define __get_kernel_nofault(dst, src, type, err_label) \
__get_user_size_goto(*((type *)(dst)), \
(__force type __user *)(src), sizeof(type), err_label)
And
#define __get_user_size_goto(x, ptr, size, label) \
do { \
BUILD_BUG_ON(size > sizeof(x)); \
switch (size) { \
case 1: __get_user_asm_goto(x, (u8 __user *)ptr, label, "lbz"); break; \
case 2: __get_user_asm_goto(x, (u16 __user *)ptr, label, "lhz"); break; \
case 4: __get_user_asm_goto(x, (u32 __user *)ptr, label, "lwz"); break; \
case 8: __get_user_asm2_goto(x, (u64 __user *)ptr, label); break; \
default: x = 0; BUILD_BUG(); \
} \
} while (0)
And
#define __get_user_asm_goto(x, addr, label, op) \
asm_volatile_goto( \
"1: "op"%U1%X1 %0, %1 # get_user\n" \
EX_TABLE(1b, %l2) \
: "=r" (x) \
: "m<>" (*addr) \
: \
: label)
I see no possibility, no alternative path where val wouldn't be set. The
asm clearly has *addr as an output param so it is always set.
> 1 warning generated.
> <stdin>:1559:2: warning: syscall futex_waitv not implemented [-W#warnings]
> #warning syscall futex_waitv not implemented
> ^
> 1 warning generated.
> arch/powerpc/kernel/vdso32/gettimeofday.S:72:8: error: unsupported directive '.stabs'
> .stabs "_restgpr_31_x:F-1",36,0,0,_restgpr_31_x; .globl _restgpr_31_x; _restgpr_31_x:
> ^
> arch/powerpc/kernel/vdso32/gettimeofday.S:73:8: error: unsupported directive '.stabs'
> .stabs "_rest32gpr_31_x:F-1",36,0,0,_rest32gpr_31_x; .globl _rest32gpr_31_x; _rest32gpr_31_x:
How should we fix that ? Will clang support .stabs in the future ?
> ^
> make[2]: *** [arch/powerpc/kernel/vdso32/Makefile:55: arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
> make[2]: Target 'include/generated/vdso32-offsets.h' not remade because of errors.
> make[1]: *** [arch/powerpc/Makefile:421: vdso_prepare] Error 2
> make[1]: Target 'prepare' not remade because of errors.
> make: *** [Makefile:219: __sub-make] Error 2
> make: Target 'prepare' not remade because of errors.
>
>
> vim +/val +165 arch/powerpc/include/asm/inst.h
>
> 152
> 153 static inline int copy_inst_from_kernel_nofault(ppc_inst_t *inst, u32 *src)
> 154 {
> 155 unsigned int val, suffix;
> 156
> 157 if (unlikely(!is_kernel_addr((unsigned long)src)))
> 158 return -ERANGE;
> 159
> 160 __get_kernel_nofault(&val, src, u32, Efault);
> 161 if (IS_ENABLED(CONFIG_PPC64) && get_op(val) == OP_PREFIX) {
> 162 __get_kernel_nofault(&suffix, src + 1, u32, Efault);
> 163 *inst = ppc_inst_prefix(val, suffix);
> 164 } else {
> > 165 *inst = ppc_inst(val);
> 166 }
> 167 return 0;
> 168 Efault:
> 169 return -EFAULT;
> 170 }
> 171
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
^ permalink raw reply
* Re: [PATCH RFC 1/4] mm: percpu: Generalize percpu related config
From: Kefeng Wang @ 2021-11-30 6:22 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaVV38QSn6LEBKH/@fedora>
On 2021/11/30 6:36, Dennis Zhou wrote:
> Hello,
>
> On Sun, Nov 21, 2021 at 05:35:54PM +0800, Kefeng Wang wrote:
>> The HAVE_SETUP_PER_CPU_AREA/NEED_PER_CPU_EMBED_FIRST_CHUNK/
>> NEED_PER_CPU_PAGE_FIRST_CHUNK/USE_PERCPU_NUMA_NODE_ID configs,
>> which has duplicate definitions on platforms that subscribe it.
>>
>> Move them into mm, drop these redundant definitions and instead
>> just select it on applicable platforms.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> arch/arm64/Kconfig | 20 ++++----------------
>> arch/ia64/Kconfig | 9 ++-------
>> arch/mips/Kconfig | 10 ++--------
>> arch/powerpc/Kconfig | 17 ++++-------------
>> arch/riscv/Kconfig | 10 ++--------
>> arch/sparc/Kconfig | 12 +++---------
>> arch/x86/Kconfig | 17 ++++-------------
>> mm/Kconfig | 12 ++++++++++++
>> 8 files changed, 33 insertions(+), 74 deletions(-)
...
>>
> This makes sense and looks good. A series like this is a little tricky.
> The latter patches change the contracts so it'd be easiest to run it
> through my tree. We'd need to get explicit acks from each arch
> maintainer to make sure they're fine with this.
Got it, I will resend without RFC and hope to get ACKs from related arch
maintainers.
>
> Thanks,
> Dennis
> .
^ permalink raw reply
* Re: [PATCH RFC 2/4] mm: percpu: Add pcpu_fc_cpu_to_node_fn_t typedef
From: Kefeng Wang @ 2021-11-30 6:22 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaVW8ZNQMUnnoWEB@fedora>
On 2021/11/30 6:40, Dennis Zhou wrote:
> On Sun, Nov 21, 2021 at 05:35:55PM +0800, Kefeng Wang wrote:
>> Add pcpu_fc_cpu_to_node_fn_t and pass it into pcpu_fc_alloc_fn_t,
>> pcpu first chunk allocation will call it to alloc memblock on the
>> corresponding node by it.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> arch/mips/mm/init.c | 12 +++++++++---
>> arch/powerpc/kernel/setup_64.c | 14 +++++++++++---
>> arch/sparc/kernel/smp_64.c | 8 +++++---
>> arch/x86/kernel/setup_percpu.c | 18 +++++++++++++-----
>> drivers/base/arch_numa.c | 8 +++++---
>> include/linux/percpu.h | 7 +++++--
>> mm/percpu.c | 14 +++++++++-----
>> 7 files changed, 57 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
...
>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>> index 6052f5d5ded3..9a5609c821df 100644
>> --- a/arch/powerpc/kernel/setup_64.c
>> +++ b/arch/powerpc/kernel/setup_64.c
>> @@ -771,6 +771,12 @@ void __init emergency_stack_init(void)
>> }
>>
>> #ifdef CONFIG_SMP
>> +
>> +static __init int pcpu_cpu_to_node(int cpu)
>> +{
>> + return IS_ENABLED(CONFIG_NUMA) ? early_cpu_to_node(cpu) : NUMA_NO_NODE;
>> +}
>> +
>> /**
>> * pcpu_alloc_bootmem - NUMA friendly alloc_bootmem wrapper for percpu
>> * @cpu: cpu to allocate for
>> @@ -784,12 +790,12 @@ void __init emergency_stack_init(void)
>> * RETURNS:
>> * Pointer to the allocated area on success, NULL on failure.
>> */
>> -static void * __init pcpu_alloc_bootmem(unsigned int cpu, size_t size,
>> - size_t align)
>> +static void * __init pcpu_alloc_bootmem(unsigned int cpu, size_t size, size_t align,
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn)
>> {
>> const unsigned long goal = __pa(MAX_DMA_ADDRESS);
>> #ifdef CONFIG_NUMA
>> - int node = early_cpu_to_node(cpu);
>> + int node = cpu_to_nd_fun(cpu);
> ^ typo - cpu_to_nd_fn().
Will fix.
...
>> if (rc < 0)
>> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
>> index ae4004e7957e..41bb54715b0c 100644
>> --- a/include/linux/percpu.h
>> +++ b/include/linux/percpu.h
>> @@ -94,8 +94,9 @@ extern const char * const pcpu_fc_names[PCPU_FC_NR];
>>
>> extern enum pcpu_fc pcpu_chosen_fc;
>>
>> -typedef void * (*pcpu_fc_alloc_fn_t)(unsigned int cpu, size_t size,
>> - size_t align);
>> +typedef int (pcpu_fc_cpu_to_node_fn_t)(int cpu);
>> +typedef void * (*pcpu_fc_alloc_fn_t)(unsigned int cpu, size_t size, size_t align,
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
>> typedef void (*pcpu_fc_free_fn_t)(void *ptr, size_t size);
>> typedef void (*pcpu_fc_populate_pte_fn_t)(unsigned long addr);
>> typedef int (pcpu_fc_cpu_distance_fn_t)(unsigned int from, unsigned int to);
>> @@ -111,6 +112,7 @@ extern void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
>> extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
>> size_t atom_size,
>> pcpu_fc_cpu_distance_fn_t cpu_distance_fn,
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn,
>> pcpu_fc_alloc_fn_t alloc_fn,
>> pcpu_fc_free_fn_t free_fn);
>> #endif
>> @@ -119,6 +121,7 @@ extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
>> extern int __init pcpu_page_first_chunk(size_t reserved_size,
>> pcpu_fc_alloc_fn_t alloc_fn,
>> pcpu_fc_free_fn_t free_fn,
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn,
>> pcpu_fc_populate_pte_fn_t populate_pte_fn);
>> #endif
> Be consistent here. In pcpu_setup_first_chunk() you add the
> cpu_to_node() before alloc()/free() and then in pcpu_embed_first_chunk()
> you add it after. I'd prefer to add it before as to keep the
> cpu_distance()/cpu_to_node() grouping.
Sure, will adjust the order.
^ permalink raw reply
* Re: [PATCH RFC 3/4] mm: percpu: Add generic pcpu_fc_alloc/free funciton
From: Kefeng Wang @ 2021-11-30 6:27 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaVYGCB+I7QLZo0+@fedora>
On 2021/11/30 6:45, Dennis Zhou wrote:
> On Sun, Nov 21, 2021 at 05:35:56PM +0800, Kefeng Wang wrote:
>> With previous patch, we could add a generic pcpu first chunk
>> allocation and free function to cleanup the duplicated definations
>> on each architecture.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> arch/mips/mm/init.c | 16 +--------
>> arch/powerpc/kernel/setup_64.c | 51 ++------------------------
>> arch/sparc/kernel/smp_64.c | 50 +-------------------------
>> arch/x86/kernel/setup_percpu.c | 59 +-----------------------------
>> drivers/base/arch_numa.c | 19 +---------
>> include/linux/percpu.h | 9 +----
>> mm/percpu.c | 66 ++++++++++++++++++----------------
>> 7 files changed, 42 insertions(+), 228 deletions(-)
...
>> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
>> index 41bb54715b0c..d73c97ef4ff4 100644
>> --- a/include/linux/percpu.h
>> +++ b/include/linux/percpu.h
>> @@ -95,9 +95,6 @@ extern const char * const pcpu_fc_names[PCPU_FC_NR];
>> extern enum pcpu_fc pcpu_chosen_fc;
>>
>> typedef int (pcpu_fc_cpu_to_node_fn_t)(int cpu);
>> -typedef void * (*pcpu_fc_alloc_fn_t)(unsigned int cpu, size_t size, size_t align,
>> - pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
>> -typedef void (*pcpu_fc_free_fn_t)(void *ptr, size_t size);
>> typedef void (*pcpu_fc_populate_pte_fn_t)(unsigned long addr);
>> typedef int (pcpu_fc_cpu_distance_fn_t)(unsigned int from, unsigned int to);
>>
>> @@ -112,15 +109,11 @@ extern void __init pcpu_setup_first_chunk(const struct pcpu_alloc_info *ai,
>> extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
>> size_t atom_size,
>> pcpu_fc_cpu_distance_fn_t cpu_distance_fn,
>> - pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn,
>> - pcpu_fc_alloc_fn_t alloc_fn,
>> - pcpu_fc_free_fn_t free_fn);
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
>> #endif
>>
>> #ifdef CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK
>> extern int __init pcpu_page_first_chunk(size_t reserved_size,
>> - pcpu_fc_alloc_fn_t alloc_fn,
>> - pcpu_fc_free_fn_t free_fn,
>> pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn,
>> pcpu_fc_populate_pte_fn_t populate_pte_fn);
>> #endif
>> diff --git a/mm/percpu.c b/mm/percpu.c
>> index 3f6cf1ff0be2..efaa1cbaf73d 100644
>> --- a/mm/percpu.c
>> +++ b/mm/percpu.c
>> @@ -2992,6 +2992,30 @@ static struct pcpu_alloc_info * __init __flatten pcpu_build_alloc_info(
>>
>> return ai;
>> }
>> +
>> +static void * __init pcpu_fc_alloc(unsigned int cpu, size_t size, size_t align,
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn)
>> +{
>> + const unsigned long goal = __pa(MAX_DMA_ADDRESS);
>> + int node = NUMA_NO_NODE;
>> + void *ptr;
>> +
>> + if (cpu_to_nd_fn)
>> + node = cpu_to_nd_fn(cpu);
>> +
>> + if (node == NUMA_NO_NODE || !node_online(node) || !NODE_DATA(node)) {
>> + ptr = memblock_alloc_from(size, align, goal);
>> + } else {
>> + ptr = memblock_alloc_try_nid(size, align, goal,
>> + MEMBLOCK_ALLOC_ACCESSIBLE, node);
>> + }
>> + return ptr;
>> +}
> My preference here would be to keep this identical to the x86
> implementation where we #ifdef CONFIG_NUMA.
I will add back '#ifdef CONFIG_NUMA', also will add back the
pr_debug/pr_info part as x86 does,
> Overall this makes sense.
>
> Thanks,
> Dennis
> .
^ permalink raw reply
* Re: [PATCH RFC 4/4] mm: percpu: Add generic pcpu_populate_pte() function
From: Kefeng Wang @ 2021-11-30 6:42 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaVZB/Lcis4iQ3RY@fedora>
On 2021/11/30 6:49, Dennis Zhou wrote:
> On Sun, Nov 21, 2021 at 05:35:57PM +0800, Kefeng Wang wrote:
>> When NEED_PER_CPU_PAGE_FIRST_CHUNK enabled, we need a function to
>> populate pte, add a generic pcpu populate pte function and switch
>> to use it.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> arch/powerpc/kernel/setup_64.c | 47 +--------------------
>> arch/sparc/kernel/smp_64.c | 57 +------------------------
>> arch/x86/kernel/setup_percpu.c | 5 +--
>> drivers/base/arch_numa.c | 51 +---------------------
>> include/linux/percpu.h | 5 +--
>> mm/percpu.c | 77 +++++++++++++++++++++++++++++++---
>> 6 files changed, 79 insertions(+), 163 deletions(-)
>>
...
>> diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
>> index cd672bd46241..4eadbe45078e 100644
>> --- a/arch/x86/kernel/setup_percpu.c
>> +++ b/arch/x86/kernel/setup_percpu.c
>> @@ -101,7 +101,7 @@ static int __init pcpu_cpu_to_node(int cpu)
>> return IS_ENABLED(CONFIG_NUMA) ? early_cpu_to_node(cpu) : NUMA_NO_NODE;
>> }
>>
>> -static void __init pcpup_populate_pte(unsigned long addr)
>> +void __init pcpu_populate_pte(unsigned long addr)
>> {
>> populate_extra_pte(addr);
>> }
>> @@ -163,8 +163,7 @@ void __init setup_per_cpu_areas(void)
>> }
>> if (rc < 0)
>> rc = pcpu_page_first_chunk(PERCPU_FIRST_CHUNK_RESERVE,
>> - pcpu_cpu_to_node,
>> - pcpup_populate_pte);
>> + pcpu_cpu_to_node);
> x86 has it's own implementation that differs for 32 bit. I'm not
> confident this is correct to drop in as a replacement for x86, so I'd
> prefer to keep populate_pte_fn() around.
The x86's pcpup_populate_pte() version is not dropped.
We define a __weak pcpu_populate_pte function in mm/percpu.c,
and there is a own version on x86, so no function change on x86.
I will add this into changelog,
arch/x86/kernel/setup_percpu.c: void __init pcpu_populate_pte(unsigned
long addr)
include/linux/percpu.h: void __init
pcpu_populate_pte(unsigned long addr);
mm/percpu.c: void __init __weak
pcpu_populate_pte(unsigned long addr)
mm/percpu.c: pcpu_populate_pte(unit_addr + (i << PAGE_SHIFT));
>> diff --git a/include/linux/percpu.h b/include/linux/percpu.h
>> index d73c97ef4ff4..f1ec5ad1351c 100644
>> --- a/include/linux/percpu.h
>> +++ b/include/linux/percpu.h
>> @@ -95,7 +95,6 @@ extern const char * const pcpu_fc_names[PCPU_FC_NR];
>> extern enum pcpu_fc pcpu_chosen_fc;
>>
>> typedef int (pcpu_fc_cpu_to_node_fn_t)(int cpu);
>> -typedef void (*pcpu_fc_populate_pte_fn_t)(unsigned long addr);
>> typedef int (pcpu_fc_cpu_distance_fn_t)(unsigned int from, unsigned int to);
>>
>> extern struct pcpu_alloc_info * __init pcpu_alloc_alloc_info(int nr_groups,
>> @@ -113,9 +112,9 @@ extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
>> #endif
>>
>> #ifdef CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK
>> +void __init pcpu_populate_pte(unsigned long addr);
>> extern int __init pcpu_page_first_chunk(size_t reserved_size,
>> - pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn,
>> - pcpu_fc_populate_pte_fn_t populate_pte_fn);
>> + pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
>> #endif
>>
>> extern void __percpu *__alloc_reserved_percpu(size_t size, size_t align) __alloc_size(1);
>> diff --git a/mm/percpu.c b/mm/percpu.c
>> index efaa1cbaf73d..d907daed04eb 100644
>> --- a/mm/percpu.c
>> +++ b/mm/percpu.c
>> @@ -3162,11 +3162,80 @@ int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
>> #endif /* BUILD_EMBED_FIRST_CHUNK */
>>
...
>> +void __init __weak pcpu_populate_pte(unsigned long addr)
>> +{
>> + pgd_t *pgd = pgd_offset_k(addr);
>> + p4d_t *p4d;
>> + pud_t *pud;
>> + pmd_t *pmd;
>> +
>> + if (pgd_none(*pgd)) {
>> + p4d_t *new;
>> +
>> + new = memblock_alloc_from(P4D_TABLE_SIZE, P4D_TABLE_SIZE, PAGE_SIZE);
> It's unnecessary to specify a min_addr to memblock_alloc_from() as it
> won't allocate 0 anyway. So please use memblock_alloc() instead.
ok, will use memblock_alloc in this function
^ permalink raw reply
* Re: [PATCH RFC 0/4] mm: percpu: Cleanup percpu first chunk funciton
From: Kefeng Wang @ 2021-11-30 6:53 UTC (permalink / raw)
To: Dennis Zhou
Cc: linux-ia64, dave.hansen, linux-mips, linux-mm, paulus, hpa,
sparclinux, cl, will, linux-riscv, x86, mingo, catalin.marinas,
aou, bp, paul.walmsley, tglx, linux-arm-kernel, tsbogend, gregkh,
linux-kernel, palmer, tj, akpm, linuxppc-dev, davem
In-Reply-To: <YaVaTwjiZmWz8PKY@fedora>
On 2021/11/30 6:55, Dennis Zhou wrote:
> Hello,
>
> On Sun, Nov 21, 2021 at 05:35:53PM +0800, Kefeng Wang wrote:
>> When support page mapping percpu first chunk allocator on arm64, we
>> found there are lots of duplicated codes in percpu embed/page first
>> chunk allocator. This patchset is aimed to cleanup them and should
>> no funciton change, only test on arm64.
>>
>> Kefeng Wang (4):
>> mm: percpu: Generalize percpu related config
>> mm: percpu: Add pcpu_fc_cpu_to_node_fn_t typedef
>> mm: percpu: Add generic pcpu_fc_alloc/free funciton
>> mm: percpu: Add generic pcpu_populate_pte() function
>>
>> arch/arm64/Kconfig | 20 +----
>> arch/ia64/Kconfig | 9 +--
>> arch/mips/Kconfig | 10 +--
>> arch/mips/mm/init.c | 14 +---
>> arch/powerpc/Kconfig | 17 +---
>> arch/powerpc/kernel/setup_64.c | 92 +--------------------
>> arch/riscv/Kconfig | 10 +--
>> arch/sparc/Kconfig | 12 +--
>> arch/sparc/kernel/smp_64.c | 105 +-----------------------
>> arch/x86/Kconfig | 17 +---
>> arch/x86/kernel/setup_percpu.c | 66 ++-------------
>> drivers/base/arch_numa.c | 68 +---------------
>> include/linux/percpu.h | 13 +--
>> mm/Kconfig | 12 +++
>> mm/percpu.c | 143 +++++++++++++++++++++++++--------
>> 15 files changed, 165 insertions(+), 443 deletions(-)
>>
>> --
>> 2.26.2
>>
> I've made a few comments. I think this will be a little bit of a
> challenge to get through due to it touching so many architectures. For
> ease, it probably makes sense to run it through mny tree, but we'll need
> explicit acks as I mentioned.
>
> I like getting rid of the pcpu_alloc_bootmem()/pcpu_free_bootmem()
> functions. However, let's keep the implementation identical to x86.
ok , will change patch3 in v2
>
>
> I don't think we should get rid of the populate_pte_fn(). I'm not
> comfortable changing x86's implementation. Simply offer a NULL, and if
> NULL use the default.
As replied in patch4, we use __weak method, and x86's implementation is
not changed in patch4, is this ok?
>
> Do you have a tree that intel pulls? I suggest cleaning up the patches
> and pushing to a remote branch that they pick up. That would have caught
> the mips typo. Send a PR creating a file in [1] for your branch, github
> is fine. Basic validation needs to be done before I can pick this up
> too on more than arm64.
Ok, x86/arm64/riscv are tested, but I don't has ppc/mips/sparc compliler.
I will try to push new version into github and test by lkp.
Thanks.
>
> [1] https://github.com/intel/lkp-tests/tree/master/repo/linux
>
> Thanks,
> Dennis
> .
^ permalink raw reply
* [RFC PATCH] powerpc/signal: sanitise PT_NIP and sa_handler low bits
From: Nicholas Piggin @ 2021-11-30 7:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
The bottom 2 bits of NIP are ignored when RFI returns with SRR0 = NIP,
so regs->nip does not correspond to the actual return address if either
of those bits are set. Further, these bits are reserved in SRR0 so they
should not be set. Sanitize PT_NIP from signal handlers to ensure they
can't be set by userspace, this also keeps the low 2 bit of TFHAR clear,
which are similarly reserved. 32-bit signal delivery returns directly to
the handler, so sa_handler is sanitised similarly there.
This can cause a bug when CONFIG_PPC_RFI_SRR_DEBUG=y on a processor that
does not implement the 2 low bits of SRR0 (always read back 0) because
SRR0 will not match regs->nip. This was caught by sigfuz, but a simple
reproducer follows.
#include <stdlib.h>
#include <signal.h>
#include <ucontext.h>
static void trap_signal_handler(int signo, siginfo_t *si, void *uc)
{
ucontext_t *ucp = uc;
ucp->uc_mcontext.gp_regs[PT_NIP] |= 3;
}
int main(void)
{
struct sigaction trap_sa;
trap_sa.sa_flags = SA_SIGINFO;
trap_sa.sa_sigaction = trap_signal_handler;
sigaction(SIGUSR1, &trap_sa, NULL);
raise(SIGUSR1);
exit(EXIT_SUCCESS);
}
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
I'm not entirely sure about the 32-bit / compat part. Or the 64-bit for
that matter except that it does seem to fix the bug caused by the test
program.
Thanks,
Nick
arch/powerpc/kernel/signal_32.c | 23 ++++++++++++++++-------
arch/powerpc/kernel/signal_64.c | 17 ++++++++++++-----
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 3e053e2fd6b6..5379bece8072 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -116,7 +116,7 @@ __unsafe_restore_general_regs(struct pt_regs *regs, struct mcontext __user *sr)
int i;
for (i = 0; i <= PT_RESULT; i++) {
- if ((i == PT_MSR) || (i == PT_SOFTE))
+ if ((i == PT_NIP) || (i == PT_MSR) || (i == PT_SOFTE))
continue;
unsafe_get_user(gregs[i], &sr->mc_gregs[i], failed);
}
@@ -156,7 +156,7 @@ static __always_inline
int __unsafe_restore_general_regs(struct pt_regs *regs, struct mcontext __user *sr)
{
/* copy up to but not including MSR */
- unsafe_copy_from_user(regs, &sr->mc_gregs, PT_MSR * sizeof(elf_greg_t), failed);
+ unsafe_copy_from_user(regs, &sr->mc_gregs, PT_NIP * sizeof(elf_greg_t), failed);
/* copy from orig_r3 (the word after the MSR) up to the end */
unsafe_copy_from_user(®s->orig_gpr3, &sr->mc_gregs[PT_ORIG_R3],
@@ -458,7 +458,7 @@ static long restore_user_regs(struct pt_regs *regs,
struct mcontext __user *sr, int sig)
{
unsigned int save_r2 = 0;
- unsigned long msr;
+ unsigned long nip, msr;
#ifdef CONFIG_VSX
int i;
#endif
@@ -473,6 +473,9 @@ static long restore_user_regs(struct pt_regs *regs,
save_r2 = (unsigned int)regs->gpr[2];
unsafe_restore_general_regs(regs, sr, failed);
set_trap_norestart(regs);
+ unsafe_get_user(nip, &sr->mc_gregs[PT_NIP], failed);
+ nip &= ~3UL;
+ regs_set_return_ip(regs, nip);
unsafe_get_user(msr, &sr->mc_gregs[PT_MSR], failed);
if (!sig)
regs->gpr[2] = (unsigned long) save_r2;
@@ -560,7 +563,7 @@ static long restore_tm_user_regs(struct pt_regs *regs,
struct mcontext __user *sr,
struct mcontext __user *tm_sr)
{
- unsigned long msr, msr_hi;
+ unsigned long nip, msr, msr_hi;
int i;
if (tm_suspend_disabled)
@@ -576,7 +579,9 @@ static long restore_tm_user_regs(struct pt_regs *regs,
return 1;
unsafe_restore_general_regs(¤t->thread.ckpt_regs, sr, failed);
- unsafe_get_user(current->thread.tm_tfhar, &sr->mc_gregs[PT_NIP], failed);
+ unsafe_get_user(nip, &sr->mc_gregs[PT_NIP], failed);
+ nip &= ~3UL;
+ current->thread.tm_tfhar = nip;
unsafe_get_user(msr, &sr->mc_gregs[PT_MSR], failed);
/* Restore the previous little-endian mode */
@@ -646,6 +651,10 @@ static long restore_tm_user_regs(struct pt_regs *regs,
current->thread.used_vsr = true;
}
+ unsafe_get_user(nip, &tm_sr->mc_gregs[PT_NIP], failed);
+ nip &= ~3UL;
+ regs_set_return_ip(regs, nip);
+
/* Get the top half of the MSR from the user context */
unsafe_get_user(msr_hi, &tm_sr->mc_gregs[PT_MSR], failed);
msr_hi <<= 32;
@@ -801,7 +810,7 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
regs->gpr[4] = (unsigned long)&frame->info;
regs->gpr[5] = (unsigned long)&frame->uc;
regs->gpr[6] = (unsigned long)frame;
- regs_set_return_ip(regs, (unsigned long) ksig->ka.sa.sa_handler);
+ regs_set_return_ip(regs, (unsigned long) ksig->ka.sa.sa_handler & ~3UL);
/* enter the signal handler in native-endian mode */
regs_set_return_msr(regs, (regs->msr & ~MSR_LE) | (MSR_KERNEL & MSR_LE));
@@ -889,7 +898,7 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset,
regs->gpr[1] = newsp;
regs->gpr[3] = ksig->sig;
regs->gpr[4] = (unsigned long) sc;
- regs_set_return_ip(regs, (unsigned long) ksig->ka.sa.sa_handler);
+ regs_set_return_ip(regs, (unsigned long) ksig->ka.sa.sa_handler & ~3UL);
/* enter the signal handler in native-endian mode */
regs_set_return_msr(regs, (regs->msr & ~MSR_LE) | (MSR_KERNEL & MSR_LE));
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index d1e1fc0acbea..5ef24adb9803 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -336,7 +336,7 @@ static long notrace __unsafe_restore_sigcontext(struct task_struct *tsk, sigset_
elf_vrreg_t __user *v_regs;
#endif
unsigned long save_r13 = 0;
- unsigned long msr;
+ unsigned long nip, msr;
struct pt_regs *regs = tsk->thread.regs;
#ifdef CONFIG_VSX
int i;
@@ -350,7 +350,9 @@ static long notrace __unsafe_restore_sigcontext(struct task_struct *tsk, sigset_
/* copy the GPRs */
unsafe_copy_from_user(regs->gpr, sc->gp_regs, sizeof(regs->gpr), efault_out);
- unsafe_get_user(regs->nip, &sc->gp_regs[PT_NIP], efault_out);
+ unsafe_get_user(nip, &sc->gp_regs[PT_NIP], efault_out);
+ nip &= ~3UL;
+ regs_set_return_ip(regs, nip);
/* get MSR separately, transfer the LE bit if doing signal return */
unsafe_get_user(msr, &sc->gp_regs[PT_MSR], efault_out);
if (sig)
@@ -434,7 +436,7 @@ static long restore_tm_sigcontexts(struct task_struct *tsk,
elf_vrreg_t __user *v_regs, *tm_v_regs;
#endif
unsigned long err = 0;
- unsigned long msr;
+ unsigned long nip, msr;
struct pt_regs *regs = tsk->thread.regs;
#ifdef CONFIG_VSX
int i;
@@ -458,8 +460,13 @@ static long restore_tm_sigcontexts(struct task_struct *tsk,
* For the case of getting a signal and simply returning from it,
* we don't need to re-copy them here.
*/
- err |= __get_user(regs->nip, &tm_sc->gp_regs[PT_NIP]);
- err |= __get_user(tsk->thread.tm_tfhar, &sc->gp_regs[PT_NIP]);
+ err |= __get_user(nip, &tm_sc->gp_regs[PT_NIP]);
+ nip &= ~3UL;
+ regs_set_return_ip(regs, nip);
+
+ err |= __get_user(nip, &sc->gp_regs[PT_NIP]);
+ nip &= ~3UL;
+ tsk->thread.tm_tfhar = nip;
/* get MSR separately, transfer the LE bit if doing signal return */
err |= __get_user(msr, &sc->gp_regs[PT_MSR]);
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries/vas: Don't print an error when VAS is unavailable
From: Haren Myneni @ 2021-11-30 7:35 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Cédric Le Goater,
linuxppc-dev
In-Reply-To: <87fsrepms0.fsf@mpe.ellerman.id.au>
On Tue, 2021-11-30 at 10:25 +1100, Michael Ellerman wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
> > Excerpts from Cédric Le Goater's message of November 26, 2021 5:13
> > pm:
> > > On 11/26/21 06:21, Nicholas Piggin wrote:
> > > > KVM does not support VAS so guests always print a useless error
> > > > on boot
> > > >
> > > > vas: HCALL(398) error -2, query_type 0, result buffer
> > > > 0x57f2000
> > > >
> > > > Change this to only print the message if the error is not
> > > > H_FUNCTION.
> > >
> > > Just being curious, why is it even called since "ibm,compression"
> > > should
> > > not be exposed in the DT ?
> >
> > It looks like vas does not test for it. I guess in theory there can
> > be
> > other functions than compression implemented as an accelerator.
> > Maybe
> > that's why?
>
> Yeah I guess, or it's just not structured that well. The vas platform
> code is a bit awkward, it's there to support drivers, but it's not
> actually driver code.
>
> I think we can probably rework it so the vas code does nothing until
> a
> driver calls in to it.
>
> eg. something like below.
Correct, Even though NXGZIP is the only usage right now, VAS is
accelerator switchboard which should support other coprocessor types
such as GZIP and 842 or SW type solutions such as fast thread wakeup
and fast memory copy.
So can we leave VAS initialization separate from drivers and use some
feature such as FW_FEATURE_LPAR to differentiate from KVM guests?
Thanks
Haren
>
> cheers
>
>
> diff --git a/arch/powerpc/platforms/pseries/vas.c
> b/arch/powerpc/platforms/pseries/vas.c
> index b043e3936d21..dc3491fc919d 100644
> --- a/arch/powerpc/platforms/pseries/vas.c
> +++ b/arch/powerpc/platforms/pseries/vas.c
> @@ -454,6 +454,8 @@ static const struct vas_user_win_ops vops_pseries
> = {
> .close_win = vas_deallocate_window, /* Close window */
> };
>
> +static int pseries_vas_init(void);
> +
> /*
> * Supporting only nx-gzip coprocessor type now, but this API code
> * extended to other coprocessor types later.
> @@ -463,7 +465,8 @@ int vas_register_api_pseries(struct module *mod,
> enum vas_cop_type cop_type,
> {
> int rc;
>
> - if (!copypaste_feat)
> + rc = pseries_vas_init();
> + if (rc || !copypaste_feat)
> return -ENOTSUPP;
>
> rc = vas_register_coproc_api(mod, cop_type, name,
> &vops_pseries);
> @@ -531,7 +534,7 @@ static int get_vas_capabilities(u8 feat, enum
> vas_cop_feat_type type,
> return 0;
> }
>
> -static int __init pseries_vas_init(void)
> +static int pseries_vas_init(void)
> {
> struct hv_vas_cop_feat_caps *hv_cop_caps;
> struct hv_vas_all_caps *hv_caps;
> @@ -592,4 +595,3 @@ static int __init pseries_vas_init(void)
> kfree(hv_caps);
> return rc;
> }
> -machine_device_initcall(pseries, pseries_vas_init);
^ permalink raw reply
* [PATCH] powerpc/32s: Fix shift-out-of-bounds in KASAN init
From: Christophe Leroy @ 2021-11-30 8:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
================================================================================
UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23
shift exponent -1 is negative
CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.5-gentoo-PowerMacG4 #9
Call Trace:
[c214be60] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable)
[c214be80] [c0b99288] ubsan_epilogue+0x10/0x5c
[c214be90] [c0b98fe0] __ubsan_handle_shift_out_of_bounds+0x94/0x138
[c214bf00] [c1c0f010] kasan_init_region+0xd8/0x26c
[c214bf30] [c1c0ed84] kasan_init+0xc0/0x198
[c214bf70] [c1c08024] setup_arch+0x18/0x54c
[c214bfc0] [c1c037f0] start_kernel+0x90/0x33c
[c214bff0] [00003610] 0x3610
================================================================================
This happens when the directly mapped memory is a power of 2.
Fix it by checking the shift and set the result to 0 when shift is -1
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215169
Fixes: 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/mm/kasan/book3s_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/kasan/book3s_32.c b/arch/powerpc/mm/kasan/book3s_32.c
index 202bd260a009..35b287b0a8da 100644
--- a/arch/powerpc/mm/kasan/book3s_32.c
+++ b/arch/powerpc/mm/kasan/book3s_32.c
@@ -19,7 +19,8 @@ int __init kasan_init_region(void *start, size_t size)
block = memblock_alloc(k_size, k_size_base);
if (block && k_size_base >= SZ_128K && k_start == ALIGN(k_start, k_size_base)) {
- int k_size_more = 1 << (ffs(k_size - k_size_base) - 1);
+ int shift = ffs(k_size - k_size_base);
+ int k_size_more = shift ? 1 << (shift - 1) : 0;
setbat(-1, k_start, __pa(block), k_size_base, PAGE_KERNEL);
if (k_size_more >= SZ_128K)
--
2.33.1
^ permalink raw reply related
* Re: [RFC PATCH 0/3] Use pageblock_order for cma and alloc_contig_range alignment.
From: Vlastimil Babka @ 2021-11-30 9:11 UTC (permalink / raw)
To: Zi Yan
Cc: Mel Gorman, David Hildenbrand, linuxppc-dev, linux-kernel,
virtualization, linux-mm, iommu, Robin Murphy, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <35A20739-152A-450E-8535-2236D2B28748@nvidia.com>
On 11/29/21 23:08, Zi Yan wrote:
> On 23 Nov 2021, at 12:32, Vlastimil Babka wrote:
>
>> On 11/23/21 17:35, Zi Yan wrote:
>>> On 19 Nov 2021, at 10:15, Zi Yan wrote:
>>>>>> From what my understanding, cma required alignment of
>>>>>> max(MAX_ORDER - 1, pageblock_order), because when MIGRATE_CMA was introduced,
>>>>>> __free_one_page() does not prevent merging two different pageblocks, when
>>>>>> MAX_ORDER - 1 > pageblock_order. But current __free_one_page() implementation
>>>>>> does prevent that.
>>>>>
>>>>> But it does prevent that only for isolated pageblock, not CMA, and yout
>>>>> patchset doesn't seem to expand that to CMA? Or am I missing something.
>>>>
>>>> Yeah, you are right. Originally, I thought preventing merging isolated pageblock
>>>> with other types of pageblocks is sufficient, since MIGRATE_CMA is always
>>>> converted from MIGRATE_ISOLATE. But that is not true. I will rework the code.
>>>> Thanks for pointing this out.
>>>>
>>>
>>> I find that two pageblocks with different migratetypes, like MIGRATE_RECLAIMABLE
>>> and MIGRATE_MOVABLE can be merged into a single free page after I checked
>>> __free_one_page() in detail and printed pageblock information during buddy page
>>> merging.
>>
>> Yes, that can happen.
>>
>> I am not sure what consequence it will cause. Do you have any idea?
>>
>> For MIGRATE_RECLAIMABLE or MIGRATE_MOVABLE or even MIGRATE_UNMOVABLE it's
>> absolutely fine. As long as these pageblocks are fully free (and they are if
>> it's a single free page spanning 2 pageblocks), they can be of any of these
>> type, as they can be reused as needed without causing fragmentation.
>>
>> But in case of MIGRATE_CMA and MIGRATE_ISOLATE, uncontrolled merging would
>> break the specifics of those types. That's why the code is careful for
>> MIGRATE_ISOLATE, and MIGRATE_CMA was until now done in MAX_ORDER granularity.
>
> Thanks for the explanation. Basically migratetypes that can fall back to each
> other can be merged into a single free page, right?
Yes.
> How about MIGRATE_HIGHATOMIC? It should not be merged with other migratetypes
> from my understanding.
Hmm it shouldn't minimally because it has an accounting that would become
broken. So it should prevent merging or make sure the reservations are with
MAX_ORDER granularity, but seems that neither is true? CCing Mel.
> --
> Best Regards,
> Yan, Zi
>
^ permalink raw reply
* [PATCH] powerpc/powermac: Add missing lockdep_register_key()
From: Christophe Leroy @ 2021-11-30 9:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
KeyWest i2c @0xf8001003 irq 42 /uni-n@f8000000/i2c@f8001000
BUG: key c2d00cbc has not been registered!
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x4c0/0xb4c
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.5-gentoo-PowerMacG4 #9
NIP: c01a9428 LR: c01a9428 CTR: 00000000
REGS: e1033cf0 TRAP: 0700 Not tainted (5.15.5-gentoo-PowerMacG4)
MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002002 XER: 00000000
GPR00: c01a9428 e1033db0 c2d1cf20 00000016 00000004 00000001 c01c0630 e1033a73
GPR08: 00000000 00000000 00000000 e1033db0 24002004 00000000 f8729377 00000003
GPR16: c1829a9c 00000000 18305357 c1416fc0 c1416f80 c006ac60 c2d00ca8 c1416f00
GPR24: 00000000 c21586f0 c2160000 00000000 c2d00cbc c2170000 c216e1a0 c2160000
NIP [c01a9428] lockdep_init_map_type+0x4c0/0xb4c
LR [c01a9428] lockdep_init_map_type+0x4c0/0xb4c
Call Trace:
[e1033db0] [c01a9428] lockdep_init_map_type+0x4c0/0xb4c (unreliable)
[e1033df0] [c1c177b8] kw_i2c_add+0x334/0x424
[e1033e20] [c1c18294] pmac_i2c_init+0x9ec/0xa9c
[e1033e80] [c1c1a790] smp_core99_probe+0xbc/0x35c
[e1033eb0] [c1c03cb0] kernel_init_freeable+0x190/0x5a4
[e1033f10] [c000946c] kernel_init+0x28/0x154
[e1033f30] [c0035148] ret_from_kernel_thread+0x14/0x1c
Add missing lockdep_register_key()
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/platforms/powermac/low_i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index f77a59b5c2e1..de34fa34c42d 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -582,6 +582,7 @@ static void __init kw_i2c_add(struct pmac_i2c_host_kw *host,
bus->close = kw_i2c_close;
bus->xfer = kw_i2c_xfer;
mutex_init(&bus->mutex);
+ lockdep_register_key(&bus->lock_key);
lockdep_set_class(&bus->mutex, &bus->lock_key);
if (controller == busnode)
bus->flags = pmac_i2c_multibus;
--
2.33.1
^ permalink raw reply related
* Re: [PATCH] powerpc/rtas: Introduce rtas_get_sensor_nonblocking() for pci hotplug driver.
From: Mahesh J Salgaonkar @ 2021-11-30 9:31 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Oliver O'Halloran
In-Reply-To: <87o862nt0q.fsf@linux.ibm.com>
On 2021-11-29 22:53:41 Mon, Nathan Lynch wrote:
> Mahesh Salgaonkar <mahesh@linux.ibm.com> writes:
> > When certain PHB HW failure causes phyp to recover PHB, it marks the PE
> > state as temporarily unavailable until recovery is complete. This also
> > triggers an EEH handler in Linux which needs to notify drivers, and perform
> > recovery. But before notifying the driver about the pci error it uses
> > get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to
> > determine if the slot contains a device or not. if the slot is empty, the
> > recovery is skipped entirely.
> >
> > However on certain PHB failures, the rtas call get-sesnor-state() returns
> > extended busy error (9902) until PHB is recovered by phyp. Once PHB is
> > recovered, the get-sensor-state() returns success with correct presence
> > status. The rtas call interface rtas_get_sensor() loops over the rtas call
> > on extended delay return code (9902) until the return value is either
> > success (0) or error (-1). This causes the EEH handler to get stuck for ~6
> > seconds before it could notify that the pci error has been detected and
> > stop any active operations.
>
> I am curious whether you see any difference with "powerpc/rtas:
> rtas_busy_delay() improvements" which was recently applied. It will
> cause the the calling task to sleep in response to a 990x status instead
> of immediately retrying:
If it is still sleeping it may not help, however I will give a try.
>
> https://git.kernel.org/powerpc/c/38f7b7067dae0c101be573106018e8af22a90fdf
>
> If that commit helps then maybe this change isn't needed.
>
> Otherwise, see my comments below.
>
>
> > -int rtas_get_sensor_fast(int sensor, int index, int *state)
> > +static int
> > +__rtas_get_sensor(int sensor, int index, int *state, bool warn_on)
>
> Boolean flag parameters in this style are undesirable. As a reader you
> can't infer the significance of a 'true' or 'false' in the argument list
> at the call site.
>
> > {
> > int token = rtas_token("get-sensor-state");
> > int rc;
> > @@ -618,14 +619,26 @@ int rtas_get_sensor_fast(int sensor, int index, int *state)
> > return -ENOENT;
> >
> > rc = rtas_call(token, 2, 2, state, sensor, index);
> > - WARN_ON(rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
> > - rc <= RTAS_EXTENDED_DELAY_MAX));
> > + WARN_ON(warn_on &&
> > + (rc == RTAS_BUSY || (rc >= RTAS_EXTENDED_DELAY_MIN &&
> > + rc <= RTAS_EXTENDED_DELAY_MAX)));
> >
> > if (rc < 0)
> > return rtas_error_rc(rc);
> > return rc;
> > }
>
> Issues I see with this, in terms of correctness and convention:
>
> * On non-negative status from rtas_call(), including 990x,
> __rtas_get_sensor() returns the RTAS status unchanged. On a negative
> status, it returns a Linux errno value. On a -2 (busy) status
> rtas_error_rc() prints an error message and returns -ERANGE. Seems
> difficult for a caller to handle. Generally we want rtas_* APIs to
> adhere to a Linux 0/-errno convention or to return the RTAS
> status unchanged, but not a mixture.
>
> * __rtas_get_sensor() is called by rtas_get_sensor_fast() and
> rtas_get_sensor_nonblocking(), but is not called by rtas_get_sensor(),
> despite common practice with __-prefixed functions.
>
> > +int rtas_get_sensor_fast(int sensor, int index, int *state)
> > +{
> > + return __rtas_get_sensor(sensor, index, state, true);
> > +}
> > +
> > +int rtas_get_sensor_nonblocking(int sensor, int index, int *state)
> > +{
> > + return __rtas_get_sensor(sensor, index, state, false);
> > +}
> > +EXPORT_SYMBOL(rtas_get_sensor_nonblocking);
> > +
> > bool rtas_indicator_present(int token, int *maxindex)
> > {
> > int proplen, count, i;
> > diff --git a/drivers/pci/hotplug/rpaphp_pci.c b/drivers/pci/hotplug/rpaphp_pci.c
> > index c380bdacd1466..8a7d681254ce9 100644
> > --- a/drivers/pci/hotplug/rpaphp_pci.c
> > +++ b/drivers/pci/hotplug/rpaphp_pci.c
> > @@ -23,7 +23,7 @@ int rpaphp_get_sensor_state(struct slot *slot, int *state)
> > int rc;
> > int setlevel;
> >
> > - rc = rtas_get_sensor(DR_ENTITY_SENSE, slot->index, state);
> > + rc = rtas_get_sensor_nonblocking(DR_ENTITY_SENSE, slot->index, state);
> >
> > if (rc < 0) {
> > if (rc == -EFAULT || rc == -EEXIST) {
> > @@ -38,10 +38,10 @@ int rpaphp_get_sensor_state(struct slot *slot, int *state)
> > if (rc < 0) {
> > dbg("%s: power on slot[%s] failed rc=%d.\n",
> > __func__, slot->name, rc);
> > - } else {
> > - rc = rtas_get_sensor(DR_ENTITY_SENSE,
> > - slot->index, state);
> > + return rc;
> > }
> > + rc = rtas_get_sensor_nonblocking(DR_ENTITY_SENSE,
> > + slot->index, state);
> > } else if (rc == -ENODEV)
> > info("%s: slot is unusable\n", __func__);
> > else
>
> If I'm reading it right rpaphp_get_sensor_state() now returns 9902 in
> the situation this change is trying to address. I checked a couple of
> its call sites and it seems like this is going to propagate back into
> the PCI hotplug core which of course doesn't understand RTAS call
> statuses. So this doesn't seem right.
Thanks for pointing it out. I should convert that into an error before
returning. I overlooked this when I moved away from get_sensor_state().
>
> Maybe it would be better to have rpaphp_get_sensor_state() invoke
> rtas_call("get-sensor-state", ...) directly and code whatever special
> behavior is needed there, instead of introducing a new exported API. The
> driver seems to want to deal with the RTAS return values anyway - it's
> implicitly mapping ENODEV, EFAULT, EEXIST from rtas_get_sensor() back to
> -9002, -9000, -9001 respectively.
Sure I will try this.
Thanks,
-Mahesh.
--
Mahesh J Salgaonkar
^ permalink raw reply
* [PATCH] powerpc/modules: Don't WARN on first module allocation tentative
From: Christophe Leroy @ 2021-11-30 10:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Erhard Furtner, linuxppc-dev, linux-kernel
module_alloc() first tries to allocate module text within
24 bits direct jump from kernel text, and tries a wider
allocation if first one fails.
When first allocation fails the following is observed in kernel logs:
vmap allocation for size 2400256 failed: use vmalloc=<size> to increase size
systemd-udevd: vmalloc error: size 2395133, vm_struct allocation failed, mode:0xcc0(GFP_KERNEL), nodemask=(null)
CPU: 0 PID: 127 Comm: systemd-udevd Tainted: G W 5.15.5-gentoo-PowerMacG4 #9
Call Trace:
[e2a53a50] [c0ba0048] dump_stack_lvl+0x80/0xb0 (unreliable)
[e2a53a70] [c0540128] warn_alloc+0x11c/0x2b4
[e2a53b50] [c0531be8] __vmalloc_node_range+0xd8/0x64c
[e2a53c10] [c00338c0] module_alloc+0xa0/0xac
[e2a53c40] [c027a368] load_module+0x2ae0/0x8148
[e2a53e30] [c027fc78] sys_finit_module+0xfc/0x130
[e2a53f30] [c0035098] ret_from_syscall+0x0/0x28
--- interrupt: c00 at 0x25df10
NIP: 0025df10 LR: 00416180 CTR: 00000000
REGS: e2a53f40 TRAP: 0c00 Tainted: G W (5.15.5-gentoo-PowerMacG4)
MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 2822242c XER: 20000000
GPR00: 00000161 afa8f060 a73a6160 00000011 0041dfa5 00000000 00000011 00000000
GPR08: 00000000 20000000 0000007a afa8efe0 002113f8 0072f924 00000000 00000000
GPR16: 00000005 afa8f1fc afa8f1e8 00000000 22222422 00000000 009603b0 22222422
GPR24: 00000000 00000000 0041dfa5 008a5fc0 00020000 00000000 00444cc4 009958f0
NIP [0025df10] 0x25df10
LR [00416180] 0x416180
--- interrupt: c00
Mem-Info:
active_anon:36 inactive_anon:4417 isolated_anon:0
active_file:3496 inactive_file:10535 isolated_file:0
unevictable:0 dirty:59 writeback:0
slab_reclaimable:3672 slab_unreclaimable:20540
mapped:5700 shmem:166 pagetables:185 bounce:0
kernel_misc_reclaimable:0
free:438282 free_pcp:1121 free_cma:0
Node 0 active_anon:144kB inactive_anon:17668kB active_file:13984kB inactive_file:42140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:22800kB dirty:404kB writeback:0kB shmem:664kB writeback_tmp:0kB kernel_stack:1352kB pagetables:740kB all_unreclaimable? no
DMA free:267900kB min:2488kB low:3108kB high:3728kB reserved_highatomic:4096KB active_anon:0kB inactive_anon:0kB active_file:4016kB inactive_file:4224kB unevictable:0kB writepending:76kB present:524288kB managed:389432kB mlocked:0kB bounce:0kB free_pcp:2480kB local_pcp:1176kB free_cma:0kB
lowmem_reserve[]: 0 0 1536 1536
HighMem free:1485036kB min:512kB low:3032kB high:5552kB reserved_highatomic:0KB active_anon:136kB inactive_anon:17612kB active_file:9976kB inactive_file:37912kB unevictable:0kB writepending:364kB present:1572864kB managed:1572864kB mlocked:0kB bounce:0kB free_pcp:1776kB local_pcp:404kB free_cma:0kB
BTRFS: selftest: sectorsize: 4096 nodesize: 8192
lowmem_reserve[]: 0 0 0 0
BTRFS: selftest: running btrfs free space cache tests
DMA: 283*4kB (UMH) 282*8kB (UMH) 242*16kB (UMEH) 422*32kB (UMH) 187*64kB (UMH) 139*128kB (UME) 118*256kB (UM) 87*512kB (UME) 61*1024kB (UME) 27*2048kB (U) 6*4096kB (U) = 267612kB
BTRFS: selftest: running extent only tests
HighMem: 1*4kB (M) 1*8kB (M) 92*16kB (M) 43*32kB (UM) 21*64kB (M) 7*128kB (M) 3*256kB (UM) 1*512kB (U) 2*1024kB (UM) 1*2048kB (U) 360*4096kB (UM) = 1485036kB
BTRFS: selftest: running bitmap only tests
14218 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 8388604kB
Total swap = 8388604kB
524288 pages RAM
393216 pages HighMem/MovableOnly
33714 pages reserved
Add __GFP_NOWARN flag to first allocation so that no warning appears
when it fails.
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Fixes: 2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/module.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index ed04a3ba66fe..40a583e9d3c7 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -90,16 +90,17 @@ int module_finalize(const Elf_Ehdr *hdr,
}
static __always_inline void *
-__module_alloc(unsigned long size, unsigned long start, unsigned long end)
+__module_alloc(unsigned long size, unsigned long start, unsigned long end, bool nowarn)
{
pgprot_t prot = strict_module_rwx_enabled() ? PAGE_KERNEL : PAGE_KERNEL_EXEC;
+ gfp_t gfp = GFP_KERNEL | (nowarn ? __GFP_NOWARN : 0);
/*
* Don't do huge page allocations for modules yet until more testing
* is done. STRICT_MODULE_RWX may require extra work to support this
* too.
*/
- return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL, prot,
+ return __vmalloc_node_range(size, 1, start, end, gfp, prot,
VM_FLUSH_RESET_PERMS | VM_NO_HUGE_VMAP,
NUMA_NO_NODE, __builtin_return_address(0));
}
@@ -114,13 +115,13 @@ void *module_alloc(unsigned long size)
/* First try within 32M limit from _etext to avoid branch trampolines */
if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
- ptr = __module_alloc(size, limit, MODULES_END);
+ ptr = __module_alloc(size, limit, MODULES_END, true);
if (!ptr)
- ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
+ ptr = __module_alloc(size, MODULES_VADDR, MODULES_END, false);
return ptr;
#else
- return __module_alloc(size, VMALLOC_START, VMALLOC_END);
+ return __module_alloc(size, VMALLOC_START, VMALLOC_END, false);
#endif
}
--
2.33.1
^ permalink raw reply related
* Re: [RFC PATCH 0/3] Use pageblock_order for cma and alloc_contig_range alignment.
From: Mel Gorman @ 2021-11-30 10:08 UTC (permalink / raw)
To: Vlastimil Babka
Cc: David Hildenbrand, linuxppc-dev, linux-kernel, virtualization,
linux-mm, iommu, Zi Yan, Robin Murphy, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <1c67bb96-24db-f5a6-7520-3d97e54e5192@suse.cz>
On Tue, Nov 30, 2021 at 10:11:36AM +0100, Vlastimil Babka wrote:
> >>> I find that two pageblocks with different migratetypes, like MIGRATE_RECLAIMABLE
> >>> and MIGRATE_MOVABLE can be merged into a single free page after I checked
> >>> __free_one_page() in detail and printed pageblock information during buddy page
> >>> merging.
> >>
> >> Yes, that can happen.
> >>
> >> I am not sure what consequence it will cause. Do you have any idea?
> >>
> >> For MIGRATE_RECLAIMABLE or MIGRATE_MOVABLE or even MIGRATE_UNMOVABLE it's
> >> absolutely fine. As long as these pageblocks are fully free (and they are if
> >> it's a single free page spanning 2 pageblocks), they can be of any of these
> >> type, as they can be reused as needed without causing fragmentation.
> >>
> >> But in case of MIGRATE_CMA and MIGRATE_ISOLATE, uncontrolled merging would
> >> break the specifics of those types. That's why the code is careful for
> >> MIGRATE_ISOLATE, and MIGRATE_CMA was until now done in MAX_ORDER granularity.
> >
> > Thanks for the explanation. Basically migratetypes that can fall back to each
> > other can be merged into a single free page, right?
>
> Yes.
>
> > How about MIGRATE_HIGHATOMIC? It should not be merged with other migratetypes
> > from my understanding.
>
> Hmm it shouldn't minimally because it has an accounting that would become
> broken. So it should prevent merging or make sure the reservations are with
> MAX_ORDER granularity, but seems that neither is true? CCing Mel.
>
MIGRATE_HIGHATOMIC pageblocks can have pages allocated of different
types, particularly UNMOVABLE and potentially RECLAIMABLE. The
reserving or releasing MIGRATE_HIGHATOMIC pageblocks should be done with
reserve_highatomic_pageblock and unreserve_highatomic_pageblock to get
the accounting right.
However, there does not appear to be any special protection against a
page in a highatomic pageblock getting merged with a buddy of another
pageblock type. The pageblock would still have the right setting but on
allocation, the pages could split to the wrong free list and be lost
until the pages belonging to MIGRATE_HIGHATOMIC were freed again.
Not sure how much of a problem that is in practice, it's been a while
since I've heard of high-order atomic allocation failures.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* [PATCH] powerpc: unrecoverable system reset crash fix
From: Nicholas Piggin @ 2021-11-30 10:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
When the system reset interrupt (0x100 trap) calls die(), it does not
exit so it returns. Unrecoverable system reset cases don't expect this,
so it continues on and ends up going BUG later.
Change the 0x100 logic in die to just avoid kexec/fadump. Then a 0
signr can be used by a caller to avoid the exit/panic, which the main
0x100 die() call can use. The unrecoverable die() calls then exit and
don't return, as expected.
Fixes: d40b6768e45b ("powerpc/64s: sreset panic if there is no debugger or crash dump handlers")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/traps.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 11741703d26e..94b842d659ab 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -219,15 +219,15 @@ static void oops_end(unsigned long flags, struct pt_regs *regs,
raw_local_irq_restore(flags);
/*
- * system_reset_excption handles debugger, crash dump, panic, for 0x100
+ * When system_reset_exception sets signr==0, it does not want crash
+ * dump code to be called (it has already handled it).
*/
- if (TRAP(regs) == INTERRUPT_SYSTEM_RESET)
- return;
-
- crash_fadump(regs, "die oops");
+ if (!(TRAP(regs) == INTERRUPT_SYSTEM_RESET && signr == 0)) {
+ crash_fadump(regs, "die oops");
- if (kexec_should_crash(current))
- crash_kexec(regs);
+ if (kexec_should_crash(current))
+ crash_kexec(regs);
+ }
if (!signr)
return;
@@ -287,7 +287,8 @@ void die(const char *str, struct pt_regs *regs, long err)
unsigned long flags;
/*
- * system_reset_excption handles debugger, crash dump, panic, for 0x100
+ * When system_reset_exception calls die, it does not want the
+ * debugger to be invoked (it has already handled it).
*/
if (TRAP(regs) != INTERRUPT_SYSTEM_RESET) {
if (debugger(regs))
@@ -462,8 +463,19 @@ DEFINE_INTERRUPT_HANDLER_NMI(system_reset_exception)
/* See if any machine dependent calls */
if (ppc_md.system_reset_exception) {
- if (ppc_md.system_reset_exception(regs))
- goto out;
+ if (ppc_md.system_reset_exception(regs)) {
+ /*
+ * If this is unrecoverable, it will miss calling
+ * the debugger due to the TRAP=0x100 logic in die(),
+ * do it here.
+ */
+ if (regs_is_unrecoverable(regs)) {
+ if (debugger(regs))
+ goto out;
+ } else {
+ goto out;
+ }
+ }
}
if (debugger(regs))
@@ -488,9 +500,10 @@ DEFINE_INTERRUPT_HANDLER_NMI(system_reset_exception)
/*
* No debugger or crash dump registered, print logs then
- * panic.
+ * panic. Pass 0 in the err argument to prevent the debugger
+ * being invoked again, and to prevent die() from crashing.
*/
- die("System Reset", regs, SIGABRT);
+ die("System Reset", regs, 0);
mdelay(2*MSEC_PER_SEC); /* Wait a little while for others to print */
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries/vas: Don't print an error when VAS is unavailable
From: Michael Ellerman @ 2021-11-30 11:21 UTC (permalink / raw)
To: Haren Myneni, Nicholas Piggin, Cédric Le Goater,
linuxppc-dev
In-Reply-To: <200d69c3f168f84bd8165935ad778c49bf8b83ff.camel@linux.ibm.com>
Haren Myneni <haren@linux.ibm.com> writes:
> On Tue, 2021-11-30 at 10:25 +1100, Michael Ellerman wrote:
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> > Excerpts from Cédric Le Goater's message of November 26, 2021 5:13
>> > pm:
>> > > On 11/26/21 06:21, Nicholas Piggin wrote:
>> > > > KVM does not support VAS so guests always print a useless error
>> > > > on boot
>> > > >
>> > > > vas: HCALL(398) error -2, query_type 0, result buffer
>> > > > 0x57f2000
>> > > >
>> > > > Change this to only print the message if the error is not
>> > > > H_FUNCTION.
>> > >
>> > > Just being curious, why is it even called since "ibm,compression"
>> > > should
>> > > not be exposed in the DT ?
>> >
>> > It looks like vas does not test for it. I guess in theory there can
>> > be
>> > other functions than compression implemented as an accelerator.
>> > Maybe
>> > that's why?
>>
>> Yeah I guess, or it's just not structured that well. The vas platform
>> code is a bit awkward, it's there to support drivers, but it's not
>> actually driver code.
>>
>> I think we can probably rework it so the vas code does nothing until
>> a
>> driver calls in to it.
>>
>> eg. something like below.
>
> Correct, Even though NXGZIP is the only usage right now, VAS is
> accelerator switchboard which should support other coprocessor types
> such as GZIP and 842 or SW type solutions such as fast thread wakeup
> and fast memory copy.
>
> So can we leave VAS initialization separate from drivers and use some
> feature such as FW_FEATURE_LPAR to differentiate from KVM guests?
FW_FEATURE_LPAR is true on KVM guests as well.
As Tyrel pointed out, you should be looking for "hcall-vas" in
"ibm,hypertas-functions" and setting a new FW_FEATURE_VAS based on that.
Then use that to gate the vas init routine.
cheers
^ permalink raw reply
* Re: [PATCH v5 5/5] powerpc/inst: Optimise copy_inst_from_kernel_nofault()
From: Michael Ellerman @ 2021-11-30 11:25 UTC (permalink / raw)
To: Christophe Leroy, kernel test robot, Benjamin Herrenschmidt,
Paul Mackerras, Nick Desaulniers
Cc: linuxppc-dev, llvm, kbuild-all, linux-kernel
In-Reply-To: <e7b67ca6-8cd1-da3c-c0f3-e05f7e592828@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 29/11/2021 à 23:55, kernel test robot a écrit :
>> Hi Christophe,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on powerpc/next]
>> [also build test WARNING on v5.16-rc3 next-20211129]
>> [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]
>>
>> url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-inst-Refactor-___get_user_instr/20211130-015346
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>> config: powerpc-randconfig-r023-20211129 (https://download.01.org/0day-ci/archive/20211130/202111300652.0yDBNvyJ-lkp@intel.com/config)
>> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project df08b2fe8b35cb63dfb3b49738a3494b9b4e6f8e)
>> 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 powerpc cross compiling tool for clang build
>> # apt-get install binutils-powerpc-linux-gnu
>> # https://github.com/0day-ci/linux/commit/fb7bff30cc0efc7e4df1b48bb69de1f325eee826
>> git remote add linux-review https://github.com/0day-ci/linux
>> git fetch --no-tags linux-review Christophe-Leroy/powerpc-inst-Refactor-___get_user_instr/20211130-015346
>> git checkout fb7bff30cc0efc7e4df1b48bb69de1f325eee826
>> # save the config file to linux build tree
>> mkdir build_dir
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=powerpc prepare
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>> All warnings (new ones prefixed by >>):
>>
>> In file included from arch/powerpc/kernel/asm-offsets.c:71:
>> In file included from arch/powerpc/kernel/../xmon/xmon_bpts.h:7:
>>>> arch/powerpc/include/asm/inst.h:165:20: warning: variable 'val' is uninitialized when used here [-Wuninitialized]
>> *inst = ppc_inst(val);
>> ^~~
>> arch/powerpc/include/asm/inst.h:53:22: note: expanded from macro 'ppc_inst'
>> #define ppc_inst(x) (x)
>> ^
>> arch/powerpc/include/asm/inst.h:155:18: note: initialize the variable 'val' to silence this warning
>> unsigned int val, suffix;
>> ^
>> = 0
>
> I can't understand what's wrong here.
>
> We have
>
> __get_kernel_nofault(&val, src, u32, Efault);
> if (IS_ENABLED(CONFIG_PPC64) && get_op(val) == OP_PREFIX) {
> __get_kernel_nofault(&suffix, src + 1, u32, Efault);
> *inst = ppc_inst_prefix(val, suffix);
> } else {
> *inst = ppc_inst(val);
> }
>
> With
>
> #define __get_kernel_nofault(dst, src, type, err_label) \
> __get_user_size_goto(*((type *)(dst)), \
> (__force type __user *)(src), sizeof(type), err_label)
>
>
> And
>
> #define __get_user_size_goto(x, ptr, size, label) \
> do { \
> BUILD_BUG_ON(size > sizeof(x)); \
> switch (size) { \
> case 1: __get_user_asm_goto(x, (u8 __user *)ptr, label, "lbz"); break; \
> case 2: __get_user_asm_goto(x, (u16 __user *)ptr, label, "lhz"); break; \
> case 4: __get_user_asm_goto(x, (u32 __user *)ptr, label, "lwz"); break; \
> case 8: __get_user_asm2_goto(x, (u64 __user *)ptr, label); break; \
> default: x = 0; BUILD_BUG(); \
> } \
> } while (0)
>
> And
>
> #define __get_user_asm_goto(x, addr, label, op) \
> asm_volatile_goto( \
> "1: "op"%U1%X1 %0, %1 # get_user\n" \
> EX_TABLE(1b, %l2) \
> : "=r" (x) \
> : "m<>" (*addr) \
> : \
> : label)
>
>
> I see no possibility, no alternative path where val wouldn't be set. The
> asm clearly has *addr as an output param so it is always set.
I guess clang can't convince itself of that?
>> 1 warning generated.
>> <stdin>:1559:2: warning: syscall futex_waitv not implemented [-W#warnings]
>> #warning syscall futex_waitv not implemented
>> ^
>> 1 warning generated.
>> arch/powerpc/kernel/vdso32/gettimeofday.S:72:8: error: unsupported directive '.stabs'
>> .stabs "_restgpr_31_x:F-1",36,0,0,_restgpr_31_x; .globl _restgpr_31_x; _restgpr_31_x:
>> ^
>> arch/powerpc/kernel/vdso32/gettimeofday.S:73:8: error: unsupported directive '.stabs'
>> .stabs "_rest32gpr_31_x:F-1",36,0,0,_rest32gpr_31_x; .globl _rest32gpr_31_x; _rest32gpr_31_x:
>
> How should we fix that ? Will clang support .stabs in the future ?
I think we should drop any stabs annotations / support. AFAICT none of
the toolchains we support produce it anymore.
cheers
^ permalink raw reply
* Re: [PATCH v5 1/3] powerpc/bitops: Use immediate operand when possible
From: Michael Ellerman @ 2021-11-30 11:40 UTC (permalink / raw)
To: LEROY Christophe
Cc: Paul Mackerras, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4092f4e9-5b2a-a5ca-946b-bb7b92a74f7c@csgroup.eu>
LEROY Christophe <christophe.leroy@csgroup.eu> writes:
> Hi Michael,
>
> Any chance to get this series merged this cycle ?
Yeah. I hesitated a bit at the changes which make the atomic asm even
more complicated, but I guess it's worth it.
cheers
> Le 21/09/2021 à 17:09, Christophe Leroy a écrit :
>> Today we get the following code generation for bitops like
>> set or clear bit:
>>
>> c0009fe0: 39 40 08 00 li r10,2048
>> c0009fe4: 7c e0 40 28 lwarx r7,0,r8
>> c0009fe8: 7c e7 53 78 or r7,r7,r10
>> c0009fec: 7c e0 41 2d stwcx. r7,0,r8
>>
>> c000d568: 39 00 18 00 li r8,6144
>> c000d56c: 7c c0 38 28 lwarx r6,0,r7
>> c000d570: 7c c6 40 78 andc r6,r6,r8
>> c000d574: 7c c0 39 2d stwcx. r6,0,r7
>>
>> Most set bits are constant on lower 16 bits, so it can easily
>> be replaced by the "immediate" version of the operation. Allow
>> GCC to choose between the normal or immediate form.
>>
>> For clear bits, on 32 bits 'rlwinm' can be used instead of 'andc' for
>> when all bits to be cleared are consecutive.
>>
>> On 64 bits we don't have any equivalent single operation for clearing,
>> single bits or a few bits, we'd need two 'rldicl' so it is not
>> worth it, the li/andc sequence is doing the same.
>>
>> With this patch we get:
>>
>> c0009fe0: 7d 00 50 28 lwarx r8,0,r10
>> c0009fe4: 61 08 08 00 ori r8,r8,2048
>> c0009fe8: 7d 00 51 2d stwcx. r8,0,r10
>>
>> c000d558: 7c e0 40 28 lwarx r7,0,r8
>> c000d55c: 54 e7 05 64 rlwinm r7,r7,0,21,18
>> c000d560: 7c e0 41 2d stwcx. r7,0,r8
>>
>> On pmac32_defconfig, it reduces the text by approx 10 kbytes.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
>> ---
>> v5: Fixed the argument of is_rlwinm_mask_valid() in test_and_clear_bits()
>>
>> v4: Rebased
>>
>> v3:
>> - Using the mask validation proposed by Segher
>>
>> v2:
>> - Use "n" instead of "i" as constraint for the rlwinm mask
>> - Improve mask verification to handle more than single bit masks
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> arch/powerpc/include/asm/bitops.h | 89 ++++++++++++++++++++++++++++---
>> 1 file changed, 81 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
>> index 11847b6a244e..a05d8c62cbea 100644
>> --- a/arch/powerpc/include/asm/bitops.h
>> +++ b/arch/powerpc/include/asm/bitops.h
>> @@ -71,19 +71,61 @@ static inline void fn(unsigned long mask, \
>> __asm__ __volatile__ ( \
>> prefix \
>> "1:" PPC_LLARX "%0,0,%3,0\n" \
>> - stringify_in_c(op) "%0,%0,%2\n" \
>> + #op "%I2 %0,%0,%2\n" \
>> PPC_STLCX "%0,0,%3\n" \
>> "bne- 1b\n" \
>> : "=&r" (old), "+m" (*p) \
>> - : "r" (mask), "r" (p) \
>> + : "rK" (mask), "r" (p) \
>> : "cc", "memory"); \
>> }
>>
>> DEFINE_BITOP(set_bits, or, "")
>> -DEFINE_BITOP(clear_bits, andc, "")
>> -DEFINE_BITOP(clear_bits_unlock, andc, PPC_RELEASE_BARRIER)
>> DEFINE_BITOP(change_bits, xor, "")
>>
>> +static __always_inline bool is_rlwinm_mask_valid(unsigned long x)
>> +{
>> + if (!x)
>> + return false;
>> + if (x & 1)
>> + x = ~x; // make the mask non-wrapping
>> + x += x & -x; // adding the low set bit results in at most one bit set
>> +
>> + return !(x & (x - 1));
>> +}
>> +
>> +#define DEFINE_CLROP(fn, prefix) \
>> +static inline void fn(unsigned long mask, volatile unsigned long *_p) \
>> +{ \
>> + unsigned long old; \
>> + unsigned long *p = (unsigned long *)_p; \
>> + \
>> + if (IS_ENABLED(CONFIG_PPC32) && \
>> + __builtin_constant_p(mask) && is_rlwinm_mask_valid(~mask)) {\
>> + asm volatile ( \
>> + prefix \
>> + "1:" "lwarx %0,0,%3\n" \
>> + "rlwinm %0,%0,0,%2\n" \
>> + "stwcx. %0,0,%3\n" \
>> + "bne- 1b\n" \
>> + : "=&r" (old), "+m" (*p) \
>> + : "n" (~mask), "r" (p) \
>> + : "cc", "memory"); \
>> + } else { \
>> + asm volatile ( \
>> + prefix \
>> + "1:" PPC_LLARX "%0,0,%3,0\n" \
>> + "andc %0,%0,%2\n" \
>> + PPC_STLCX "%0,0,%3\n" \
>> + "bne- 1b\n" \
>> + : "=&r" (old), "+m" (*p) \
>> + : "r" (mask), "r" (p) \
>> + : "cc", "memory"); \
>> + } \
>> +}
>> +
>> +DEFINE_CLROP(clear_bits, "")
>> +DEFINE_CLROP(clear_bits_unlock, PPC_RELEASE_BARRIER)
>> +
>> static inline void arch_set_bit(int nr, volatile unsigned long *addr)
>> {
>> set_bits(BIT_MASK(nr), addr + BIT_WORD(nr));
>> @@ -116,12 +158,12 @@ static inline unsigned long fn( \
>> __asm__ __volatile__ ( \
>> prefix \
>> "1:" PPC_LLARX "%0,0,%3,%4\n" \
>> - stringify_in_c(op) "%1,%0,%2\n" \
>> + #op "%I2 %1,%0,%2\n" \
>> PPC_STLCX "%1,0,%3\n" \
>> "bne- 1b\n" \
>> postfix \
>> : "=&r" (old), "=&r" (t) \
>> - : "r" (mask), "r" (p), "i" (IS_ENABLED(CONFIG_PPC64) ? eh : 0) \
>> + : "rK" (mask), "r" (p), "i" (IS_ENABLED(CONFIG_PPC64) ? eh : 0) \
>> : "cc", "memory"); \
>> return (old & mask); \
>> }
>> @@ -130,11 +172,42 @@ DEFINE_TESTOP(test_and_set_bits, or, PPC_ATOMIC_ENTRY_BARRIER,
>> PPC_ATOMIC_EXIT_BARRIER, 0)
>> DEFINE_TESTOP(test_and_set_bits_lock, or, "",
>> PPC_ACQUIRE_BARRIER, 1)
>> -DEFINE_TESTOP(test_and_clear_bits, andc, PPC_ATOMIC_ENTRY_BARRIER,
>> - PPC_ATOMIC_EXIT_BARRIER, 0)
>> DEFINE_TESTOP(test_and_change_bits, xor, PPC_ATOMIC_ENTRY_BARRIER,
>> PPC_ATOMIC_EXIT_BARRIER, 0)
>>
>> +static inline unsigned long test_and_clear_bits(unsigned long mask, volatile unsigned long *_p)
>> +{
>> + unsigned long old, t;
>> + unsigned long *p = (unsigned long *)_p;
>> +
>> + if (IS_ENABLED(CONFIG_PPC32) &&
>> + __builtin_constant_p(mask) && is_rlwinm_mask_valid(~mask)) {
>> + asm volatile (
>> + PPC_ATOMIC_ENTRY_BARRIER
>> + "1:" "lwarx %0,0,%3\n"
>> + "rlwinm %1,%0,0,%2\n"
>> + "stwcx. %1,0,%3\n"
>> + "bne- 1b\n"
>> + PPC_ATOMIC_EXIT_BARRIER
>> + : "=&r" (old), "=&r" (t)
>> + : "n" (~mask), "r" (p)
>> + : "cc", "memory");
>> + } else {
>> + asm volatile (
>> + PPC_ATOMIC_ENTRY_BARRIER
>> + "1:" PPC_LLARX "%0,0,%3,0\n"
>> + "andc %1,%0,%2\n"
>> + PPC_STLCX "%1,0,%3\n"
>> + "bne- 1b\n"
>> + PPC_ATOMIC_EXIT_BARRIER
>> + : "=&r" (old), "=&r" (t)
>> + : "r" (mask), "r" (p)
>> + : "cc", "memory");
>> + }
>> +
>> + return (old & mask);
>> +}
>> +
>> static inline int arch_test_and_set_bit(unsigned long nr,
>> volatile unsigned long *addr)
>> {
>>
^ permalink raw reply
* Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Joakim Tjernlund @ 2021-11-30 11:56 UTC (permalink / raw)
To: regressions@leemhuis.info, leoyang.li@nxp.com,
Eugene_Bordenkircher@selinc.com, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org
In-Reply-To: <MWHPR2201MB15205A333F1F610D332038AC91669@MWHPR2201MB1520.namprd22.prod.outlook.com>
On Mon, 2021-11-29 at 23:48 +0000, Eugene Bordenkircher wrote:
> Agreed,
>
> We are happy pick up the torch on this, but I'd like to try and hear from Joakim first before we do. The patch set is his, so I'd like to give him the opportunity. I think he's the only one that can add a truly proper description as well because he mentioned that this includes a "few more fixes" than just the one we ran into. I'd rather hear from him than try to reverse engineer what was being addressed.
>
> Joakim, if you are still watching the thread, would you like to take a stab at it? If I don't hear from you in a couple days, we'll pick up the torch and do what we can.
>
I am far away from this now and still on 4.19. I don't mind if you tweak tweak the patches for better "upstreamability"
Regards
Joakim
> Eugene T. Bordenkircher
>
> -----Original Message-----
> From: Leo Li <leoyang.li@nxp.com>
> Sent: Monday, November 29, 2021 3:37 PM
> To: Eugene Bordenkircher <Eugene_Bordenkircher@selinc.com>; Thorsten Leemhuis <regressions@leemhuis.info>; jocke@infinera.com <joakim.tjernlund@infinera.com>; linuxppc-dev@lists.ozlabs.org; linux-usb@vger.kernel.org
> Cc: gregkh@linuxfoundation.org; balbi@kernel.org
> Subject: RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
>
> [Caution - External]
>
> > -----Original Message-----
> > From: Eugene Bordenkircher <Eugene_Bordenkircher@selinc.com>
> > Sent: Monday, November 29, 2021 11:25 AM
> > To: Thorsten Leemhuis <regressions@leemhuis.info>; jocke@infinera.com
> > <joakim.tjernlund@infinera.com>; linuxppc-dev@lists.ozlabs.org; linux-
> > usb@vger.kernel.org
> > Cc: Leo Li <leoyang.li@nxp.com>; gregkh@linuxfoundation.org;
> > balbi@kernel.org
> > Subject: RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list
> > leads to unrecoverable loop.
> >
> > The final result of our testing is that the patch set posted seems to
> > address all known defects in the Linux kernel. The mentioned
> > additional problems are entirely caused by the antivirus solution on
> > the windows box. The antivirus solution blocks the disconnect
> > messages from reaching the RNDIS driver so it has no idea the USB
> > device went away. There is nothing we can do to address this in the Linux kernel.
>
> Thanks for the confirmation.
>
> >
> > I propose we move forward with the patchset.
>
> I think that we should proceed to merge the patchset but it seems to need some cleanup for coding style issues and better description before submitted formally.
>
> >
> > Eugene T. Bordenkircher
> >
> > -----Original Message-----
> > From: Thorsten Leemhuis <regressions@leemhuis.info>
> > Sent: Thursday, November 25, 2021 5:59 AM
> > To: Eugene Bordenkircher <Eugene_Bordenkircher@selinc.com>; Thorsten
> > Leemhuis <regressions@leemhuis.info>; Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com>; linuxppc-dev@lists.ozlabs.org; linux-
> > usb@vger.kernel.org
> > Cc: leoyang.li@nxp.com; gregkh@linuxfoundation.org; balbi@kernel.org
> > Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list
> > leads to unrecoverable loop.
> >
> > Hi, this is your Linux kernel regression tracker speaking.
> >
> > Top-posting for once, to make this easy to process for everyone:
> >
> > Li Yang and Felipe Balbi: how to move on with this? It's quite an old
> > regression, but nevertheless it is one and thus should be fixed. Part
> > of my position is to make that happen and thus remind developers and
> > maintainers about this until the regression is resolved.
> >
> > Ciao, Thorsten
> >
> > On 16.11.21 20:11, Eugene Bordenkircher wrote:
> > > On 02.11.21 22:15, Joakim Tjernlund wrote:
> > > > On Sat, 2021-10-30 at 14:20 +0000, Joakim Tjernlund wrote:
> > > > > On Fri, 2021-10-29 at 17:14 +0000, Eugene Bordenkircher wrote:
> > > >
> > > > > > We've discovered a situation where the FSL udc driver
> > (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating
> > over the request queue, but the queue has been corrupted at some point
> > so it loops infinitely. I believe we have narrowed into the offending
> > code, but we are in need of assistance trying to find an appropriate
> > fix for the problem. The identified code appears to be in all
> > versions of the Linux kernel the driver exists in.
> > > > > >
> > > > > > The problem appears to be when handling a USB_REQ_GET_STATUS
> > request. The driver gets this request and then calls the
> > ch9getstatus() function. In this function, it starts a request by
> > "borrowing" the per device status_req, filling it in, and then queuing
> > it with a call to list_add_tail() to add the request to the endpoint
> > queue. Right before it exits the function however, it's calling
> > ep0_prime_status(), which is filling out that same status_req
> > structure and then queuing it with another call to list_add_tail() to
> > add the request to the endpoint queue. This adds two instances of the
> > exact same LIST_HEAD to the endpoint queue, which breaks the list
> > since the prev and next pointers end up pointing to the wrong things.
> > This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ.
> > > > > >
> > > > > > I'm not sure what the appropriate fix to this problem is, mostly
> > > > > > due to
> > my lack of expertise in USB and this driver stack. The code has been
> > this way in the kernel for a very long time, which suggests that it
> > has been working, unless USB_REQ_GET_STATUS requests are never made.
> > This further suggests that there is something else going on that I don't understand.
> > Deleting the call to ep0_prime_status() and the following ep0stall()
> > call appears, on the surface, to get the device working again, but may
> > have side effects that I'm not seeing.
> > > > > >
> > > > > > I'm hopeful someone in the community can help provide some
> > information on what I may be missing or help come up with a solution
> > to the problem. A big thank you to anyone who would like to help out.
> > > > >
> > > > > Run into this to a while ago. Found the bug and a few more fixes.
> > > > > This is against 4.19 so you may have to tweak them a bit.
> > > > > Feel free to upstream them.
> > > >
> > > > Curious, did my patches help? Good to known once we upgrade as well.
> > >
> > > There's good news and bad news.
> > >
> > > The good news is that this appears to stop the driver from entering
> > > an infinite loop, which prevents the Linux system from locking up
> > > and never recovering. So I'm willing to say we've made the behavior
> > > better.
> > >
> > > The bad news is that once we get past this point, there is new bad
> > > behavior. What is on top of this driver in our system is the RNDIS
> > > gadget driver communicating to a Laptop running Win10 -1809.
> > > Everything appears to work fine with the Linux system until there is
> > > a USB disconnect. After the disconnect, the Linux side appears to
> > > continue on just fine, but the Windows side doesn't seem to
> > > recognize the disconnect, which causes the USB driver on that side
> > > to hang forever and eventually blue screen the box. This doesn't happen on
> > > all machines, just a select few. I think we can isolate the
> > > behavior to a specific antivirus/security software driver that is
> > > inserting itself into the USB stack and filtering the disconnect
> > > message, but we're still proving that.
> > >
> > > I'm about 90% certain this is a different problem and we can call
> > > this patchset good, at least for our test setup. My only hesitation
> > > is if the Linux side is sending a set of responses that are
> > > confusing the Windows side (specifically this antivirus) or not.
> > > I'd be content calling that a separate defect though and letting
> > > this one close up with that patchset.
> >
> > P.S.: As a Linux kernel regression tracker I'm getting a lot of
> > reports on my table. I can only look briefly into most of them.
> > Unfortunately therefore I sometimes will get things wrong or miss something important.
> > I hope that's not the case here; if you think it is, don't hesitate to
> > tell me about it in a public reply. That's in everyone's interest, as
> > what I wrote above might be misleading to everyone reading this; any
> > suggestion I gave they thus might sent someone reading this down the
> > wrong rabbit hole, which none of us wants.
> >
> > BTW, I have no personal interest in this issue, which is tracked using
> > regzbot, my Linux kernel regression tracking bot
> > (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Feur01.safelinks.protection.outloo&data=04%7C01%7Cjoakim.tjernlund%40infinera.com%7Cb302ff817a8f4b3184c408d9b392bd1c%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637738265108962168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D2TOGHLaeLnnmbJQG5VEY3CQ66GKtkpBOkFZ16WeW%2F4%3D&reserved=0
> > k.com/?url=https*3A*2F*2Furld__;JSUl!!O7uE89YCNVw!a6nsIMfn544OIzmshw3H
> > bMBVcbwor4cV2Q5OsST7-86jy_YZKvDsN-558Ris4wh8Zawz4puN$
> > efense.com%2Fv3%2F__https%3A%2F%2Flinux-
> > regtracking.leemhuis.info%2Fregzbot%2F__%3B!!O7uE89YCNVw!aHa5_mLM
> > nBeDjINlAtV19tBHm-
> > He9jbusXucMA5h7oonHvNFwYpOHAaaqqewPOuGK9HAzJUz%24&data
> > =04%7C01%7Cleoyang.li%40nxp.com%7C859ce1560a7344729cea08d9b35d2e
> > 67%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6377380350721308
> > 84%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ONQZyAKXNgok
> > 6LgYvnaAL7LVY%2B5Wl7pXglZDqWUJZMc%3D&reserved=0 ). I'm only
> > posting this mail to get things rolling again and hence don't need to
> > be CC on all further activities wrt to this regression.
> >
> > #regzbot title: usb: fsl_udc_core: corrupted request list leads to
> > unrecoverable loop
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox