* Re: [next-20220215] WARNING at fs/iomap/buffered-io.c:75 with xfstests
From: Stephen Rothwell @ 2022-02-16 7:39 UTC (permalink / raw)
To: Sachin Sant; +Cc: linux-xfs, riteshh, linuxppc-dev, linux-next
In-Reply-To: <5AD0BD6A-2C31-450A-924E-A581CD454073@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
Hi Sachin,
On Wed, 16 Feb 2022 12:55:02 +0530 Sachin Sant <sachinp@linux.ibm.com> wrote:
>
> While running xfstests on IBM Power10 logical partition (LPAR) booted
> with 5.17.0-rc4-next-20220215 following warning was seen:
>
> The warning is seen when test tries to unmount the file system. This problem is seen
> while running generic/475 sub test. Have attached captured messages during the test
> run of generic/475.
>
> xfstest is a recent add to upstream regression bucket. I don’t have any previous data
> to attempt a git bisect.
If you have time, could you test v5.17-rc4-2-gd567f5db412e (the commit
in Linus' tree that next-20220215 is based on) and if that OK, then a
bisect from that to 5.17.0-rc4-next-20220215 may be helpful.
Thanks for the report.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] crypto: vmx: Turn CRYPTO_DEV_VMX_ENCRYPT into tristate
From: Nicolai Stange @ 2022-02-16 9:33 UTC (permalink / raw)
To: Petr Vorel
Cc: Herbert Xu, Nicolai Stange, linux-kbuild, Nayna Jain,
Paulo Flabiano Smorigo, linux-crypto, leitao, linuxppc-dev
In-Reply-To: <20220215185936.15576-2-pvorel@suse.cz>
Hi Petr,
Petr Vorel <pvorel@suse.cz> writes:
> and remove CRYPTO_DEV_VMX, which looked redundant when only
> CRYPTO_DEV_VMX_ENCRYPT used it. Also it forces CRYPTO_GHASH to be
> builtin even CRYPTO_DEV_VMX_ENCRYPT was configured as module.
I'm confused by the description. CRYPTO_DEV_VMX_ENCRYPT has been a
tristate since ever? And thus, with CRYPTO_DEV_VMX_ENCRYPT=m,
CRYPTO_GHASH=m would be possible as far as vmx is concerned?
What this patch really does is to merge CRYPTO_DEV_VMX into
CRYPTO_DEV_VMX_ENCRYPT AFAICS.
These two seem indeed redundant to me, but for consistency with the
other crypto drivers (e.g. bcm, ccree, ...), I'd rather keep
CRYPTO_DEV_VMX and merge CRYPTO_DEV_VMX_ENCRYPT into it.
> Update powerpc defconfigs and description in MAINTAINERS.
The change to MAINTAINERS is completely unrelated? If anything, it had
to come with a separate patch then.
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> new in v2
>
> This might be a bit aggressive, but IMHO CRYPTO_DEV_VMX only complicated
> things for nothing.
I agree on the redundancy, but as said, CRYPTO_DEV_VMX_ENCRYPT should
probably the one to get dropped in favor of CRYPTO_DEV_VMX.
> But if you do *not* agree with removing it, I just add
> select to drivers/crypto/vmx/Kconfig (which forces dependencies to be
> always modules.)
>
> If it's ok for you to remove, please also check whether the description
> is ok. get_maintainer.pl script has size limitation:
>
> $ ./scripts/get_maintainer.pl drivers/crypto/vmx/Kconfig
> ...
> linux-crypto@vger.kernel.org (open list:IBM Power VMX Cryptographic Acceleration Instru...)
>
> maybe the name should be shorter.
>
> Kind regards,
> Petr
>
> MAINTAINERS | 2 +-
> arch/powerpc/configs/powernv_defconfig | 2 +-
> arch/powerpc/configs/ppc64_defconfig | 2 +-
> arch/powerpc/configs/pseries_defconfig | 2 +-
> drivers/crypto/Kconfig | 6 ------
> drivers/crypto/vmx/Kconfig | 4 ++--
> 6 files changed, 6 insertions(+), 12 deletions(-)
If you were to drop CONFIG_CRYPTO_DEV_VMX (like it's implemented in this
patch), then something had to be done about
obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
in drivers/crypto/Makefile as well.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..80e562579180 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9207,7 +9207,7 @@ L: target-devel@vger.kernel.org
> S: Supported
> F: drivers/scsi/ibmvscsi_tgt/
>
> -IBM Power VMX Cryptographic instructions
> +IBM Power VMX Cryptographic Acceleration Instructions Driver
> M: Breno Leitão <leitao@debian.org>
> M: Nayna Jain <nayna@linux.ibm.com>
> M: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
> diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
> index 49f49c263935..4b250d05dcdf 100644
> --- a/arch/powerpc/configs/powernv_defconfig
> +++ b/arch/powerpc/configs/powernv_defconfig
> @@ -337,7 +337,7 @@ CONFIG_CRYPTO_TEA=m
> CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_LZO=m
> CONFIG_CRYPTO_DEV_NX=y
> -CONFIG_CRYPTO_DEV_VMX=y
> +CONFIG_CRYPTO_DEV_VMX_ENCRYPT=m
> CONFIG_VIRTUALIZATION=y
> CONFIG_KVM_BOOK3S_64=m
> CONFIG_KVM_BOOK3S_64_HV=m
> diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
> index c8b0e80d613b..ebd33b94debb 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -355,7 +355,7 @@ CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_LZO=m
> CONFIG_CRYPTO_DEV_NX=y
> CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
> -CONFIG_CRYPTO_DEV_VMX=y
> +CONFIG_CRYPTO_DEV_VMX_ENCRYPT=m
> CONFIG_PRINTK_TIME=y
> CONFIG_PRINTK_CALLER=y
> CONFIG_MAGIC_SYSRQ=y
> diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
> index b571d084c148..304673817ef1 100644
> --- a/arch/powerpc/configs/pseries_defconfig
> +++ b/arch/powerpc/configs/pseries_defconfig
> @@ -315,7 +315,7 @@ CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRYPTO_LZO=m
> CONFIG_CRYPTO_DEV_NX=y
> CONFIG_CRYPTO_DEV_NX_ENCRYPT=m
> -CONFIG_CRYPTO_DEV_VMX=y
> +CONFIG_CRYPTO_DEV_VMX_ENCRYPT=m
> CONFIG_VIRTUALIZATION=y
> CONFIG_KVM_BOOK3S_64=m
> CONFIG_KVM_BOOK3S_64_HV=m
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 4f705674f94f..956f956607a5 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -761,12 +761,6 @@ config CRYPTO_DEV_QCOM_RNG
> To compile this driver as a module, choose M here. The
> module will be called qcom-rng. If unsure, say N.
>
> -config CRYPTO_DEV_VMX
> - bool "Support for VMX cryptographic acceleration instructions"
> - depends on PPC64 && VSX
> - help
> - Support for VMX cryptographic acceleration instructions.
> -
As said, I'd keep this one (while moving the GHASH dependency here) ...
> source "drivers/crypto/vmx/Kconfig"
... and drop this one.
Thanks,
Nicolai
>
> config CRYPTO_DEV_IMGTEC_HASH
> diff --git a/drivers/crypto/vmx/Kconfig b/drivers/crypto/vmx/Kconfig
> index c85fab7ef0bd..1a3808b719f3 100644
> --- a/drivers/crypto/vmx/Kconfig
> +++ b/drivers/crypto/vmx/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config CRYPTO_DEV_VMX_ENCRYPT
> - tristate "Encryption acceleration support on P8 CPU"
> - depends on CRYPTO_DEV_VMX
> + tristate "Power VMX cryptographic acceleration instructions driver"
> + depends on PPC64 && VSX
> select CRYPTO_GHASH
> default m
> help
--
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev
^ permalink raw reply
* Re: [next-20220215] WARNING at fs/iomap/buffered-io.c:75 with xfstests
From: Sachin Sant @ 2022-02-16 9:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-xfs, riteshh, linuxppc-dev, linux-next
In-Reply-To: <20220216183919.13b32e1e@canb.auug.org.au>
>> While running xfstests on IBM Power10 logical partition (LPAR) booted
>> with 5.17.0-rc4-next-20220215 following warning was seen:
>>
>> The warning is seen when test tries to unmount the file system. This problem is seen
>> while running generic/475 sub test. Have attached captured messages during the test
>> run of generic/475.
>>
>> xfstest is a recent add to upstream regression bucket. I don’t have any previous data
>> to attempt a git bisect.
>
> If you have time, could you test v5.17-rc4-2-gd567f5db412e (the commit
> in Linus' tree that next-20220215 is based on) and if that OK, then a
> bisect from that to 5.17.0-rc4-next-20220215 may be helpful.
Unfortunately I cannot recreate the problem consistently. I tried same test run with both
mainline as well as linux-next20220215. In both attempts I wasn’t able to recreate it.
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH v2 1/2] crypto: vmx: Turn CRYPTO_DEV_VMX_ENCRYPT into tristate
From: Petr Vorel @ 2022-02-16 9:57 UTC (permalink / raw)
To: Nicolai Stange
Cc: Herbert Xu, linux-kbuild, Nayna Jain, Paulo Flabiano Smorigo,
linux-crypto, leitao, linuxppc-dev
In-Reply-To: <87tuczf96a.fsf@suse.de>
Hi Nicolai,
thanks for all your comments.
> Hi Petr,
> Petr Vorel <pvorel@suse.cz> writes:
> > and remove CRYPTO_DEV_VMX, which looked redundant when only
> > CRYPTO_DEV_VMX_ENCRYPT used it. Also it forces CRYPTO_GHASH to be
> > builtin even CRYPTO_DEV_VMX_ENCRYPT was configured as module.
> I'm confused by the description. CRYPTO_DEV_VMX_ENCRYPT has been a
> tristate since ever? And thus, with CRYPTO_DEV_VMX_ENCRYPT=m,
> CRYPTO_GHASH=m would be possible as far as vmx is concerned?
I'm sorry, the description is wrong.
I'm not kconfig expert and I verify it again, but I run into it when testing
this with defconfig:
$ make defconfig && scripts/config --enable CONFIG_KVM_GUEST --disable
CRYPTO_MANAGER_DISABLE_TESTS --enable CONFIG_MODULE_SIG
It somehow inherits CRYPTO_DEV_VMX=y. But I'll verify it again.
> What this patch really does is to merge CRYPTO_DEV_VMX into
> CRYPTO_DEV_VMX_ENCRYPT AFAICS.
+1 This is a proper description.
> These two seem indeed redundant to me, but for consistency with the
> other crypto drivers (e.g. bcm, ccree, ...), I'd rather keep
> CRYPTO_DEV_VMX and merge CRYPTO_DEV_VMX_ENCRYPT into it.
I'm not sure myself, because some other modules also have Kconfig.
$ ls -1 drivers/crypto/*/Kconfig
drivers/crypto/allwinner/Kconfig
drivers/crypto/amlogic/Kconfig
drivers/crypto/caam/Kconfig
drivers/crypto/ccp/Kconfig
drivers/crypto/hisilicon/Kconfig
drivers/crypto/chelsio/Kconfig
drivers/crypto/keembay/Kconfig
drivers/crypto/marvell/Kconfig
drivers/crypto/nx/Kconfig
drivers/crypto/qat/Kconfig
drivers/crypto/stm32/Kconfig
drivers/crypto/ux500/Kconfig
drivers/crypto/virtio/Kconfig
drivers/crypto/vmx/Kconfig
Sure, some of them have many config options in Kconfig, but
at least drivers/crypto/chelsio/Kconfig and drivers/crypto/virtio/Kconfig
configure just the module. Given it's just these two, I should probably merge
CRYPTO_DEV_VMX_ENCRYPT into CRYPTO_DEV_VMX as you suggest (also defconfig
changes would not be needed).
@Herbert, Nayna, Paulo, Breno: any preference of these.
> > Update powerpc defconfigs and description in MAINTAINERS.
> The change to MAINTAINERS is completely unrelated? If anything, it had
> to come with a separate patch then.
You're right, I was hesitating myself.
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > new in v2
> > This might be a bit aggressive, but IMHO CRYPTO_DEV_VMX only complicated
> > things for nothing.
> I agree on the redundancy, but as said, CRYPTO_DEV_VMX_ENCRYPT should
> probably the one to get dropped in favor of CRYPTO_DEV_VMX.
> > But if you do *not* agree with removing it, I just add
> > select to drivers/crypto/vmx/Kconfig (which forces dependencies to be
> > always modules.)
> > If it's ok for you to remove, please also check whether the description
> > is ok. get_maintainer.pl script has size limitation:
> > $ ./scripts/get_maintainer.pl drivers/crypto/vmx/Kconfig
> > ...
> > linux-crypto@vger.kernel.org (open list:IBM Power VMX Cryptographic Acceleration Instru...)
> > maybe the name should be shorter.
> > Kind regards,
> > Petr
> > MAINTAINERS | 2 +-
> > arch/powerpc/configs/powernv_defconfig | 2 +-
> > arch/powerpc/configs/ppc64_defconfig | 2 +-
> > arch/powerpc/configs/pseries_defconfig | 2 +-
> > drivers/crypto/Kconfig | 6 ------
> > drivers/crypto/vmx/Kconfig | 4 ++--
> > 6 files changed, 6 insertions(+), 12 deletions(-)
> If you were to drop CONFIG_CRYPTO_DEV_VMX (like it's implemented in this
> patch), then something had to be done about
> obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
> in drivers/crypto/Makefile as well.
+1 (I obviously forget to amend).
Kind regards,
Petr
...
> > +++ b/drivers/crypto/Kconfig
> > @@ -761,12 +761,6 @@ config CRYPTO_DEV_QCOM_RNG
> > To compile this driver as a module, choose M here. The
> > module will be called qcom-rng. If unsure, say N.
> > -config CRYPTO_DEV_VMX
> > - bool "Support for VMX cryptographic acceleration instructions"
> > - depends on PPC64 && VSX
> > - help
> > - Support for VMX cryptographic acceleration instructions.
> > -
> As said, I'd keep this one (while moving the GHASH dependency here) ...
> > source "drivers/crypto/vmx/Kconfig"
> ... and drop this one.
> Thanks,
> Nicolai
^ permalink raw reply
* Re: [PATCH v2 1/2] crypto: vmx: Turn CRYPTO_DEV_VMX_ENCRYPT into tristate
From: Petr Vorel @ 2022-02-16 10:01 UTC (permalink / raw)
To: Nicolai Stange
Cc: Herbert Xu, linux-kbuild, Nayna Jain, Paulo Flabiano Smorigo,
linux-crypto, leitao, linuxppc-dev
In-Reply-To: <87tuczf96a.fsf@suse.de>
Hi,
side notes about the subject (following private notes from Nicolai):
I dared to use "crypto: vmx: " in subject, next version I'll use "crypto: vmx - "
as it's used in crypto.
Also continue the subject line into the rest of the commit message isn't
probably wanted.
Kind regards,
Petr
^ permalink raw reply
* Re: [PATCH v1 4/4] powerpc/ftrace: Style cleanup in ftrace_mprofile.S
From: Naveen N. Rao @ 2022-02-16 10:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Ingo Molnar,
Michael Ellerman, Paul Mackerras, Steven Rostedt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <973506292d0c7b05c06530c8e11803ce38e5eda2.1644949750.git.christophe.leroy@csgroup.eu>
Christophe Leroy wrote:
> Add some line breaks to better match the file's style, add
> some space after comma and fix a couple of misplaced blanks.
>
> Suggested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/trace/ftrace_mprofile.S | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
Thanks. For the series:
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
- Naveen
^ permalink raw reply
* Re: [next-20220215] WARNING at fs/iomap/buffered-io.c:75 with xfstests
From: Stephen Rothwell @ 2022-02-16 11:39 UTC (permalink / raw)
To: Sachin Sant; +Cc: linux-xfs, riteshh, linuxppc-dev, linux-next
In-Reply-To: <CF1506AF-E82B-412B-BD7B-A9F0B9971CB3@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
Hi Sachin,
On Wed, 16 Feb 2022 15:17:14 +0530 Sachin Sant <sachinp@linux.ibm.com> wrote:
>
> >> While running xfstests on IBM Power10 logical partition (LPAR) booted
> >> with 5.17.0-rc4-next-20220215 following warning was seen:
> >>
> >> The warning is seen when test tries to unmount the file system. This problem is seen
> >> while running generic/475 sub test. Have attached captured messages during the test
> >> run of generic/475.
> >>
> >> xfstest is a recent add to upstream regression bucket. I don’t have any previous data
> >> to attempt a git bisect.
> >
> > If you have time, could you test v5.17-rc4-2-gd567f5db412e (the commit
> > in Linus' tree that next-20220215 is based on) and if that OK, then a
> > bisect from that to 5.17.0-rc4-next-20220215 may be helpful.
>
> Unfortunately I cannot recreate the problem consistently. I tried same test run with both
> mainline as well as linux-next20220215. In both attempts I wasn’t able to recreate it.
No worries, thanks anyway.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4 1/2] Revert "powerpc: Set max_mapnr correctly"
From: Kefeng Wang @ 2022-02-16 12:11 UTC (permalink / raw)
To: linuxppc-dev, mpe, benh, paulus, linux-kernel, linux-mm
Cc: akpm, songyuanzheng, npiggin, Kefeng Wang
This reverts commit 602946ec2f90d5bd965857753880db29d2d9a1e9.
If CONFIG_HIGHMEM enabled, highmem will be disappeared with max_mapnr
set to max_low_pfn, see mem_init(),
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
...
free_highmem_page();
}
Revert it and will fix virt_addr_valid() check in the next patch.
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Fixes: 602946ec2f90 ("powerpc: Set max_mapnr correctly")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
v4:
- new patch
arch/powerpc/mm/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 8e301cd8925b..4d221d033804 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -255,7 +255,7 @@ void __init mem_init(void)
#endif
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
- set_max_mapnr(max_low_pfn);
+ set_max_mapnr(max_pfn);
kasan_late_init();
--
2.26.2
^ permalink raw reply related
* [PATCH v4 2/2] powerpc: Fix virt_addr_valid() check
From: Kefeng Wang @ 2022-02-16 12:11 UTC (permalink / raw)
To: linuxppc-dev, mpe, benh, paulus, linux-kernel, linux-mm
Cc: akpm, songyuanzheng, npiggin, Kefeng Wang
In-Reply-To: <20220216121109.157605-1-wangkefeng.wang@huawei.com>
When run ethtool eth0 on PowerPC64, the BUG occurred,
usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
kernel BUG at mm/usercopy.c:99
...
usercopy_abort+0x64/0xa0 (unreliable)
__check_heap_object+0x168/0x190
__check_object_size+0x1a0/0x200
dev_ethtool+0x2494/0x2b20
dev_ioctl+0x5d0/0x770
sock_do_ioctl+0xf0/0x1d0
sock_ioctl+0x3ec/0x5a0
__se_sys_ioctl+0xf0/0x160
system_call_exception+0xfc/0x1f0
system_call_common+0xf8/0x200
The code shows below,
data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
on PowerPC64, which leads to the panic.
As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
the virt_addr_valid() for PowerPC64, also add upper limit check to make
sure the virt is below high_memory.
Meanwhile, for PowerPC32 PAGE_OFFSET is the virtual address of the start
of lowmem, high_memory is the upper low virtual address, the check is
suitable for PowerPC32, this will fix the issue mentioned in commit
602946ec2f90 ("powerpc: Set max_mapnr correctly") too.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
v4:
- add upper limit check
v3:
- update changelog and remove a redundant cast
arch/powerpc/include/asm/page.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 254687258f42..7a1ba27a7285 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -132,7 +132,11 @@ static inline bool pfn_valid(unsigned long pfn)
#define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
-#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
+#define virt_addr_valid(vaddr) ({ \
+ unsigned long _addr = (unsigned long)vaddr; \
+ _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory && \
+ pfn_valid(virt_to_pfn(_addr)); \
+})
/*
* On Book-E parts we need __va to parse the device tree and we can't
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4
From: Michael Ellerman @ 2022-02-16 12:22 UTC (permalink / raw)
To: Kees Cook, Christophe Leroy
Cc: linux-arch, linux-ia64, linux-parisc, Arnd Bergmann, Helge Deller,
linux-kernel, James E.J. Bottomley, linux-mm, Paul Mackerras,
Greg Kroah-Hartman, Andrew Morton, linuxppc-dev
In-Reply-To: <202202150807.D584917D34@keescook>
Kees Cook <keescook@chromium.org> writes:
> On Tue, Feb 15, 2022 at 01:40:55PM +0100, Christophe Leroy wrote:
>> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
>> on those three architectures because LKDTM messes up function
>> descriptors with functions.
>>
>> This series does some cleanup in the three architectures and
>> refactors function descriptors so that it can then easily use it
>> in a generic way in LKDTM.
>
> Thanks for doing this! It looks good to me. :)
How should we merge this series, it's a bit all over the map.
I could put it in a topic branch?
cheers
^ permalink raw reply
* Re: [PATCH v4 00/13] Fix LKDTM for PPC64/IA64/PARISC v4
From: John Paul Adrian Glaubitz @ 2022-02-16 12:25 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Andrew Morton, James E.J. Bottomley,
Helge Deller, Arnd Bergmann, Kees Cook, Greg Kroah-Hartman
Cc: linux-arch, linux-ia64, linux-parisc, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <cover.1644928018.git.christophe.leroy@csgroup.eu>
Hi!
On 2/15/22 13:40, Christophe Leroy wrote:
> PPC64/IA64/PARISC have function descriptors. LKDTM doesn't work
> on those three architectures because LKDTM messes up function
> descriptors with functions.
>
> This series does some cleanup in the three architectures and
> refactors function descriptors so that it can then easily use it
> in a generic way in LKDTM.
I'll test the series on ia64 later this week. I have an Itanium box at
home for testing kernel patches.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Update default hugetlb size early
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, linuxppc-dev; +Cc: linux-mm
In-Reply-To: <20220211065215.101767-1-aneesh.kumar@linux.ibm.com>
On Fri, 11 Feb 2022 12:22:15 +0530, Aneesh Kumar K.V wrote:
> commit: d9c234005227 ("Do not depend on MAX_ORDER when grouping pages by mobility")
> introduced pageblock_order which will be used to group pages better.
> The kernel now groups pages based on the value of HPAGE_SHIFT. Hence HPAGE_SHIFT
> should be set before we call set_pageblock_order.
>
> set_pageblock_order happens early in the boot and default hugetlb page size
> should be initialized before that to compute the right pageblock_order value.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Update default hugetlb size early
https://git.kernel.org/powerpc/c/2354ad252b66695be02f4acd18e37bf6264f0464
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/32: Remove remaining .stabs annotations
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, kernel test robot, linux-kernel
In-Reply-To: <68932ec2ba6b868d35006b96e90f0890f3da3c05.1638273868.git.christophe.leroy@csgroup.eu>
On Tue, 30 Nov 2021 13:04:49 +0100, Christophe Leroy wrote:
> STABS debug format has been superseded long time ago by DWARF.
>
> Remove the few remaining .stabs annotations from old 32 bits code.
>
>
Applied to powerpc/next.
[1/2] powerpc/32: Remove remaining .stabs annotations
https://git.kernel.org/powerpc/c/12318163737cd8808d13faa6e2393774191a6182
[2/2] powerpc/32: Remove _ENTRY() macro
https://git.kernel.org/powerpc/c/27e21e8f128a56d3462f0fe2fd3a59c02cc002b1
cheers
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/lib/sstep: Use l1_dcache_bytes() instead of opencoding
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <6c608fd4795e2d8ea1a0a449405a0087f76d8bb3.1642752375.git.christophe.leroy@csgroup.eu>
On Fri, 21 Jan 2022 08:06:27 +0000, Christophe Leroy wrote:
> Don't opencode dcache size retrieval based on whether that's ppc32 or ppc64.
>
> Use l1_dcache_bytes()
>
>
Applied to powerpc/next.
[1/3] powerpc/lib/sstep: Use l1_dcache_bytes() instead of opencoding
https://git.kernel.org/powerpc/c/67484e0de9c93b4a9187bb49f45dfdaa8dc03c0b
[2/3] powerpc/lib/sstep: Remove unneeded #ifdef __powerpc64__
https://git.kernel.org/powerpc/c/7c3bba91999075f4cfcab0542e4eb74d2d63554b
[3/3] powerpc/lib/sstep: use truncate_if_32bit()
https://git.kernel.org/powerpc/c/6836f099039e6c72fb548bf527345aa4345c3308
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Enable STRICT_MODULE_RWX for the 603 core
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1e6162f334167e75f1140082932e3a354b16daba.1642413973.git.christophe.leroy@csgroup.eu>
On Mon, 17 Jan 2022 10:06:39 +0000, Christophe Leroy wrote:
> The book3s/32 MMU doesn't support per page execution protection and
> doesn't support RO protection for kernel pages.
>
> However, on the 603 which implements software loaded TLBs, execution
> protection is honored by the TLB Miss handler which doesn't load
> Instruction TLB for non executable pages. And RO protection is
> honored by clearing the C bit for RO pages, leading to DSI.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Enable STRICT_MODULE_RWX for the 603 core
https://git.kernel.org/powerpc/c/0670010f3b10aeaad0dfdf0dad0bcd020fc70eb5
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/bpf: Always reallocate BPF_REG_5, BPF_REG_AX and TMP_REG when possible
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: Naveen N . Rao, linuxppc-dev, linux-kernel
In-Reply-To: <b04c246874b716911139c04bc004b3b14eed07ef.1641817763.git.christophe.leroy@csgroup.eu>
On Mon, 10 Jan 2022 12:29:42 +0000, Christophe Leroy wrote:
> BPF_REG_5, BPF_REG_AX and TMP_REG are mapped on non volatile registers
> because there are not enough volatile registers, but they don't need
> to be preserved on function calls.
>
> So when some volatile registers become available, those registers can
> always be reallocated regardless of whether SEEN_FUNC is set or not.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/bpf: Always reallocate BPF_REG_5, BPF_REG_AX and TMP_REG when possible
https://git.kernel.org/powerpc/c/a8936569a07bf27cc9cfc2a39a1e5ea91273b2d4
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Use the newly added is_tsk_32bit_task() macro
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7304a889dbe885aefad8a8333673c81ee4b8f7a6.1642751874.git.christophe.leroy@csgroup.eu>
On Fri, 21 Jan 2022 07:58:47 +0000, Christophe Leroy wrote:
> Two places deserve using the macro is_tsk_32bit_task() added by
> commit 252745240ba0 ("powerpc/audit: Fix syscall_get_arch()")
>
>
Applied to powerpc/next.
[1/1] powerpc: Use the newly added is_tsk_32bit_task() macro
https://git.kernel.org/powerpc/c/9d44d1bd93b9a881f407b3202dc13fbd85fb5f1a
cheers
^ permalink raw reply
* Re: [PATCH v2 00/13] Implement livepatch on PPC32 and more
From: Michael Ellerman @ 2022-02-16 12:26 UTC (permalink / raw)
To: Steven Rostedt, Jiri Kosina, Naveen N . Rao, Christophe Leroy,
Josh Poimboeuf, Miroslav Benes, Joe Lawrence, Petr Mladek,
Ingo Molnar
Cc: live-patching, linuxppc-dev, linux-kernel
In-Reply-To: <cover.1640017960.git.christophe.leroy@csgroup.eu>
On Mon, 20 Dec 2021 16:37:58 +0000, Christophe Leroy wrote:
> This series implements livepatch on PPC32 and implements
> CONFIG_DYNAMIC_FTRACE_WITH_ARGS to simplify ftracing.
>
> v2:
> - Fix problem with strict modules RWX
> - Convert powerpc to CONFIG_DYNAMIC_FTRACE_WITH_ARGS
> - Convert function graph tracing to C
> - Refactor PPC32 versus PPC64
>
> [...]
Patches 1 and 3-13 applied to powerpc/next.
[01/13] livepatch: Fix build failure on 32 bits processors
https://git.kernel.org/powerpc/c/2f293651eca3eacaeb56747dede31edace7329d2
[03/13] powerpc/module_32: Fix livepatching for RO modules
https://git.kernel.org/powerpc/c/0c850965d6909d39fd69d6a3602bb62b48cad417
[04/13] powerpc/ftrace: Add support for livepatch to PPC32
https://git.kernel.org/powerpc/c/a4520b25276500f1abcfc55d24f1251b7b08eff6
[05/13] powerpc/ftrace: Don't save again LR in ftrace_regs_caller() on PPC32
https://git.kernel.org/powerpc/c/7875bc9b07cde868784195e215f4deaa0fa928a2
[06/13] powerpc/ftrace: Simplify PPC32's return_to_handler()
https://git.kernel.org/powerpc/c/7bdb478c1d15cfd3a92db6331cb2d3dd3a8b9436
[07/13] powerpc/ftrace: Prepare PPC32's ftrace_caller() for CONFIG_DYNAMIC_FTRACE_WITH_ARGS
https://git.kernel.org/powerpc/c/d95bf254be5f74c1e4c8f7cb64e2e21b9cc91717
[08/13] powerpc/ftrace: Prepare PPC64's ftrace_caller() for CONFIG_DYNAMIC_FTRACE_WITH_ARGS
https://git.kernel.org/powerpc/c/c75388a8ceffbf1bf72c61afe66a72e58aa20c74
[09/13] powerpc/ftrace: Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS
https://git.kernel.org/powerpc/c/40b035efe288f42bbf4483236cde652584ccb64e
[10/13] powerpc/ftrace: Refactor ftrace_{en/dis}able_ftrace_graph_caller
https://git.kernel.org/powerpc/c/0c81ed5ed43863d313cf253b0ebada6ea2f17676
[11/13] powerpc/ftrace: directly call of function graph tracer by ftrace caller
https://git.kernel.org/powerpc/c/830213786c498b0c488fedd2abc15a7ce442b42f
[12/13] powerpc/ftrace: Prepare ftrace_64_mprofile.S for reuse by PPC32
https://git.kernel.org/powerpc/c/41315494beed087011f256b4f1439bb3d8236904
[13/13] powerpc/ftrace: Remove ftrace_32.S
https://git.kernel.org/powerpc/c/4ee83a2cfbc46c13f2a08fe6d48dbcede53cdbf8
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: Maxime Bizon, linuxppc-dev, linux-kernel
In-Reply-To: <43c3c76a1175ae6dc1a3d3b5c3f7ecb48f683eea.1640344012.git.christophe.leroy@csgroup.eu>
On Fri, 24 Dec 2021 11:07:33 +0000, Christophe Leroy wrote:
> Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
> included a spin_lock() to change_page_attr() in order to
> safely perform the three step operations. But then
> commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against
> concurrent accesses") modify it to use pte_update() and do
> the operation safely against concurrent access.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/set_memory: Avoid spinlock recursion in change_page_attr()
https://git.kernel.org/powerpc/c/a4c182ecf33584b9b2d1aa9dad073014a504c01f
[2/2] powerpc: Add set_memory_{p/np}() and remove set_memory_attr()
https://git.kernel.org/powerpc/c/f222ab83df92acf72691a2021e1f0d99880dcdf1
cheers
^ permalink raw reply
* Re: [PATCH v4 1/5] powerpc/vdso: augment VDSO32 functions to support 64 bits build
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Benjamin Herrenschmidt,
Christophe Leroy, masahiroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c2cbb8f046b7efc251053521dc39b752795e26b7.1642782130.git.christophe.leroy@csgroup.eu>
On Fri, 21 Jan 2022 16:30:21 +0000, Christophe Leroy wrote:
> VDSO64 cacheflush.S datapage.S gettimeofday.S and vgettimeofday.c
> are very similar to their VDSO32 counterpart.
>
> VDSO32 counterpart is already more complete than the VDSO64 version
> as it supports both PPC32 vdso and 32 bits VDSO for PPC64.
>
> Use compat macros wherever necessary in PPC32 files
> so that they can also be used to build VDSO64.
>
> [...]
Applied to powerpc/next.
[1/5] powerpc/vdso: augment VDSO32 functions to support 64 bits build
https://git.kernel.org/powerpc/c/f061fb03ee611c5657010ee4fa2a3fa64dfe3bd0
[2/5] powerpc/vdso: Rework VDSO32 makefile to add a prefix to object files
https://git.kernel.org/powerpc/c/d88378d8d2c776154c6b606f2a423a81d7795f6f
[3/5] powerpc/vdso: Merge vdso64 and vdso32 into a single directory
https://git.kernel.org/powerpc/c/fd1feade75fb1a9275c39d76c5ccdbbbe6b37aa3
[4/5] powerpc/vdso: Remove cvdso_call_time macro
https://git.kernel.org/powerpc/c/9b97bea90072a075363a200dd7b54ad4a24e9491
[5/5] powerpc/vdso: Move cvdso_call macro into gettimeofday.S
https://git.kernel.org/powerpc/c/692b21d78046851e75dc25bba773189c670b49c2
cheers
^ permalink raw reply
* Re: [RFC PATCH v1 00/11] powerpc/machdep: Remove dust and convert to static calls
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1630667612.git.christophe.leroy@csgroup.eu>
On Fri, 3 Sep 2021 11:18:34 +0000 (UTC), Christophe Leroy wrote:
> The purpose of this series is to convert machine dependent
> functions in structure ppc_md into static calls.
>
> First part of the series remove some dust in and around machdep.h
>
> Then some helpers are defined to abstract the access to ppc_md. structure.
>
> [...]
Patches 3, 5, 7 and 8 applied to powerpc/next.
[03/11] powerpc/machdep: Remove CONFIG_PPC_HAS_FEATURE_CALLS
https://git.kernel.org/powerpc/c/d6a6c725a20467f52a41270bdaad9565c66f3b7a
[05/11] powerpc/machdep: Move sys_ctrler_t definition into pmac.h
https://git.kernel.org/powerpc/c/e6d03ac156db84422519aa8628efc210d24bf889
[07/11] powerpc/mpc86xx_hpcn: Remove obsolete statement
https://git.kernel.org/powerpc/c/fae65a9ac8fd2221dbf034019fa18d72b2b0c8e9
[08/11] powerpc/corenet: Change criteria to set MPIC_ENABLE_COREINT
https://git.kernel.org/powerpc/c/66ada2907864cafa4578b92926cb8bc0a4bc8c9c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: make pseries_devicetree_update() static
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20220207221247.354454-1-nathanl@linux.ibm.com>
On Mon, 7 Feb 2022 16:12:47 -0600, Nathan Lynch wrote:
> pseries_devicetree_update() has only one call site, in the same file in
> which it is defined. Make it static.
>
>
Applied to powerpc/next.
[1/1] powerpc/pseries: make pseries_devicetree_update() static
https://git.kernel.org/powerpc/c/92e6dc257bd5771cf8db662e4d371fdb58fcbf43
cheers
^ permalink raw reply
* Re: [PATCHv2] selftests/powerpc/copyloops: Add memmove_64 test
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: Ritesh Harjani, linuxppc-dev; +Cc: Aneesh Kumar K . V, Vaibhav Jain
In-Reply-To: <57242c1fe7aba6b7f0fcd0490303bfd5f222ee00.1631512686.git.riteshh@linux.ibm.com>
On Mon, 13 Sep 2021 11:47:20 +0530, Ritesh Harjani wrote:
> While debugging an issue, we wanted to check whether the arch specific
> kernel memmove implementation is correct.
> This selftest could help test that.
>
>
Applied to powerpc/next.
[1/1] selftests/powerpc/copyloops: Add memmove_64 test
https://git.kernel.org/powerpc/c/2504e5b9827f7fc76ed0e4593adc852ac7a19851
cheers
^ permalink raw reply
* Re: powerpc: Set crashkernel offset to mid of RMA region
From: Michael Ellerman @ 2022-02-16 12:25 UTC (permalink / raw)
To: mpe, Sourabh Jain, linuxppc-dev; +Cc: Abdul haleem, hbathini, mahesh
In-Reply-To: <20220204085601.107257-1-sourabhjain@linux.ibm.com>
On Fri, 4 Feb 2022 14:26:01 +0530, Sourabh Jain wrote:
> On large config LPARs (having 192 and more cores), Linux fails to boot
> due to insufficient memory in the first memblock. It is due to the
> memory reservation for the crash kernel which starts at 128MB offset of
> the first memblock. This memory reservation for the crash kernel doesn't
> leave enough space in the first memblock to accommodate other essential
> system resources.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Set crashkernel offset to mid of RMA region
https://git.kernel.org/powerpc/c/7c5ed82b800d8615cdda00729e7b62e5899f0b13
cheers
^ permalink raw reply
* Re: [PATCH v5 0/5] KVM: PPC: MMIO fixes
From: Michael Ellerman @ 2022-02-16 13:04 UTC (permalink / raw)
To: kvm-ppc, Fabiano Rosas; +Cc: aik, linuxppc-dev, npiggin
In-Reply-To: <20220125215655.1026224-1-farosas@linux.ibm.com>
On Tue, 25 Jan 2022 18:56:50 -0300, Fabiano Rosas wrote:
> Changes from v4:
>
> -patch 4: switched to kvm_debug_ratelimited.
>
> -patch 5: kept the Program interrupt for BookE.
>
> v4:
> https://lore.kernel.org/r/20220121222626.972495-1-farosas@linux.ibm.com
>
> [...]
Applied to powerpc/topic/ppc-kvm.
[1/5] KVM: PPC: Book3S HV: Stop returning internal values to userspace
https://git.kernel.org/powerpc/c/36d014d37d59065087e51b8381e37993f1ca99bc
[2/5] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
https://git.kernel.org/powerpc/c/b99234b918c6e36b9aa0a5b2981e86b6bd11f8e2
[3/5] KVM: PPC: mmio: Reject instructions that access more than mmio.data size
https://git.kernel.org/powerpc/c/3f831504482ab0d0d53d1966987959d1485345cc
[4/5] KVM: PPC: mmio: Return to guest after emulation failure
https://git.kernel.org/powerpc/c/349fbfe9b918e6dea00734f07c0fbaf4c2e2df5e
[5/5] KVM: PPC: Book3s: mmio: Deliver DSI after emulation failure
https://git.kernel.org/powerpc/c/c1c8a66367a35aabbad9bd629b105b9fb49f2c1f
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