Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links
On Tue, Jan 9, 2024 at 5:26 PM Nathan Chancellor wrote: > > This series updates all instances of LLVM Phabricator and Bugzilla links > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > shortlinks respectively. > > I split up the Phabricator patch into BPF selftests and the rest of the > kernel in case the BPF folks want to take it separately from the rest of > the series, there are obviously no dependency issues in that case. The > Bugzilla change was mechanical enough and should have no conflicts. > > I am aiming this at Andrew and CC'ing other lists, in case maintainers > want to chime in, but I think this is pretty uncontroversial (famous > last words...). > Acked-by: Alex Deucher > --- > Nathan Chancellor (3): > selftests/bpf: Update LLVM Phabricator links > arch and include: Update LLVM Phabricator links > treewide: Update LLVM Bugzilla links > > arch/arm64/Kconfig | 4 +-- > arch/powerpc/Makefile | 4 +-- > arch/powerpc/kvm/book3s_hv_nested.c| 2 +- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/ftrace.h| 2 +- > arch/s390/include/asm/ftrace.h | 2 +- > arch/x86/power/Makefile| 2 +- > crypto/blake2b_generic.c | 2 +- > drivers/firmware/efi/libstub/Makefile | 2 +- > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- > drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- > drivers/regulator/Kconfig | 2 +- > include/asm-generic/vmlinux.lds.h | 2 +- > include/linux/compiler-clang.h | 2 +- > lib/Kconfig.kasan | 2 +- > lib/raid6/Makefile | 2 +- > lib/stackinit_kunit.c | 2 +- > mm/slab_common.c | 2 +- > net/bridge/br_multicast.c | 2 +- > security/Kconfig | 2 +- > tools/testing/selftests/bpf/README.rst | 32 > +++--- > tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- > .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- > 23 files changed, 40 insertions(+), 40 deletions(-) > --- > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a > change-id: 20240109-update-llvm-links-d03f9d649e1e > > Best regards, > -- > Nathan Chancellor >
Re: [PATCH v5 0/5] RISC-V SBI debug console extension support
On Thu, 11 Jan 2024 06:50:37 PST (-0800), patchwork-bot+linux-ri...@kernel.org wrote: Hello: This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt : On Fri, 24 Nov 2023 12:39:00 +0530 you wrote: The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines SBI debug console (DBCN) extension which replaces the legacy SBI v0.1 functions sbi_console_putchar() and sbi_console_getchar(). (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases) This series adds support for SBI debug console (DBCN) extension in Linux RISC-V. [...] Here is the summary with links: - [v5,1/5] RISC-V: Add stubs for sbi_console_putchar/getchar() https://git.kernel.org/riscv/c/f503b167b660 - [v5,2/5] RISC-V: Add SBI debug console helper routines https://git.kernel.org/riscv/c/f43fabf444ca - [v5,3/5] tty/serial: Add RISC-V SBI debug console based earlycon https://git.kernel.org/riscv/c/c77bf3607a0f - [v5,4/5] tty: Add SBI debug console support to HVC SBI driver https://git.kernel.org/riscv/c/88ead68e764c - [v5,5/5] RISC-V: Enable SBI based earlycon support https://git.kernel.org/riscv/c/50942ad6ddb5 You are awesome, thank you! Nathan points out that this has some semantic conflicts with a patch in Greg's TTY tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?id=f32fcbedbe9290565e4eac3fd7c4c451d5478787 So I think the best bet is to wait on Greg's patch to land in Linus' tree, and then base a v6 of this patch set on that merged patch. I'm going to drop this one from for-next.
Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
Johannes and I were chatting about this the other day. We might be
able to disable certain zsmalloc behavior in the case of !MMU, making
it available there too. Once that's happened, we can outright remove
z3fold and zbud, and have one allocator to rule them all? :)
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.
>
> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.
>
> Signed-off-by: Yosry Ahmed
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig
> b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig
> b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
> -config Z3FOLD
> - tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux...@kvack.org and the zswap maintainers.
> +
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
> +config Z3FOLD
> + tristate
> + default y
> + depends on Z3FOLD_DEPRECATED
> +
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>
Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed wrote:
>
> The z3fold compressed pages allocator is not widely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
>
> In hopes of having a single compressed pages allocator at some point,
> and following in the footsteps of SLAB, deprecate z3fold. Rename the
> user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
> with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
> defconfigs.
>
> Existing users, if any, should voice their objections. Otherwise, we can
> remove z3fold in a few releases.
>
> Signed-off-by: Yosry Ahmed
> ---
> I have limited understanding of Kconfigs. I modelled this after commit
> eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
> but one difference is that CONFIG_Z3FOLD is a tristate. I made
> CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
> so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
> am not sure if that's the correct way to do this.
>
> ---
> arch/loongarch/configs/loongson3_defconfig | 1 -
> arch/powerpc/configs/ppc64_defconfig | 1 -
> mm/Kconfig | 13 +++--
> 3 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/loongarch/configs/loongson3_defconfig
> b/arch/loongarch/configs/loongson3_defconfig
> index 33795e4a5bd63..89b66b6c6a1d5 100644
> --- a/arch/loongarch/configs/loongson3_defconfig
> +++ b/arch/loongarch/configs/loongson3_defconfig
> @@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
> CONFIG_ZSWAP=y
> CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
> CONFIG_ZBUD=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=m
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
> diff --git a/arch/powerpc/configs/ppc64_defconfig
> b/arch/powerpc/configs/ppc64_defconfig
> index 544a65fda77bc..d39284489aa26 100644
> --- a/arch/powerpc/configs/ppc64_defconfig
> +++ b/arch/powerpc/configs/ppc64_defconfig
> @@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_BINFMT_MISC=m
> CONFIG_ZSWAP=y
> -CONFIG_Z3FOLD=y
> CONFIG_ZSMALLOC=y
> # CONFIG_SLAB_MERGE_DEFAULT is not set
> CONFIG_SLAB_FREELIST_RANDOM=y
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 1902cfe4cc4f5..bc6cc97c08349 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -193,15 +193,24 @@ config ZBUD
> deterministic reclaim properties that make it preferable to a higher
> density approach when reclaim will be used.
>
> -config Z3FOLD
> - tristate "3:1 compression allocator (z3fold)"
> +config Z3FOLD_DEPRECATED
> + bool "3:1 compression allocator (z3fold) (DEPRECATED)"
> depends on ZSWAP
> help
> + Deprecated and scheduled for removal in a few cycles. If you have
> + a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
> + contact linux...@kvack.org and the zswap maintainers.
> +
> A special purpose allocator for storing compressed pages.
> It is designed to store up to three compressed pages per physical
> page. It is a ZBUD derivative so the simplicity and determinism are
> still there.
>
> +config Z3FOLD
> + tristate
> + default y
> + depends on Z3FOLD_DEPRECATED
> +
> config ZSMALLOC
> tristate
> prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
> --
> 2.43.0.275.g3460e3d667-goog
>
FWIW:
Acked-by: Nhat Pham
[RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
The z3fold compressed pages allocator is not widely used, most users use
zsmalloc. The only disadvantage of zsmalloc in comparison is the
dependency on MMU, and zbud is a more common option for !MMU as it was
the default zswap allocator for a long time.
In hopes of having a single compressed pages allocator at some point,
and following in the footsteps of SLAB, deprecate z3fold. Rename the
user-visible option so that users with CONFIG_Z3FOLD=y get a new prompt
with explanation during make oldconfig. Remove CONFIG_Z3FOLD=y from
defconfigs.
Existing users, if any, should voice their objections. Otherwise, we can
remove z3fold in a few releases.
Signed-off-by: Yosry Ahmed
---
I have limited understanding of Kconfigs. I modelled this after commit
eb07c4f39c3e ("mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED"),
but one difference is that CONFIG_Z3FOLD is a tristate. I made
CONFIG_Z3FOLD_DEPRECATED a boolean config, and CONFIG_Z3FOLD default y
so that it is on by default if CONFIG_Z3FOLD_DEPRECATED is selected. I
am not sure if that's the correct way to do this.
---
arch/loongarch/configs/loongson3_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
mm/Kconfig | 13 +++--
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/loongarch/configs/loongson3_defconfig
b/arch/loongarch/configs/loongson3_defconfig
index 33795e4a5bd63..89b66b6c6a1d5 100644
--- a/arch/loongarch/configs/loongson3_defconfig
+++ b/arch/loongarch/configs/loongson3_defconfig
@@ -85,7 +85,6 @@ CONFIG_ZPOOL=y
CONFIG_ZSWAP=y
CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD=y
CONFIG_ZBUD=y
-CONFIG_Z3FOLD=y
CONFIG_ZSMALLOC=m
# CONFIG_COMPAT_BRK is not set
CONFIG_MEMORY_HOTPLUG=y
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 544a65fda77bc..d39284489aa26 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -81,7 +81,6 @@ CONFIG_MODULE_SIG_SHA512=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_BINFMT_MISC=m
CONFIG_ZSWAP=y
-CONFIG_Z3FOLD=y
CONFIG_ZSMALLOC=y
# CONFIG_SLAB_MERGE_DEFAULT is not set
CONFIG_SLAB_FREELIST_RANDOM=y
diff --git a/mm/Kconfig b/mm/Kconfig
index 1902cfe4cc4f5..bc6cc97c08349 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -193,15 +193,24 @@ config ZBUD
deterministic reclaim properties that make it preferable to a higher
density approach when reclaim will be used.
-config Z3FOLD
- tristate "3:1 compression allocator (z3fold)"
+config Z3FOLD_DEPRECATED
+ bool "3:1 compression allocator (z3fold) (DEPRECATED)"
depends on ZSWAP
help
+ Deprecated and scheduled for removal in a few cycles. If you have
+ a good reason for using Z3FOLD rather than ZSMALLOC or ZBUD, please
+ contact linux...@kvack.org and the zswap maintainers.
+
A special purpose allocator for storing compressed pages.
It is designed to store up to three compressed pages per physical
page. It is a ZBUD derivative so the simplicity and determinism are
still there.
+config Z3FOLD
+ tristate
+ default y
+ depends on Z3FOLD_DEPRECATED
+
config ZSMALLOC
tristate
prompt "N:1 compression allocator (zsmalloc)" if ZSWAP
--
2.43.0.275.g3460e3d667-goog
Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham wrote: > > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed wrote: > > > > The z3fold compressed pages allocator is not widely used, most users use > > zsmalloc. The only disadvantage of zsmalloc in comparison is the > > dependency on MMU, and zbud is a more common option for !MMU as it was > > the default zswap allocator for a long time. > > Johannes and I were chatting about this the other day. We might be > able to disable certain zsmalloc behavior in the case of !MMU, making > it available there too. Once that's happened, we can outright remove > z3fold and zbud, and have one allocator to rule them all? :) (Adding Sergey and Minchan for visibility) I didn't want to bring up the zsmalloc MMU dependency in this thread to reduce noise, but that's also what I had in mind. Sergey and I were also chatting about this the other day :) I thought deprecating z3fold is the low hanging fruit. Then, once we can sort out the MMU dependency in zsmalloc, we can go after zbud as well.
Re: [RFC PATCH] mm: z3fold: rename CONFIG_Z3FOLD to CONFIG_Z3FOLD_DEPRECATED
On Fri, Jan 12, 2024 at 3:37 PM Yosry Ahmed wrote: > > On Fri, Jan 12, 2024 at 11:42 AM Nhat Pham wrote: > > > > On Fri, Jan 12, 2024 at 11:31 AM Yosry Ahmed wrote: > > > > > > The z3fold compressed pages allocator is not widely used, most users use > > > zsmalloc. The only disadvantage of zsmalloc in comparison is the > > > dependency on MMU, and zbud is a more common option for !MMU as it was > > > the default zswap allocator for a long time. > > > > Johannes and I were chatting about this the other day. We might be > > able to disable certain zsmalloc behavior in the case of !MMU, making > > it available there too. Once that's happened, we can outright remove > > z3fold and zbud, and have one allocator to rule them all? :) > > (Adding Sergey and Minchan for visibility) > > I didn't want to bring up the zsmalloc MMU dependency in this thread > to reduce noise, but that's also what I had in mind. Sergey and I were > also chatting about this the other day :) > > I thought deprecating z3fold is the low hanging fruit. Then, once we > can sort out the MMU dependency in zsmalloc, we can go after zbud as > well. Makes sense to me. Should we do the same thing to zbud? We probably have even less of a case for it, no?
Re: [PATCH] powerpc: Fix preserved memory size for int-vectors
On 2024/1/9 17:59, Christophe Leroy wrote:
>
>
> Le 09/01/2024 à 04:38, GUO Zihua a écrit :
>> [Vous ne recevez pas souvent de courriers de guozi...@huawei.com. Découvrez
>> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>>
>> The first 32k of memory is reserved for interrupt vectors, however for
>> powerpc64 this might not be enough. Fix this by reserving the maximum
>> size between 32k and the real size of interrupt vectors.
>
> You say "this might not be enough". Do you have exemples of when it is
> not enough, or is it just hypothetycal ?
Hi Christophe,
The problem is discovered when I am trying to test ppc64 kaslr
(developed by Yan, ref: https://lwn.net/Articles/811686/) on QEMU. On
QEMU it seems that the size of interrupt vectors is way larger than
0x8000, resulting in the interrupt vectors code overriding memory
allocated for PACAs during do_final_fixups().
>
>>
>> Signed-off-by: GUO Zihua
>> ---
>> arch/powerpc/kernel/prom.c | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 0b5878c3125b..f374487513b3 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -758,6 +758,7 @@ static inline void save_fscr_to_task(void) {}
>> void __init early_init_devtree(void *params)
>> {
>> phys_addr_t limit;
>> + size_t int_vector_size;
>
> Why size_t ?
>
> memblock_reserve() takes a phys_addr_t
Will fix that.
>
>>
>> DBG(" -> early_init_devtree(%px)\n", params);
>>
>> @@ -810,9 +811,17 @@ void __init early_init_devtree(void *params)
>> setup_initial_memory_limit(memstart_addr, first_memblock_size);
>> /* Reserve MEMBLOCK regions used by kernel, initrd, dt, etc... */
>> memblock_reserve(PHYSICAL_START, __pa(_end) - PHYSICAL_START);
>> +#ifdef CONFIG_PPC64
>> + /* If relocatable, reserve at least 32k for interrupt vectors etc. */
>> + int_vector_size = (size_t)((uintptr_t)__end_interrupts -
>> + (uintptr_t)_stext);
>
> Why do you need so many casts ? When I look into function
> overlaps_interrupt_vector_text() it seems to work well without cast at all.
I'll look into it.
>
>> + int_vector_size = max_t(size_t, 0x8000, int_vector_size);
>
> Use SZ_32K instead of 0x8000
>
>> +#else
>> /* If relocatable, reserve first 32k for interrupt vectors etc. */
>> + int_vector_size = 0x8000;
>
> Use SZ_32K
Sure.
>
>> +#endif
>> if (PHYSICAL_START > MEMORY_START)
>> - memblock_reserve(MEMORY_START, 0x8000);
>> + memblock_reserve(MEMORY_START, int_vector_size);
>> reserve_kdump_trampoline();
>> #if defined(CONFIG_FA_DUMP) || defined(CONFIG_PRESERVE_FA_DUMP)
>> /*
>> --
>> 2.34.1
>>
--
Best
GUO Zihua
