* Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
From: kajoljain @ 2021-08-16 6:46 UTC (permalink / raw)
To: Christophe Leroy, mpe, linuxppc-dev; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <c6110aa1-90e2-77aa-1ab5-355975037227@csgroup.eu>
On 8/13/21 3:04 PM, Christophe Leroy wrote:
>
>
> Le 13/08/2021 à 10:24, Kajol Jain a écrit :
>> Incase of random sampling, there can be scenarios where SIAR is not
>> latching sample address and results in 0 value. Since current code
>> directly returning the siar value, we could see multiple instruction
>> pointer values as 0 in perf report.
>> Patch resolves this issue by adding a ternary condition to return
>> regs->nip incase SIAR is 0.
>
> Your description seems rather similar to https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c
>
> Does it mean that the problem occurs on more than the power10 DD1 ?
>
> In that case, can the solution be common instead of doing something for power10 DD1 and something for others ?
Hi Christophe,
Yes its better to have common check. I will make these updates.
Thanks,
Kajol Jain
>
>>
>> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
>> into perf_read_regs")
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>> ---
>> arch/powerpc/perf/core-book3s.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index 1b464aad29c4..aeecaaf6810f 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
>> else
>> return regs->nip;
>> } else if (use_siar && siar_valid(regs))
>> - return siar + perf_ip_adjust(regs);
>> + return siar ? siar + perf_ip_adjust(regs) : regs->nip;
>> else if (use_siar)
>> return 0; // no valid instruction pointer
>> else
>>
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
From: kajoljain @ 2021-08-16 6:44 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, linuxppc-dev
Cc: atrajeev, maddy, rnsastry
In-Reply-To: <871r6wmc16.fsf@mpe.ellerman.id.au>
On 8/14/21 6:14 PM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 13/08/2021 à 10:24, Kajol Jain a écrit :
>>> Incase of random sampling, there can be scenarios where SIAR is not
>>> latching sample address and results in 0 value. Since current code
>>> directly returning the siar value, we could see multiple instruction
>>> pointer values as 0 in perf report.
>
> Can you please give more detail on that? What scenarios? On what CPUs?
>
Hi Michael,
Sure I will update these details in my next patch-set.
>>> Patch resolves this issue by adding a ternary condition to return
>>> regs->nip incase SIAR is 0.
>>
>> Your description seems rather similar to
>> https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c
>>
>> Does it mean that the problem occurs on more than the power10 DD1 ?
>>
>> In that case, can the solution be common instead of doing something for power10 DD1 and something
>> for others ?
>
> Agreed.
>
> This change would seem to make that P10 DD1 logic superfluous.
>
> Also we already have a fallback to regs->nip in the else case of the if,
> so we should just use that rather than adding a ternary condition.
>
> eg.
>
> if (use_siar && siar_valid(regs) && siar)
> return siar + perf_ip_adjust(regs);
> else if (use_siar)
> return 0; // no valid instruction pointer
> else
> return regs->nip;
>
>
> I'm also not sure why we have that return 0 case, I can't think of why
> we'd ever want to do that rather than using nip. So maybe we should do
> another patch to drop that case.
Yeah make sense. I will remove return 0 case in my next version.
Thanks,
Kajol Jain
>
> cheers
>
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/perf: Use stack siar instead of mfspr
From: kajoljain @ 2021-08-16 5:58 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, linuxppc-dev
Cc: atrajeev, maddy, rnsastry
In-Reply-To: <8735rcmcni.fsf@mpe.ellerman.id.au>
On 8/14/21 6:00 PM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 13/08/2021 à 10:29, kajoljain a écrit :
>>>
>>> On 8/13/21 1:54 PM, Kajol Jain wrote:
>>>> Minor optimization in the 'perf_instruction_pointer' function code by
>>>> making use of stack siar instead of mfspr.
>>>>
>>>> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
>>>> into perf_read_regs")
>>>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>>>
>>> Please ignore this patch-set as I mentioned wrong version number. I will resend
>>> this patch-set again with correct version. Sorry for the confusion.
>>
>> I fear you are creating even more confusion by sending a v1 after sending a v2 ...
>
> Yeah in future just reply to the v2 saying "oops I sent v2 instead of
> v1" and leave it at that.
Hi Christophe/Michael,
Sure I will take care next time.
Thanks,
Kajol Jain
>
> cheers
>
^ permalink raw reply
* [PATCH] powerpc/pseries: Fix build error when NUMA=n
From: Michael Ellerman @ 2021-08-16 4:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ldufour
As reported by lkp, if NUMA=n we see a build error:
arch/powerpc/platforms/pseries/hotplug-cpu.c: In function 'pseries_cpu_hotplug_init':
arch/powerpc/platforms/pseries/hotplug-cpu.c:1022:8: error: 'node_to_cpumask_map' undeclared
1022 | node_to_cpumask_map[node]);
Use cpumask_of_node() which has an empty stub for NUMA=n, and when
NUMA=y does a lookup from node_to_cpumask_map[].
Fixes: bd1dd4c5f528 ("powerpc/pseries: Prevent free CPU ids being reused on another node")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 1ef40ef699a6..d646c22e94ab 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -1021,7 +1021,7 @@ static int __init pseries_cpu_hotplug_init(void)
/* Record ids of CPU added at boot time */
cpumask_or(node_recorded_ids_map[node],
node_recorded_ids_map[node],
- node_to_cpumask_map[node]);
+ cpumask_of_node(node));
}
of_reconfig_notifier_register(&pseries_smp_nb);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] crypto: DRBG - select SHA512
From: Herbert Xu @ 2021-08-16 2:44 UTC (permalink / raw)
To: Christophe Leroy
Cc: sachinp, Stephan Mueller, lkml, Borislav Petkov, linux-crypto,
linuxppc-dev
In-Reply-To: <20210816044514.Horde.WAvjInneMUMGu0ryEZHgrQ8@messagerie.c-s.fr>
On Mon, Aug 16, 2021 at 04:45:14AM +0200, Christophe Leroy wrote:
>
> The fixes tag has a problem it seems. Should be corrected before pushing.
It's too late for that. This commit is at the base of many other
subsequent changes.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: DRBG - select SHA512
From: Christophe Leroy @ 2021-08-16 2:45 UTC (permalink / raw)
To: Herbert Xu
Cc: sachinp, Stephan Mueller, lkml, Borislav Petkov, linux-crypto,
linuxppc-dev
In-Reply-To: <20210816020735.GA10021@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> a écrit :
> On Sat, Aug 14, 2021 at 06:23:26PM +0200, Borislav Petkov wrote:
>> On Fri, Jul 16, 2021 at 04:14:12PM +0800, Herbert Xu wrote:
>> > Stephan Mueller <smueller@chronox.de> wrote:
>> > > With the swtich to use HMAC(SHA-512) as the default DRBG type, the
>> > > configuration must now also select SHA-512.
>> > >
>> > > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG
>> as default
>> > > DRBG"
>> > > Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
>> > > Signed-off-by: Stephan Mueller <smueller@chronox.com>
>> > > ---
>> > > crypto/Kconfig | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > Patch applied. Thanks.
>>
>> Is that patch going to Linus anytime soon?
>>
>> I still see it on latest rc5+:
>
> I'll push it up this week.
The fixes tag has a problem it seems. Should be corrected before pushing.
Christophe
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: DRBG - select SHA512
From: Herbert Xu @ 2021-08-16 2:07 UTC (permalink / raw)
To: Borislav Petkov
Cc: Stephan Mueller, sachinp, linuxppc-dev, linux-crypto, lkml
In-Reply-To: <YRft/tuKE6MjHhY7@zn.tnic>
On Sat, Aug 14, 2021 at 06:23:26PM +0200, Borislav Petkov wrote:
> On Fri, Jul 16, 2021 at 04:14:12PM +0800, Herbert Xu wrote:
> > Stephan Mueller <smueller@chronox.de> wrote:
> > > With the swtich to use HMAC(SHA-512) as the default DRBG type, the
> > > configuration must now also select SHA-512.
> > >
> > > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default
> > > DRBG"
> > > Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> > > Signed-off-by: Stephan Mueller <smueller@chronox.com>
> > > ---
> > > crypto/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Patch applied. Thanks.
>
> Is that patch going to Linus anytime soon?
>
> I still see it on latest rc5+:
I'll push it up this week.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 0355785313e2191be4e1108cdbda94ddb0238c48
From: kernel test robot @ 2021-08-16 2:04 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: 0355785313e2191be4e1108cdbda94ddb0238c48 powerpc: Add "-z notext" flag to disable diagnostic
elapsed time: 722m
configs tested: 176
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
arm allyesconfig
arm allmodconfig
arm64 defconfig
i386 randconfig-c001-20210816
i386 randconfig-c001-20210815
nios2 3c120_defconfig
sh landisk_defconfig
sh se7712_defconfig
arm trizeps4_defconfig
mips fuloong2e_defconfig
powerpc asp8347_defconfig
arm rpc_defconfig
xtensa common_defconfig
arm jornada720_defconfig
sh secureedge5410_defconfig
powerpc tqm8540_defconfig
arm neponset_defconfig
powerpc stx_gp3_defconfig
nios2 10m50_defconfig
powerpc klondike_defconfig
mips malta_qemu_32r6_defconfig
arm mini2440_defconfig
arc alldefconfig
h8300 edosk2674_defconfig
arm moxart_defconfig
arm ixp4xx_defconfig
mips bcm63xx_defconfig
arm colibri_pxa300_defconfig
sh kfr2r09-romimage_defconfig
arm viper_defconfig
arm s3c6400_defconfig
parisc generic-32bit_defconfig
sh se7343_defconfig
arm tegra_defconfig
h8300 defconfig
powerpc tqm5200_defconfig
powerpc walnut_defconfig
mips bmips_stb_defconfig
sh se7619_defconfig
arm orion5x_defconfig
sh r7785rp_defconfig
m68k m5275evb_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc mpc834x_itxgp_defconfig
arm lubbock_defconfig
arm magician_defconfig
powerpc mpc837x_rdb_defconfig
m68k hp300_defconfig
mips ar7_defconfig
i386 defconfig
openrisc or1ksim_defconfig
powerpc pq2fads_defconfig
sh espt_defconfig
arm milbeaut_m10v_defconfig
mips gpr_defconfig
powerpc mpc5200_defconfig
i386 alldefconfig
powerpc mpc832x_rdb_defconfig
arm spear6xx_defconfig
sparc sparc64_defconfig
sh polaris_defconfig
powerpc amigaone_defconfig
powerpc mpc83xx_defconfig
sh lboxre2_defconfig
arm shannon_defconfig
mips workpad_defconfig
m68k mvme16x_defconfig
arm badge4_defconfig
sh se7705_defconfig
mips bigsur_defconfig
mips pic32mzda_defconfig
powerpc rainier_defconfig
arm hisi_defconfig
powerpc bamboo_defconfig
csky alldefconfig
alpha defconfig
arm collie_defconfig
arm pxa_defconfig
m68k atari_defconfig
arm pxa910_defconfig
powerpc mpc85xx_cds_defconfig
powerpc mgcoge_defconfig
sh j2_defconfig
ia64 gensparse_defconfig
powerpc ksi8560_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20210815
i386 randconfig-a001-20210815
i386 randconfig-a002-20210815
i386 randconfig-a003-20210815
i386 randconfig-a006-20210815
i386 randconfig-a005-20210815
i386 randconfig-a004-20210816
i386 randconfig-a003-20210816
i386 randconfig-a002-20210816
i386 randconfig-a001-20210816
i386 randconfig-a006-20210816
i386 randconfig-a005-20210816
x86_64 randconfig-a013-20210815
x86_64 randconfig-a011-20210815
x86_64 randconfig-a016-20210815
x86_64 randconfig-a012-20210815
x86_64 randconfig-a014-20210815
x86_64 randconfig-a015-20210815
i386 randconfig-a011-20210815
i386 randconfig-a015-20210815
i386 randconfig-a014-20210815
i386 randconfig-a013-20210815
i386 randconfig-a016-20210815
i386 randconfig-a012-20210815
i386 randconfig-a011-20210816
i386 randconfig-a015-20210816
i386 randconfig-a013-20210816
i386 randconfig-a014-20210816
i386 randconfig-a016-20210816
i386 randconfig-a012-20210816
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 kexec
clang tested configs:
x86_64 randconfig-c001-20210815
x86_64 randconfig-a004-20210815
x86_64 randconfig-a006-20210815
x86_64 randconfig-a003-20210815
x86_64 randconfig-a001-20210815
x86_64 randconfig-a002-20210815
x86_64 randconfig-a005-20210815
x86_64 randconfig-a011-20210816
x86_64 randconfig-a013-20210816
x86_64 randconfig-a016-20210816
x86_64 randconfig-a012-20210816
x86_64 randconfig-a015-20210816
x86_64 randconfig-a014-20210816
---
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 1e688dd2a3d6759d416616ff07afc4bb836c4213
From: kernel test robot @ 2021-08-16 2:04 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: 1e688dd2a3d6759d416616ff07afc4bb836c4213 powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto
elapsed time: 722m
configs tested: 172
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
arm allyesconfig
arm allmodconfig
arm64 defconfig
i386 randconfig-c001-20210816
i386 randconfig-c001-20210815
nios2 3c120_defconfig
sh landisk_defconfig
sh se7712_defconfig
arm trizeps4_defconfig
sh secureedge5410_defconfig
powerpc tqm8540_defconfig
arm neponset_defconfig
powerpc stx_gp3_defconfig
nios2 10m50_defconfig
powerpc klondike_defconfig
mips malta_qemu_32r6_defconfig
arm mini2440_defconfig
arc alldefconfig
h8300 edosk2674_defconfig
arm moxart_defconfig
arm ixp4xx_defconfig
mips bcm63xx_defconfig
arm colibri_pxa300_defconfig
sh kfr2r09-romimage_defconfig
arm viper_defconfig
arm s3c6400_defconfig
parisc generic-32bit_defconfig
sh se7343_defconfig
arm tegra_defconfig
h8300 defconfig
powerpc tqm5200_defconfig
powerpc walnut_defconfig
mips bmips_stb_defconfig
sh se7619_defconfig
arm orion5x_defconfig
sh r7785rp_defconfig
m68k m5275evb_defconfig
xtensa common_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc mpc834x_itxgp_defconfig
arm lubbock_defconfig
arm magician_defconfig
powerpc mpc837x_rdb_defconfig
m68k hp300_defconfig
mips ar7_defconfig
i386 defconfig
openrisc or1ksim_defconfig
powerpc pq2fads_defconfig
sh espt_defconfig
arm milbeaut_m10v_defconfig
mips gpr_defconfig
powerpc mpc5200_defconfig
i386 alldefconfig
powerpc mpc832x_rdb_defconfig
arm spear6xx_defconfig
sparc sparc64_defconfig
sh polaris_defconfig
powerpc amigaone_defconfig
powerpc mpc83xx_defconfig
sh lboxre2_defconfig
arm shannon_defconfig
mips workpad_defconfig
m68k mvme16x_defconfig
arm badge4_defconfig
sh se7705_defconfig
mips bigsur_defconfig
mips pic32mzda_defconfig
powerpc rainier_defconfig
arm hisi_defconfig
powerpc bamboo_defconfig
csky alldefconfig
alpha defconfig
arm collie_defconfig
arm pxa_defconfig
m68k atari_defconfig
arm pxa910_defconfig
powerpc mpc85xx_cds_defconfig
powerpc mgcoge_defconfig
sh j2_defconfig
ia64 gensparse_defconfig
powerpc ksi8560_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20210815
i386 randconfig-a001-20210815
i386 randconfig-a002-20210815
i386 randconfig-a003-20210815
i386 randconfig-a006-20210815
i386 randconfig-a005-20210815
i386 randconfig-a004-20210816
i386 randconfig-a003-20210816
i386 randconfig-a002-20210816
i386 randconfig-a001-20210816
i386 randconfig-a006-20210816
i386 randconfig-a005-20210816
x86_64 randconfig-a013-20210815
x86_64 randconfig-a011-20210815
x86_64 randconfig-a016-20210815
x86_64 randconfig-a012-20210815
x86_64 randconfig-a014-20210815
x86_64 randconfig-a015-20210815
i386 randconfig-a011-20210815
i386 randconfig-a015-20210815
i386 randconfig-a014-20210815
i386 randconfig-a013-20210815
i386 randconfig-a016-20210815
i386 randconfig-a012-20210815
i386 randconfig-a011-20210816
i386 randconfig-a015-20210816
i386 randconfig-a013-20210816
i386 randconfig-a014-20210816
i386 randconfig-a016-20210816
i386 randconfig-a012-20210816
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 kexec
clang tested configs:
x86_64 randconfig-c001-20210815
x86_64 randconfig-a004-20210815
x86_64 randconfig-a006-20210815
x86_64 randconfig-a003-20210815
x86_64 randconfig-a001-20210815
x86_64 randconfig-a002-20210815
x86_64 randconfig-a005-20210815
x86_64 randconfig-a011-20210816
x86_64 randconfig-a013-20210816
x86_64 randconfig-a016-20210816
x86_64 randconfig-a012-20210816
x86_64 randconfig-a015-20210816
x86_64 randconfig-a014-20210816
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* linux-next: manual merge of the powerpc tree with Linus' tree
From: Stephen Rothwell @ 2021-08-15 22:27 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Cédric Le Goater,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/sysdev/xive/common.c
between commit:
cbc06f051c52 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs")
from Linus' tree and commit:
17df41fec5b8 ("powerpc: use IRQF_NO_DEBUG for IPIs")
from the powerpc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/sysdev/xive/common.c
index 943fd30095af,458645c7a72b..000000000000
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@@ -1170,22 -1166,6 +1157,22 @@@ out
return ret;
}
+static int __init xive_request_ipi(unsigned int cpu)
+{
+ struct xive_ipi_desc *xid = &xive_ipis[early_cpu_to_node(cpu)];
+ int ret;
+
+ if (atomic_inc_return(&xid->started) > 1)
+ return 0;
+
+ ret = request_irq(xid->irq, xive_muxed_ipi_action,
- IRQF_PERCPU | IRQF_NO_THREAD,
++ IRQF_NO_DEBUG | IRQF_PERCPU | IRQF_NO_THREAD,
+ xid->name, NULL);
+
+ WARN(ret < 0, "Failed to request IPI %d: %d\n", xid->irq, ret);
+ return ret;
+}
+
static int xive_setup_cpu_ipi(unsigned int cpu)
{
unsigned int xive_ipi_irq = xive_ipi_cpu_to_irq(cpu);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] powerpc/head_check: use stdout for error messages
From: Randy Dunlap @ 2021-08-15 22:23 UTC (permalink / raw)
To: linux-kernel
Cc: Chen, Rong A, Randy Dunlap, Nicholas Piggin, Paul Mackerras,
linuxppc-dev
Prefer stderr instead of stdout for error messages.
This is a good practice and can help CI error detecting and
reporting (0day in this case).
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: "Chen, Rong A" <rong.a.chen@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/tools/head_check.sh | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-next-20210813.orig/arch/powerpc/tools/head_check.sh
+++ linux-next-20210813/arch/powerpc/tools/head_check.sh
@@ -56,9 +56,9 @@ expected_start_head_addr=$vma
start_head_addr=$(cat .tmp_symbols.txt | grep " t start_first_256B$" | cut -d' ' -f1)
if [ "$start_head_addr" != "$expected_start_head_addr" ]; then
- echo "ERROR: head code starts at $start_head_addr, should be $expected_start_head_addr"
- echo "ERROR: try to enable LD_HEAD_STUB_CATCH config option"
- echo "ERROR: see comments in arch/powerpc/tools/head_check.sh"
+ echo "ERROR: head code starts at $start_head_addr, should be $expected_start_head_addr" 1>&2
+ echo "ERROR: try to enable LD_HEAD_STUB_CATCH config option" 1>&2
+ echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
exit 1
fi
@@ -70,9 +70,9 @@ expected_start_text_addr=$(cat .tmp_symb
start_text_addr=$(cat .tmp_symbols.txt | grep " t start_text$" | cut -d' ' -f1)
if [ "$start_text_addr" != "$expected_start_text_addr" ]; then
- echo "ERROR: start_text address is $start_text_addr, should be $expected_start_text_addr"
- echo "ERROR: try to enable LD_HEAD_STUB_CATCH config option"
- echo "ERROR: see comments in arch/powerpc/tools/head_check.sh"
+ echo "ERROR: start_text address is $start_text_addr, should be $expected_start_text_addr" 1>&2
+ echo "ERROR: try to enable LD_HEAD_STUB_CATCH config option" 1>&2
+ echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
exit 1
fi
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.14-5 tag
From: pr-tracker-bot @ 2021-08-15 17:00 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linus Torvalds, linux-kernel, clg, pulehui, ldufour, linuxppc-dev
In-Reply-To: <87tujqlvpo.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 15 Aug 2021 22:48:51 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.14-5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ecf93431963a95c0f475921101bedc0dd62ec96d
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()
From: Borislav Petkov @ 2021-08-15 14:39 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
linux-s390, Andi Kleen, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Joerg Roedel, Tianyu Lan,
Andy Lutomirski, Thomas Gleixner, kexec, linux-kernel, iommu,
linux-fsdevel, linuxppc-dev
In-Reply-To: <4710eb91-d054-7b31-5106-09e3e54bba9e@amd.com>
On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote:
> It's not a cross-vendor thing as opposed to a KVM or other hypervisor
> thing where the family doesn't have to be reported as AMD or HYGON.
What would be the use case? A HV starts a guest which is supposed to be
encrypted using the AMD's confidential guest technology but the HV tells
the guest that it is not running on an AMD SVM HV but something else?
Is that even an actual use case?
Or am I way off?
I know we have talked about this in the past but this still sounds
insane.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()
From: Tom Lendacky @ 2021-08-15 13:53 UTC (permalink / raw)
To: Borislav Petkov
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
linux-s390, Andi Kleen, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Joerg Roedel, Tianyu Lan,
Andy Lutomirski, Thomas Gleixner, kexec, linux-kernel, iommu,
linux-fsdevel, linuxppc-dev
In-Reply-To: <YRgUxyhoqVJ0Kxvt@zn.tnic>
On 8/14/21 2:08 PM, Borislav Petkov wrote:
> On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
>> diff --git a/arch/x86/include/asm/protected_guest.h b/arch/x86/include/asm/protected_guest.h
>> new file mode 100644
>> index 000000000000..51e4eefd9542
>> --- /dev/null
>> +++ b/arch/x86/include/asm/protected_guest.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Protected Guest (and Host) Capability checks
>> + *
>> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
>> + *
>> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
>> + */
>> +
>> +#ifndef _X86_PROTECTED_GUEST_H
>> +#define _X86_PROTECTED_GUEST_H
>> +
>> +#include <linux/mem_encrypt.h>
>> +
>> +#ifndef __ASSEMBLY__
>> +
>> +static inline bool prot_guest_has(unsigned int attr)
>> +{
>> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>> + if (sme_me_mask)
>> + return amd_prot_guest_has(attr);
>> +#endif
>> +
>> + return false;
>> +}
>> +
>> +#endif /* __ASSEMBLY__ */
>> +
>> +#endif /* _X86_PROTECTED_GUEST_H */
>
> I think this can be simplified more, diff ontop below:
>
> - no need for the ifdeffery as amd_prot_guest_has() has versions for
> both when CONFIG_AMD_MEM_ENCRYPT is set or not.
Ugh, yeah, not sure why I put that in for this version since I have the
static inline for when CONFIG_AMD_MEM_ENCRYPT is not set.
>
> - the sme_me_mask check is pushed there too.
>
> - and since this is vendor-specific, I'm checking the vendor bit. Yeah,
> yeah, cross-vendor but I don't really believe that.
It's not a cross-vendor thing as opposed to a KVM or other hypervisor
thing where the family doesn't have to be reported as AMD or HYGON. That's
why I made the if check be for sme_me_mask. I think that is the safer way
to go.
Thanks,
Tom
>
> ---
> diff --git a/arch/x86/include/asm/protected_guest.h b/arch/x86/include/asm/protected_guest.h
> index 51e4eefd9542..8541c76d5da4 100644
> --- a/arch/x86/include/asm/protected_guest.h
> +++ b/arch/x86/include/asm/protected_guest.h
> @@ -12,18 +12,13 @@
>
> #include <linux/mem_encrypt.h>
>
> -#ifndef __ASSEMBLY__
> -
> static inline bool prot_guest_has(unsigned int attr)
> {
> -#ifdef CONFIG_AMD_MEM_ENCRYPT
> - if (sme_me_mask)
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> return amd_prot_guest_has(attr);
> -#endif
>
> return false;
> }
>
> -#endif /* __ASSEMBLY__ */
> -
> #endif /* _X86_PROTECTED_GUEST_H */
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index edc67ddf065d..5a0442a6f072 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -392,6 +392,9 @@ bool noinstr sev_es_active(void)
>
> bool amd_prot_guest_has(unsigned int attr)
> {
> + if (!sme_me_mask)
> + return false;
> +
> switch (attr) {
> case PATTR_MEM_ENCRYPT:
> return sme_me_mask != 0;
>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.14-5 tag
From: Michael Ellerman @ 2021-08-15 12:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, clg, pulehui, ldufour, linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.14:
The following changes since commit a88603f4b92ecef9e2359e40bcb99ad399d85dd7:
powerpc/vdso: Don't use r30 to avoid breaking Go lang (2021-07-29 23:13:12 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.14-5
for you to fetch changes up to cbc06f051c524dcfe52ef0d1f30647828e226d30:
powerpc/xive: Do not skip CPU-less nodes when creating the IPIs (2021-08-12 22:31:41 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.14 #5
- Fix crashes coming out of nap on 32-bit Book3s (eg. powerbooks).
- Fix critical and debug interrupts on BookE, seen as crashes when using ptrace.
- Fix an oops when running an SMP kernel on a UP system.
- Update pseries LPAR security flavor after partition migration.
- Fix an oops when using kprobes on BookE.
- Fix oops on 32-bit pmac by not calling do_IRQ() from timer_interrupt().
- Fix softlockups on CPU hotplug into a CPU-less node with xive (P9).
Thanks to: Cédric Le Goater, Christophe Leroy, Finn Thain, Geetika Moolchandani, Laurent
Dufour, Laurent Vivier, Nicholas Piggin, Pu Lehui, Radu Rendec, Srikar Dronamraju, Stan
Johnson.
- ------------------------------------------------------------------
Christophe Leroy (5):
powerpc/32s: Fix napping restore in data storage interrupt (DSI)
powerpc/32: Fix critical and debug interrupts on BOOKE
powerpc/smp: Fix OOPS in topology_init()
powerpc/interrupt: Fix OOPS by not calling do_IRQ() from timer_interrupt()
powerpc/interrupt: Do not call single_step_exception() from other exceptions
Cédric Le Goater (1):
powerpc/xive: Do not skip CPU-less nodes when creating the IPIs
Laurent Dufour (1):
powerpc/pseries: Fix update of LPAR security flavor after LPM
Pu Lehui (1):
powerpc/kprobes: Fix kprobe Oops happens in booke
arch/powerpc/include/asm/interrupt.h | 3 ++
arch/powerpc/include/asm/irq.h | 2 +-
arch/powerpc/include/asm/ptrace.h | 16 +++++++++
arch/powerpc/kernel/asm-offsets.c | 31 ++++++++---------
arch/powerpc/kernel/head_book3s_32.S | 2 +-
arch/powerpc/kernel/head_booke.h | 27 ++-------------
arch/powerpc/kernel/irq.c | 7 +++-
arch/powerpc/kernel/kprobes.c | 3 +-
arch/powerpc/kernel/sysfs.c | 2 +-
arch/powerpc/kernel/time.c | 2 +-
arch/powerpc/kernel/traps.c | 9 +++--
arch/powerpc/platforms/pseries/setup.c | 5 +--
arch/powerpc/sysdev/xive/common.c | 35 ++++++++++++++------
13 files changed, 82 insertions(+), 62 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmEZDQQACgkQUevqPMjh
pYDVNQ//cV/JSIm1THeqbfjZFrx2iO5hcwgO0lXaRK6Lf4gXGAcQAGr6Co+JjsNy
A5vz3myCKHiTlCe7862Dm7X54FKeJKwhQsdzpWVfw8aeQwxdhkc1Wg4WtgKMT3/j
woN6je4+2/I9LctFgnRMqMV1ode4t91jgjX4wGCxqLYQxPtBXgkZ4jwwIvTh5xR8
DmkYr5ZFaHzVX+wHY/58aT4rtej5f88RXVdR1ClCw9APzgPzSP+t/arZm1B7TRGN
PFetXlHtyOzHcsf5OhfHXWJ4tjUxLsuHccPmnJKJsPAnfNP2fUEZv8fqHqJma+bj
YVG8wzCI4/OTdaoEzmgwdyKXsE0g5GSh0V2ok4DEUaRWrWCbSmsKvLLqW9gVn06K
9iLMne+MoxOmUh4z2ZI2PI+Ko31IEOlaRudsdeJGCYAYAqTRrbBdrrUK55Qjozv0
oGccwMZrqyWwlNfyx4kgD03x1N0zITr1/CstAIssfQilnrlrM6n4vWjc3tvMI1R7
Lgl5Ja8UYkLQsOmH5FD0iqEwmjaJgNuc7+Vt93rWvxk1Pk/s8Kx5dEer+/q0tLku
u7QabZMOd3DsVsgU3oNNNUDGA3RbvhlOj3H2J/RoHftmXg2UG0T4MBIVk9r5N+DP
MOgk1GP1zxLQ2B6FazRG3J5W/Ct9gHTMSFUpWGaz313VWp6gpJ4=
=NuwF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto
From: Michael Ellerman @ 2021-08-15 3:49 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <389962b1b702e3c78d169e59bcfac56282889173.1618331882.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 24725e50c7b4..34745f239208 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -926,7 +926,7 @@ static void check_section(const char *modname, struct elf_info *elf,
> ".kprobes.text", ".cpuidle.text", ".noinstr.text"
> #define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
> ".fixup", ".entry.text", ".exception.text", ".text.*", \
> - ".coldtext"
> + ".coldtext .softirqentry.text"
This wasn't working, I updated it to:
".coldtext", ".softirqentry.text"
Which works.
cheers
^ permalink raw reply
* Re: [PATCH] ppc: add "-z notext" flag to disable diagnostic
From: Fāng-ruì Sòng @ 2021-08-14 19:34 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Nick Desaulniers, linux-kernel, Nathan Chancellor,
clang-built-linux, Paul Mackerras, Bill Wendling, linuxppc-dev,
Daniel Axtens
In-Reply-To: <20210814125812.GC1583@gate.crashing.org>
On Sat, Aug 14, 2021 at 5:59 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Fri, Aug 13, 2021 at 01:05:08PM -0700, Fangrui Song wrote:
> > Text relocations are considered very awful by linker developers.
>
> By very few linker developers.
https://groups.google.com/g/generic-abi/c/Ckq19PfLxyk/m/uW29sgkoAgAJ
Ali Bahrami: "My opinion is that no one wants text relocations, but
not labeling them if they do exist doesn't seem right. I find the
presence of DF_TEXTREL very interesting when diagnosing various
issues."
https://gcc.gnu.org/legacy-ml/gcc/2016-04/msg00138.html
( "So why not simply create 'dynamic text relocations' then? Is that
possible with a pure linker change?" )
Cary Coutant: "Ugh. Besides being a bad idea from a performance point
of view, it's not even always possible to do. Depending on the
architecture, a direct reference from an executable to a variable in a
shared library may not have the necessary reach."
binutils-gdb commit "Add linker option: --warn-shared-textrel to
produce warnings when adding a DT_TEXTREL to a shared object."
Nick Clifton
https://www.openwall.com/lists/musl/2020/09/26/3
Szabolcs Nagy: "nice. and gcc passes -z text for static pie code so
that case should not end up with text rels."
Someone wrote "Overall, the overhead of processing text relocations
can cause serious performance degradation." in Solaris' Linker and
Libraries Guide.
Me :)
(I wrote lld/ELF 9.0.0~13.0.0 release notes and filed dozen of GNU
ld/gold bugs/feature requests)
> > binutils 2.35 added --enable-textrel-check={no,warn,error}
> > https://sourceware.org/bugzilla/show_bug.cgi?id=20824
>
> Yes, some people wanted the default to be configurable. So now we have
> a default default that is sane, so most people get to reap the benefits
> of having defaults at all, but we also allow other people to shoot
> themselves (and people who have to deal with them) in the foot.
> "Progress". Changing the defaults should be a one-time event, only done
> when the benefits strongly outweigh the costs. Defaults should never be
> configurable (by the user).
ld.lld has such a non-configurable model and thus caught the issue
(which the patch intends to address).
Future --enable-textrel-check={yes,error} configured GNU ld will be similar.
> > I can imagine that in the future some Linux distributions (especially those
> > focusing on security) will default their binutils to use
> > --enable-textrel-check={no,warn,error}.
>
> How would this be a benefit to security?
https://flameeyes.blog/2016/01/16/textrels-text-relocations-and-their-impact-on-hardening-techniques/
https://github.com/golang/go/issues/9210
Android: "libexample.so has text relocations. This is wasting memory
and prevents security hardening. Please fix."
FWIW I contributed a glibc patch allowing TEXTREL to co-exist with ifunc.
It requires temporary mapping the text segment W^X.
> > In -no-pie links, R_PPC64_ADDR64 relocations are link-time constants.
>
> Where "link" includes dynamic links as well. There are no constants.
"Link-time" usually refers to the processing of the static linker.
Dynamic links can use load-time or run-time.
> > There are no text relocations, therefore no need for -z notext.
>
> This is a choice by the compiler, nothing more. It saves some process
> startup time, and allows slightly more maps to be shared by processes
> that run the same images. But it is a tradeoff, so it might change; and
> of course it is not an ABI requirement.
>
>
> Segher
Text relocations are generally awful.
GNU ld and gold's traditional "add DF_TEXTREL on-demand" behavior made
such user errors easy to make.
I understand that kernels are special applications where we apply
relocations once and many user-space objection can be less of a
concern/ignored.
However, the Linux kernel is already in a position where many linker
options are controlled and thus should specify -z notext to make
the intention explicit, or fix the problems (I think x86-64 is good;
that said, powerpc
has a higher cost using PC-relative instructions so pay the oneshot relocation
time cost probably isn't a bad choice)
--
宋方睿
^ permalink raw reply
* Re: [PATCH v2 03/12] x86/sev: Add an x86 version of prot_guest_has()
From: Borislav Petkov @ 2021-08-14 19:08 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
linux-s390, Andi Kleen, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Joerg Roedel, Tianyu Lan,
Andy Lutomirski, Thomas Gleixner, kexec, linux-kernel, iommu,
linux-fsdevel, linuxppc-dev
In-Reply-To: <7d55bac0cf2e73f53816bce3a3097877ed9663f3.1628873970.git.thomas.lendacky@amd.com>
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/include/asm/protected_guest.h b/arch/x86/include/asm/protected_guest.h
> new file mode 100644
> index 000000000000..51e4eefd9542
> --- /dev/null
> +++ b/arch/x86/include/asm/protected_guest.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Protected Guest (and Host) Capability checks
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
> + */
> +
> +#ifndef _X86_PROTECTED_GUEST_H
> +#define _X86_PROTECTED_GUEST_H
> +
> +#include <linux/mem_encrypt.h>
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline bool prot_guest_has(unsigned int attr)
> +{
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
> + if (sme_me_mask)
> + return amd_prot_guest_has(attr);
> +#endif
> +
> + return false;
> +}
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* _X86_PROTECTED_GUEST_H */
I think this can be simplified more, diff ontop below:
- no need for the ifdeffery as amd_prot_guest_has() has versions for
both when CONFIG_AMD_MEM_ENCRYPT is set or not.
- the sme_me_mask check is pushed there too.
- and since this is vendor-specific, I'm checking the vendor bit. Yeah,
yeah, cross-vendor but I don't really believe that.
---
diff --git a/arch/x86/include/asm/protected_guest.h b/arch/x86/include/asm/protected_guest.h
index 51e4eefd9542..8541c76d5da4 100644
--- a/arch/x86/include/asm/protected_guest.h
+++ b/arch/x86/include/asm/protected_guest.h
@@ -12,18 +12,13 @@
#include <linux/mem_encrypt.h>
-#ifndef __ASSEMBLY__
-
static inline bool prot_guest_has(unsigned int attr)
{
-#ifdef CONFIG_AMD_MEM_ENCRYPT
- if (sme_me_mask)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return amd_prot_guest_has(attr);
-#endif
return false;
}
-#endif /* __ASSEMBLY__ */
-
#endif /* _X86_PROTECTED_GUEST_H */
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index edc67ddf065d..5a0442a6f072 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -392,6 +392,9 @@ bool noinstr sev_es_active(void)
bool amd_prot_guest_has(unsigned int attr)
{
+ if (!sme_me_mask)
+ return false;
+
switch (attr) {
case PATTR_MEM_ENCRYPT:
return sme_me_mask != 0;
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply related
* Re: [PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features
From: Tom Lendacky @ 2021-08-14 18:49 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Joerg Roedel, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, Joerg Roedel, linux-fsdevel, Tianyu Lan, linuxppc-dev
In-Reply-To: <YRgMUHqdH60jDB06@zn.tnic>
On 8/14/21 1:32 PM, Borislav Petkov wrote:
> On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
>> diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
>> new file mode 100644
>> index 000000000000..43d4dde94793
>> --- /dev/null
>> +++ b/include/linux/protected_guest.h
>> @@ -0,0 +1,35 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Protected Guest (and Host) Capability checks
>> + *
>> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
>> + *
>> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
>> + */
>> +
>> +#ifndef _PROTECTED_GUEST_H
>> +#define _PROTECTED_GUEST_H
>> +
>> +#ifndef __ASSEMBLY__
> ^^^^^^^^^^^^^
>
> Do you really need that guard? It builds fine without it too. Or
> something coming later does need it...?
No, I probably did it out of habit. I can remove it in the next version.
Thanks,
Tom
>
^ permalink raw reply
* Re: [PATCH v2 02/12] mm: Introduce a function to check for virtualization protection features
From: Borislav Petkov @ 2021-08-14 18:32 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-s390, Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh,
kvm, Joerg Roedel, x86, kexec, linux-kernel, amd-gfx,
platform-driver-x86, iommu, Andi Kleen, linux-graphics-maintainer,
dri-devel, Joerg Roedel, linux-fsdevel, Tianyu Lan, linuxppc-dev
In-Reply-To: <482fe51f1671c1cd081039801b03db7ec0036332.1628873970.git.thomas.lendacky@amd.com>
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to eliminate having to add multiple technology-specific checks
> to the code (e.g. if (sev_active() || tdx_active())).
>
> Reviewed-by: Joerg Roedel <jroedel@suse.de>
> Co-developed-by: Andi Kleen <ak@linux.intel.com>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> Co-developed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/Kconfig | 3 +++
> include/linux/protected_guest.h | 35 +++++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
> create mode 100644 include/linux/protected_guest.h
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 98db63496bab..bd4f60c581f1 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1231,6 +1231,9 @@ config RELR
> config ARCH_HAS_MEM_ENCRYPT
> bool
>
> +config ARCH_HAS_PROTECTED_GUEST
> + bool
> +
> config HAVE_SPARSE_SYSCALL_NR
> bool
> help
> diff --git a/include/linux/protected_guest.h b/include/linux/protected_guest.h
> new file mode 100644
> index 000000000000..43d4dde94793
> --- /dev/null
> +++ b/include/linux/protected_guest.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Protected Guest (and Host) Capability checks
> + *
> + * Copyright (C) 2021 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
> + */
> +
> +#ifndef _PROTECTED_GUEST_H
> +#define _PROTECTED_GUEST_H
> +
> +#ifndef __ASSEMBLY__
^^^^^^^^^^^^^
Do you really need that guard? It builds fine without it too. Or
something coming later does need it...?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] crypto: DRBG - select SHA512
From: Borislav Petkov @ 2021-08-14 16:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Stephan Mueller, sachinp, linuxppc-dev, linux-crypto, lkml
In-Reply-To: <20210716081411.GA2062@gondor.apana.org.au>
On Fri, Jul 16, 2021 at 04:14:12PM +0800, Herbert Xu wrote:
> Stephan Mueller <smueller@chronox.de> wrote:
> > With the swtich to use HMAC(SHA-512) as the default DRBG type, the
> > configuration must now also select SHA-512.
> >
> > Fixes: 9b7b94683a9b "crypto: DRBG - switch to HMAC SHA512 DRBG as default
> > DRBG"
> > Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> > Signed-off-by: Stephan Mueller <smueller@chronox.com>
> > ---
> > crypto/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Patch applied. Thanks.
Is that patch going to Linus anytime soon?
I still see it on latest rc5+:
DRBG: could not allocate digest TFM handle: hmac(sha512)
alg: drbg: Failed to reset rng
alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512
------------[ cut here ]------------
alg: self-tests for drbg_nopr_hmac_sha512 (stdrng) failed (rc=-22)
WARNING: CPU: 3 PID: 76 at crypto/testmgr.c:5652 alg_test.part.0+0x132/0x3c0
Modules linked in:
CPU: 3 PID: 76 Comm: cryptomgr_test Not tainted 5.14.0-rc5+ #1
Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012
RIP: 0010:alg_test.part.0+0x132/0x3c0
Code: c0 74 2e 80 3d 7f 61 ad 02 00 0f 85 c0 64 5f 00 44 89 c1 4c 89 f2 4c 89 ee 44 89 44 24 04 48 c7 c7 f8 0a 11 82 e8 8c 57 5e 00 <0f> 0b 44 8b 44 24 04 48 8b 84 24 98 00 00 00 65 48 2b 04 25 28 00
RSP: 0000:ffffc9000078fe38 EFLAGS: 00010292
RAX: 0000000000000042 RBX: 00000000ffffffff RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffffff810f520f RDI: ffffffff810f520f
RBP: 0000000000000053 R08: 0000000000000001 R09: 0000000000000001
R10: ffff888219df9000 R11: 3fffffffffffffff R12: 0000000000000053
R13: ffff888100c0ee00 R14: ffff888100c0ee80 R15: 00000000000014c0
FS: 0000000000000000(0000) GS:ffff888211f80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000002412001 CR4: 00000000001706e0
Call Trace:
? lock_is_held_type+0xd5/0x130
? find_held_lock+0x2b/0x80
? preempt_count_sub+0x9b/0xd0
? crypto_acomp_scomp_free_ctx+0x30/0x30
cryptomgr_test+0x27/0x50
kthread+0x144/0x170
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
irq event stamp: 411
hardirqs last enabled at (419): [<ffffffff810f6972>] console_unlock+0x332/0x570
hardirqs last disabled at (426): [<ffffffff810f6a1f>] console_unlock+0x3df/0x570
softirqs last enabled at (234): [<ffffffff81c00329>] __do_softirq+0x329/0x496
softirqs last disabled at (151): [<ffffffff8108248d>] irq_exit_rcu+0xdd/0x130
---[ end trace edfdfd51982deb2d ]---
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v2 01/12] x86/ioremap: Selectively build arch override encryption functions
From: Borislav Petkov @ 2021-08-14 15:25 UTC (permalink / raw)
To: Tom Lendacky
Cc: Sathyanarayanan Kuppuswamy, linux-efi, Brijesh Singh, kvm,
Peter Zijlstra, Dave Hansen, dri-devel, platform-driver-x86,
linux-s390, Andi Kleen, Joerg Roedel, x86, amd-gfx, Ingo Molnar,
linux-graphics-maintainer, Tianyu Lan, Andy Lutomirski,
Thomas Gleixner, kexec, linux-kernel, iommu, linux-fsdevel,
linuxppc-dev
In-Reply-To: <a4338245609a6be63b162e3516d3f6614db782a4.1628873970.git.thomas.lendacky@amd.com>
On Fri, Aug 13, 2021 at 11:59:20AM -0500, Tom Lendacky wrote:
> In prep for other uses of the prot_guest_has() function besides AMD's
> memory encryption support, selectively build the AMD memory encryption
> architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These
> functions are:
> - early_memremap_pgprot_adjust()
> - arch_memremap_can_ram_remap()
>
> Additionally, routines that are only invoked by these architecture
> override functions can also be conditionally built. These functions are:
> - memremap_should_map_decrypted()
> - memremap_is_efi_data()
> - memremap_is_setup_data()
> - early_memremap_is_setup_data()
>
> And finally, phys_mem_access_encrypted() is conditionally built as well,
> but requires a static inline version of it when CONFIG_AMD_MEM_ENCRYPT is
> not set.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/include/asm/io.h | 8 ++++++++
> arch/x86/mm/ioremap.c | 2 +-
> 2 files changed, 9 insertions(+), 1 deletion(-)
LGTM.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] ppc: add "-z notext" flag to disable diagnostic
From: Segher Boessenkool @ 2021-08-14 12:58 UTC (permalink / raw)
To: Fangrui Song
Cc: Nick Desaulniers, linux-kernel, Nathan Chancellor,
clang-built-linux, Paul Mackerras, Bill Wendling, linuxppc-dev,
Daniel Axtens
In-Reply-To: <20210813200508.7bqehxgd6ruerds5@google.com>
On Fri, Aug 13, 2021 at 01:05:08PM -0700, Fangrui Song wrote:
> Text relocations are considered very awful by linker developers.
By very few linker developers.
> binutils 2.35 added --enable-textrel-check={no,warn,error}
> https://sourceware.org/bugzilla/show_bug.cgi?id=20824
Yes, some people wanted the default to be configurable. So now we have
a default default that is sane, so most people get to reap the benefits
of having defaults at all, but we also allow other people to shoot
themselves (and people who have to deal with them) in the foot.
"Progress". Changing the defaults should be a one-time event, only done
when the benefits strongly outweigh the costs. Defaults should never be
configurable (by the user).
> I can imagine that in the future some Linux distributions (especially those
> focusing on security) will default their binutils to use
> --enable-textrel-check={no,warn,error}.
How would this be a benefit to security?
> In -no-pie links, R_PPC64_ADDR64 relocations are link-time constants.
Where "link" includes dynamic links as well. There are no constants.
> There are no text relocations, therefore no need for -z notext.
This is a choice by the compiler, nothing more. It saves some process
startup time, and allows slightly more maps to be shared by processes
that run the same images. But it is a tradeoff, so it might change; and
of course it is not an ABI requirement.
Segher
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/perf: Return regs->nip as instruction pointer value when SIAR is 0
From: Michael Ellerman @ 2021-08-14 12:44 UTC (permalink / raw)
To: Christophe Leroy, Kajol Jain, linuxppc-dev; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <c6110aa1-90e2-77aa-1ab5-355975037227@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 13/08/2021 à 10:24, Kajol Jain a écrit :
>> Incase of random sampling, there can be scenarios where SIAR is not
>> latching sample address and results in 0 value. Since current code
>> directly returning the siar value, we could see multiple instruction
>> pointer values as 0 in perf report.
Can you please give more detail on that? What scenarios? On what CPUs?
>> Patch resolves this issue by adding a ternary condition to return
>> regs->nip incase SIAR is 0.
>
> Your description seems rather similar to
> https://github.com/linuxppc/linux/commit/2ca13a4cc56c920a6c9fc8ee45d02bccacd7f46c
>
> Does it mean that the problem occurs on more than the power10 DD1 ?
>
> In that case, can the solution be common instead of doing something for power10 DD1 and something
> for others ?
Agreed.
This change would seem to make that P10 DD1 logic superfluous.
Also we already have a fallback to regs->nip in the else case of the if,
so we should just use that rather than adding a ternary condition.
eg.
if (use_siar && siar_valid(regs) && siar)
return siar + perf_ip_adjust(regs);
else if (use_siar)
return 0; // no valid instruction pointer
else
return regs->nip;
I'm also not sure why we have that return 0 case, I can't think of why
we'd ever want to do that rather than using nip. So maybe we should do
another patch to drop that case.
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/perf: Use stack siar instead of mfspr
From: Michael Ellerman @ 2021-08-14 12:30 UTC (permalink / raw)
To: Christophe Leroy, kajoljain, linuxppc-dev; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <9662dfbf-d163-c313-745e-aeda0f638e98@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 13/08/2021 à 10:29, kajoljain a écrit :
>>
>> On 8/13/21 1:54 PM, Kajol Jain wrote:
>>> Minor optimization in the 'perf_instruction_pointer' function code by
>>> making use of stack siar instead of mfspr.
>>>
>>> Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
>>> into perf_read_regs")
>>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>>
>> Please ignore this patch-set as I mentioned wrong version number. I will resend
>> this patch-set again with correct version. Sorry for the confusion.
>
> I fear you are creating even more confusion by sending a v1 after sending a v2 ...
Yeah in future just reply to the v2 saying "oops I sent v2 instead of
v1" and leave it at that.
cheers
^ 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