* [PATCH V2 0/8] sched: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux, now. Delete in include/linux/sched.h
and arch's include/asm. This would confuse people who are
implementing the COMPAT feature for architecture.
Changes in v2:
- Add Arnd's comment in main patch
- Optimize coding convention with Christophe's advise
Guo Ren (8):
sched: Remove unused TASK_SIZE_OF
sched: x86: Remove unused TASK_SIZE_OF
sched: sparc: Remove unused TASK_SIZE_OF
sched: powerpc: Remove unused TASK_SIZE_OF
sched: s390: Remove unused TASK_SIZE_OF
sched: parisc: Remove unused TASK_SIZE_OF
sched: arm64: Remove unused TASK_SIZE_OF
sched: mips: Remove unused TASK_SIZE_OF
arch/arm64/include/asm/processor.h | 2 --
arch/mips/include/asm/processor.h | 3 ---
arch/parisc/include/asm/processor.h | 3 +--
arch/powerpc/include/asm/task_size_64.h | 6 +-----
arch/s390/include/asm/processor.h | 3 +--
arch/sparc/include/asm/processor_64.h | 3 ---
arch/x86/include/asm/page_64_types.h | 2 --
include/linux/sched.h | 4 ----
8 files changed, 3 insertions(+), 23 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH V2 1/8] sched: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux, now. Delete in include/linux/sched.h
and arch's include/asm. This would confuse people who are
implementing the COMPAT feature for architecture.
Here is the comment by Arnd:
Looking through the git history, I see commit a06db751c321 ("pagemap:
check permissions and capabilities at open time") removing the last
user.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
include/linux/sched.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 78c351e35fec..8e5689d06ac8 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2166,10 +2166,6 @@ static inline bool vcpu_is_preempted(int cpu)
extern long sched_setaffinity(pid_t pid, const struct cpumask *new_mask);
extern long sched_getaffinity(pid_t pid, struct cpumask *mask);
-#ifndef TASK_SIZE_OF
-#define TASK_SIZE_OF(tsk) TASK_SIZE
-#endif
-
#ifdef CONFIG_SMP
/* Returns effective CPU energy utilization, as seen by the scheduler */
unsigned long sched_cpu_util(int cpu, unsigned long max);
--
2.25.1
^ permalink raw reply related
* [PATCH V2 2/8] sched: x86: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/x86/include/asm/page_64_types.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index e9e2c3ba5923..6191cf417c31 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -74,8 +74,6 @@
IA32_PAGE_OFFSET : DEFAULT_MAP_WINDOW)
#define TASK_SIZE (test_thread_flag(TIF_ADDR32) ? \
IA32_PAGE_OFFSET : TASK_SIZE_MAX)
-#define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child, TIF_ADDR32)) ? \
- IA32_PAGE_OFFSET : TASK_SIZE_MAX)
#define STACK_TOP TASK_SIZE_LOW
#define STACK_TOP_MAX TASK_SIZE_MAX
--
2.25.1
^ permalink raw reply related
* [PATCH V2 3/8] sched: sparc: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/sparc/include/asm/processor_64.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/sparc/include/asm/processor_64.h b/arch/sparc/include/asm/processor_64.h
index ae851e8fce4c..628349fc4cdd 100644
--- a/arch/sparc/include/asm/processor_64.h
+++ b/arch/sparc/include/asm/processor_64.h
@@ -27,9 +27,6 @@
#define VPTE_SIZE (1 << (VA_BITS - PAGE_SHIFT + 3))
#endif
-#define TASK_SIZE_OF(tsk) \
- (test_tsk_thread_flag(tsk,TIF_32BIT) ? \
- (1UL << 32UL) : ((unsigned long)-VPTE_SIZE))
#define TASK_SIZE \
(test_thread_flag(TIF_32BIT) ? \
(1UL << 32UL) : ((unsigned long)-VPTE_SIZE))
--
2.25.1
^ permalink raw reply related
* [PATCH V2 4/8] sched: powerpc: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux sched, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/include/asm/task_size_64.h | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/task_size_64.h b/arch/powerpc/include/asm/task_size_64.h
index c993482237ed..38fdf8041d12 100644
--- a/arch/powerpc/include/asm/task_size_64.h
+++ b/arch/powerpc/include/asm/task_size_64.h
@@ -44,11 +44,7 @@
*/
#define TASK_SIZE_USER32 (0x0000000100000000UL - (1 * PAGE_SIZE))
-#define TASK_SIZE_OF(tsk) \
- (test_tsk_thread_flag(tsk, TIF_32BIT) ? TASK_SIZE_USER32 : \
- TASK_SIZE_USER64)
-
-#define TASK_SIZE TASK_SIZE_OF(current)
+#define TASK_SIZE (is_32bit_task() ? TASK_SIZE_USER32 : TASK_SIZE_USER64)
#define TASK_UNMAPPED_BASE_USER32 (PAGE_ALIGN(TASK_SIZE_USER32 / 4))
#define TASK_UNMAPPED_BASE_USER64 (PAGE_ALIGN(DEFAULT_MAP_WINDOW_USER64 / 4))
--
2.25.1
^ permalink raw reply related
* [PATCH V2 5/8] sched: s390: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux sched, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/s390/include/asm/processor.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index f54c152bf2bf..5581b64a4236 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -88,11 +88,10 @@ extern void __bpon(void);
* User space process size: 2GB for 31 bit, 4TB or 8PT for 64 bit.
*/
-#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_31BIT) ? \
+#define TASK_SIZE (test_thread_flag(TIF_31BIT) ? \
_REGION3_SIZE : TASK_SIZE_MAX)
#define TASK_UNMAPPED_BASE (test_thread_flag(TIF_31BIT) ? \
(_REGION3_SIZE >> 1) : (_REGION2_SIZE >> 1))
-#define TASK_SIZE TASK_SIZE_OF(current)
#define TASK_SIZE_MAX (-PAGE_SIZE)
#define STACK_TOP (test_thread_flag(TIF_31BIT) ? \
--
2.25.1
^ permalink raw reply related
* [PATCH V2 6/8] sched: parisc: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux sched, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/parisc/include/asm/processor.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/parisc/include/asm/processor.h b/arch/parisc/include/asm/processor.h
index b669f4b9040b..d9c8dc76ee6a 100644
--- a/arch/parisc/include/asm/processor.h
+++ b/arch/parisc/include/asm/processor.h
@@ -23,8 +23,7 @@
#define HAVE_ARCH_PICK_MMAP_LAYOUT
-#define TASK_SIZE_OF(tsk) ((tsk)->thread.task_size)
-#define TASK_SIZE TASK_SIZE_OF(current)
+#define TASK_SIZE (current->thread.task_size)
#define TASK_UNMAPPED_BASE (current->thread.map_base)
#define DEFAULT_TASK_SIZE32 (0xFFF00000UL)
--
2.25.1
^ permalink raw reply related
* [PATCH V2 7/8] sched: arm64: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux sched, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/include/asm/processor.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 6f41b65f9962..d24dfb49237d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -65,8 +65,6 @@
#endif /* CONFIG_ARM64_64K_PAGES */
#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)
-#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
- TASK_SIZE_32 : TASK_SIZE_64)
#define DEFAULT_MAP_WINDOW (test_thread_flag(TIF_32BIT) ? \
TASK_SIZE_32 : DEFAULT_MAP_WINDOW_64)
#else
--
2.25.1
^ permalink raw reply related
* [PATCH V2 8/8] sched: mips: Remove unused TASK_SIZE_OF
From: guoren @ 2021-12-25 4:54 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-1-guoren@kernel.org>
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux sched, now. Delete in
include/linux/sched.h and arch's include/asm.
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/mips/include/asm/processor.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/mips/include/asm/processor.h b/arch/mips/include/asm/processor.h
index 4bb24579d12e..8871fc5b0baa 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -61,9 +61,6 @@ extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src
#define TASK_SIZE (test_thread_flag(TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE64)
#define STACK_TOP_MAX TASK_SIZE64
-#define TASK_SIZE_OF(tsk) \
- (test_tsk_thread_flag(tsk, TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE64)
-
#define TASK_IS_32BIT_ADDR test_thread_flag(TIF_32BIT_ADDR)
#endif
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 4/5] powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses
From: Nicholas Piggin @ 2021-12-25 10:10 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
Cc: Aneesh Kumar K . V, Anju T Sudhakar, Madhavan Srinivasan,
Reza Arbab
In-Reply-To: <8926c850-a28b-0600-9116-1c794f80b532@csgroup.eu>
Excerpts from Christophe Leroy's message of December 24, 2021 11:24 pm:
> Hi Nic,
>
> Le 24/07/2019 à 10:46, Nicholas Piggin a écrit :
>> Ensure __va is given a physical address below PAGE_OFFSET, and __pa is
>> given a virtual address above PAGE_OFFSET.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/page.h | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
>> index 0d52f57fca04..c8bb14ff4713 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -215,9 +215,19 @@ static inline bool pfn_valid(unsigned long pfn)
>> /*
>> * gcc miscompiles (unsigned long)(&static_var) - PAGE_OFFSET
>> * with -mcmodel=medium, so we use & and | instead of - and + on 64-bit.
>> + * This also results in better code generation.
>> */
>> -#define __va(x) ((void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET))
>> -#define __pa(x) ((unsigned long)(x) & 0x0fffffffffffffffUL)
>> +#define __va(x) \
>> +({ \
>> + VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET); \
>> + (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET); \
>> +})
>> +
>> +#define __pa(x) \
>> +({ \
>> + VIRTUAL_BUG_ON((unsigned long)(x) < PAGE_OFFSET); \
>
> With this, it is likely that virt_addr_valid() BUGs on a non valid address.
>
> I think the purpose of virt_addr_valid() is to check addresses
> seamlessly, see check_heap_object()
Looks like you're right. How did you catch that?
We could change virt_addr_valid() to make that test first. x86 and arm64
both do checking rather than relying on !pfn_valid for < PAGE_OFFSET
addresses.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 1/3] KVM: PPC: Book3S HV: Stop returning internal values to userspace
From: Nicholas Piggin @ 2021-12-25 10:11 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20211223211528.3560711-2-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:15 am:
> Our kvm_arch_vcpu_ioctl_run currently returns the RESUME_HOST values
> to userspace, against the API of the KVM_RUN ioctl which returns 0 on
> success.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> This was noticed while enabling the kvm selftests for powerpc. There's
> an assert at the _vcpu_run function when we return a value different
> from the expected.
That's nasty. Looks like qemu never touches the return value except if
it was < 0, so hopefully should be okay.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kvm/powerpc.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index a72920f4f221..1e130bb087c4 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1849,6 +1849,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> #ifdef CONFIG_ALTIVEC
> out:
> #endif
> +
> + /*
> + * We're already returning to userspace, don't pass the
> + * RESUME_HOST flags along.
> + */
> + if (r > 0)
> + r = 0;
> +
> vcpu_put(vcpu);
> return r;
> }
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [PATCH 2/3] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
From: Nicholas Piggin @ 2021-12-25 10:12 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20211223211528.3560711-3-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:15 am:
> The MMIO emulation code for vector instructions is duplicated between
> VSX and VMX. When emulating VMX we should check the VMX copy size
> instead of the VSX one.
>
> Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Good catch. AFAIKS handle_vmx_store needs the same treatment? If you
agree then
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kvm/powerpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 1e130bb087c4..793d42bd6c8f 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1507,7 +1507,7 @@ int kvmppc_handle_vmx_load(struct kvm_vcpu *vcpu,
> {
> enum emulation_result emulated = EMULATE_DONE;
>
> - if (vcpu->arch.mmio_vsx_copy_nums > 2)
> + if (vcpu->arch.mmio_vmx_copy_nums > 2)
> return EMULATE_FAIL;
>
> while (vcpu->arch.mmio_vmx_copy_nums) {
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Fix mmio length message
From: Nicholas Piggin @ 2021-12-25 10:16 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <20211223211528.3560711-4-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:15 am:
> We check against 'bytes' but print 'run->mmio.len' which at that point
> has an old value.
>
> e.g. 16-byte load:
>
> before:
> __kvmppc_handle_load: bad MMIO length: 8
>
> now:
> __kvmppc_handle_load: bad MMIO length: 16
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
This patch fine, but in the case of overflow we continue anyway here.
Can that overwrite some other memory in the kvm_run struct?
This is familiar, maybe something Alexey has noticed in the past too?
What was the consensus on fixing it? (at least it should have a comment
if it's not a problem IMO)
Thanks,
Nick
> ---
> arch/powerpc/kvm/powerpc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 793d42bd6c8f..7823207eb8f1 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -1246,7 +1246,7 @@ static int __kvmppc_handle_load(struct kvm_vcpu *vcpu,
>
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> - run->mmio.len);
> + bytes);
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
> @@ -1335,7 +1335,7 @@ int kvmppc_handle_store(struct kvm_vcpu *vcpu,
>
> if (bytes > sizeof(run->mmio.data)) {
> printk(KERN_ERR "%s: bad MMIO length: %d\n", __func__,
> - run->mmio.len);
> + bytes);
> }
>
> run->mmio.phys_addr = vcpu->arch.paddr_accessed;
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [PATCH 1/3] KVM: PPC: Book3S HV: Check return value of kvmppc_radix_init
From: Nicholas Piggin @ 2021-12-25 10:17 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20211223211931.3560887-2-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:19 am:
> The return of the function is being shadowed by the call to
> kvmppc_uvmem_init.
>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> Fixes: ca9f4942670c ("KVM: PPC: Book3S HV: Support for running secure guests")
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 7b74fc0a986b..9f4765951733 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6098,8 +6098,11 @@ static int kvmppc_book3s_init_hv(void)
> if (r)
> return r;
>
> - if (kvmppc_radix_possible())
> + if (kvmppc_radix_possible()) {
> r = kvmppc_radix_init();
> + if (r)
> + return r;
> + }
>
> r = kvmppc_uvmem_init();
> if (r < 0)
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [PATCH 2/3] KVM: PPC: Book3S HV: Delay setting of kvm ops
From: Nicholas Piggin @ 2021-12-25 10:19 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20211223211931.3560887-3-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:19 am:
> Delay the setting of kvm_hv_ops until after all init code has
> completed. This avoids leaving the ops still accessible if the init
> fails.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Also looks okay to me but KVM init has lots of details. IIRC Alexey may
have run into a related issue with ops being set too early (or was it
cleared too late?)
Thanks,
Nick
> ---
> arch/powerpc/kvm/book3s_hv.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 9f4765951733..53400932f5d8 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6087,9 +6087,6 @@ static int kvmppc_book3s_init_hv(void)
> }
> #endif
>
> - kvm_ops_hv.owner = THIS_MODULE;
> - kvmppc_hv_ops = &kvm_ops_hv;
> -
> init_default_hcalls();
>
> init_vcore_lists();
> @@ -6105,10 +6102,15 @@ static int kvmppc_book3s_init_hv(void)
> }
>
> r = kvmppc_uvmem_init();
> - if (r < 0)
> + if (r < 0) {
> pr_err("KVM-HV: kvmppc_uvmem_init failed %d\n", r);
> + return r;
> + }
>
> - return r;
> + kvm_ops_hv.owner = THIS_MODULE;
> + kvmppc_hv_ops = &kvm_ops_hv;
> +
> + return 0;
> }
>
> static void kvmppc_book3s_exit_hv(void)
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S HV: Free allocated memory if module init fails
From: Nicholas Piggin @ 2021-12-25 10:22 UTC (permalink / raw)
To: Fabiano Rosas, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20211223211931.3560887-4-farosas@linux.ibm.com>
Excerpts from Fabiano Rosas's message of December 24, 2021 7:19 am:
> The module's exit function is not called when the init fails, we need
> to do cleanup before returning.
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 53400932f5d8..2d79298e7ca4 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6065,7 +6065,7 @@ static int kvmppc_book3s_init_hv(void)
>
> r = kvm_init_subcore_bitmap();
> if (r)
> - return r;
> + goto err;
>
> /*
> * We need a way of accessing the XICS interrupt controller,
> @@ -6080,7 +6080,8 @@ static int kvmppc_book3s_init_hv(void)
> np = of_find_compatible_node(NULL, NULL, "ibm,opal-intc");
> if (!np) {
> pr_err("KVM-HV: Cannot determine method for accessing XICS\n");
> - return -ENODEV;
> + r = -ENODEV;
> + goto err;
> }
> /* presence of intc confirmed - node can be dropped again */
> of_node_put(np);
> @@ -6093,12 +6094,12 @@ static int kvmppc_book3s_init_hv(void)
>
> r = kvmppc_mmu_hv_init();
> if (r)
> - return r;
> + goto err;
>
> if (kvmppc_radix_possible()) {
> r = kvmppc_radix_init();
> if (r)
> - return r;
> + goto err;
> }
>
> r = kvmppc_uvmem_init();
> @@ -6111,6 +6112,12 @@ static int kvmppc_book3s_init_hv(void)
> kvmppc_hv_ops = &kvm_ops_hv;
>
> return 0;
> +
> +err:
> + kvmhv_nested_exit();
> + kvmppc_radix_exit();
These should both be callable without init functions succeeding
so this looks right to me.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Thanks,
Nick
> +
> + return r;
> }
>
> static void kvmppc_book3s_exit_hv(void)
> --
> 2.33.1
>
>
^ permalink raw reply
* Re: [BISECTED] power8: watchdog: CPU 3 self-detected hard LOCKUP @ queued_spin_lock_slowpath+0x154/0x2d0
From: Nicholas Piggin @ 2021-12-25 10:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Davidlohr Bueso,
linuxppc-dev, Michael Ellerman, Paul Mackerras, Stijn Tintel
In-Reply-To: <c9abdadc-bc38-dbba-7f96-1ce15db8ab79@linux-ipv6.be>
Excerpts from Stijn Tintel's message of December 22, 2021 11:20 am:
> Hi,
>
> After upgrading my Power8 server from 5.10 LTS to 5.15 LTS, I started
> experiencing CPU hard lockups, usually rather quickly after boot:
>
>
> watchdog: CPU 3 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x154/0x2d0
> watchdog: CPU 3 TB:265651929071, last heartbeat TB:259344820187 (12318ms
> ago)
> watchdog: CPU 4 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x22c/0x2d0
> watchdog: CPU 4 TB:265651929059, last heartbeat TB:259344820045 (12318ms
> ago)
> watchdog: CPU 5 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 5 TB:265651929037, last heartbeat TB:259349940303 (12308ms
> ago)
> watchdog: CPU 6 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x144/0x2d0
> watchdog: CPU 6 TB:265651929056, last heartbeat TB:259349940294 (12308ms
> ago)
> watchdog: CPU 12 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x280/0x2d0
> watchdog: CPU 12 TB:242479050267, last heartbeat TB:236822174350
> (11048ms ago)
> watchdog: CPU 26 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x22c/0x2d0
> watchdog: CPU 26 TB:265657049348, last heartbeat TB:259355060595
> (12308ms ago)
> watchdog: CPU 40 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 40 TB:265657049289, last heartbeat TB:259360180427
> (12298ms ago)
> watchdog: CPU 47 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x21c/0x2d0
> watchdog: CPU 47 TB:265657049213, last heartbeat TB:259365300321
> (12288ms ago)
> watchdog: CPU 60 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 60 TB:265651929348, last heartbeat TB:259370420527
> (12268ms ago)
> watchdog: CPU 72 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 72 TB:265718488733, last heartbeat TB:259375540545
> (12388ms ago)
> watchdog: CPU 13 detected hard LOCKUP on other CPUs 0-2,7,10,44
> watchdog: CPU 13 TB:267541867921, last SMP heartbeat TB:259380660378
> (15939ms ago)
> watchdog: CPU 34 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 34 TB:269913954376, last heartbeat TB:263456144470
> (12612ms ago)
> watchdog: CPU 41 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 41 TB:267865972392, last heartbeat TB:261408162383
> (12612ms ago)
> watchdog: CPU 74 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 74 TB:267766470637, last heartbeat TB:261423522630
> (12388ms ago)
> watchdog: CPU 8 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 8 TB:274978264599, last heartbeat TB:269237436681 (11212ms
> ago)
> watchdog: CPU 9 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 9 TB:268029810836, last heartbeat TB:261397922093 (12952ms
> ago)
> watchdog: CPU 11 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 11 TB:279685725759, last heartbeat TB:273685814104
> (11718ms ago)
> watchdog: CPU 16 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 16 TB:267865972449, last heartbeat TB:261397922458
> (12632ms ago)
> watchdog: CPU 18 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 18 TB:269913954314, last heartbeat TB:263445904285
> (12632ms ago)
> watchdog: CPU 24 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 24 TB:267865972338, last heartbeat TB:261403042311
> (12622ms ago)
> watchdog: CPU 31 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x22c/0x2d0
> watchdog: CPU 31 TB:268029811095, last heartbeat TB:261403042673
> (12942ms ago)
> watchdog: CPU 32 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 32 TB:267865972528, last heartbeat TB:261403042589
> (12622ms ago)
> watchdog: CPU 33 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 33 TB:268029811013, last heartbeat TB:261408162474
> (12932ms ago)
> watchdog: CPU 35 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 35 TB:280174344471, last heartbeat TB:273696054625
> (12652ms ago)
> watchdog: CPU 37 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x230/0x2d0
> watchdog: CPU 37 TB:269913954356, last heartbeat TB:263456144501
> (12612ms ago)
> watchdog: CPU 38 self-detected hard LOCKUP @
> queued_spin_lock_slowpath+0x228/0x2d0
> watchdog: CPU 38 TB:290393774681, last heartbeat TB:283946212510
> (12592ms ago)
>
> Bisecting lead to the following commit:
>
> deb9b13eb2571fbde164ae012c77985fd14f2f02 is the first bad commit
> commit deb9b13eb2571fbde164ae012c77985fd14f2f02
> Author: Davidlohr Bueso <dave@stgolabs.net>
> Date: Mon Mar 8 17:59:50 2021 -0800
>
> powerpc/qspinlock: Use generic smp_cond_load_relaxed
Thanks for bisecting and reporting this.
As far as I can see, the code should be functionally identical,
the difference is slightly in loop structure and priority nops
but that shouldn't cause complete lock ups.
I suspect possibly something is getting miscompiled. What distro
do you use, what gcc version? And would you be able to send the
output of objdump --disassemble=queued_spin_lock_slowpath vmlinux
for your bad kernel?
Thanks,
Nick
>
>
> The problem persists in 2f47a9a4dfa3674fad19a49b40c5103a9a8e1589 and
> goes away if I revert deb9b13eb2571fbde164ae012c77985fd14f2f02 on top of
> that. As deb9b13eb2571fbde164ae012c77985fd14f2f02 seems to be a revert
> of 49a7d46a06c30c7beabbf9d1a8ea1de0f9e4fdfe, I suspect this problem
> might have existed before 49a7d46a06c30c7beabbf9d1a8ea1de0f9e4fdfe. I
> therefore tried to build 49a7d46a06c30c7beabbf9d1a8ea1de0f9e4fdfe and
> 49a7d46a06c30c7beabbf9d1a8ea1de0f9e4fdfe^1 to verify if the problem
> exists there as well, unfortunately these commits don't build due to the
> following compile error:
>
> kernel/smp.c:In function 'smp_init':
> ./include/linux/compiler.h:392:38:error: call to
> '__compiletime_assert_150' declared with attribute error: BUILD_BUG_ON
> failed: offsetof(struct task_struct, wake_entry_type) - offsetof(struct
> task_struct, wake_entry) != offsetof(struct __call_single_data, flags) -
> offsetof(struct __call_single_data, llist)
> 392 | _compiletime_assert(condition, msg, __compiletime_assert_,
> __COUNTER__)
> | ^
>
> Is this report enough to revert deb9b13eb2571fbde164ae012c77985fd14f2f02
> for now?
>
> Stijn
>
>
^ permalink raw reply
* Re: [PATCH] Revert "mm/usercopy: Drop extra is_vmalloc_or_module() check"
From: Nicholas Piggin @ 2021-12-25 11:04 UTC (permalink / raw)
To: Andrew, Morton, Benjamin Herrenschmidt, Christophe Leroy,
Kees Cook, Laura Abbott, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Mark Rutland,
Michael Ellerman, Paul Mackerras, Kefeng Wang
In-Reply-To: <ccf311bd-c0ed-3e42-8057-849a9c3e9a98@huawei.com>
Excerpts from Kefeng Wang's message of December 25, 2021 12:05 pm:
>
> On 2021/12/24 21:18, Christophe Leroy wrote:
>>
>> Le 24/12/2021 à 08:06, Kefeng Wang a écrit :
>>> On 2021/12/24 14:01, Christophe Leroy wrote:
>>>> Le 23/12/2021 à 11:21, Kefeng Wang a écrit :
>>>>> This reverts commit 517e1fbeb65f5eade8d14f46ac365db6c75aea9b.
>>>>>
>>>>> 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
>>>>>
>>>>> When run ethtool eth0, the BUG occurred, 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, add back the
>>>>> is_vmalloc_or_module()
>>>>> check to fix it.
>>>> Is it expected that virt_addr_valid() returns true on PPC64 for
>>>> vmalloc'ed memory ? If that's the case it also means that
>>>> CONFIG_DEBUG_VIRTUAL won't work as expected either.
>>> Our product reports this bug to me, after let them do some test,
>>>
>>> I found virt_addr_valid return true for vmalloc'ed memory on their board.
>>>
>>> I think DEBUG_VIRTUAL could not be work well too, but I can't test it.
>>>
>>>> If it is unexpected, I think you should fix PPC64 instead of adding this
>>>> hack back. Maybe the ARM64 fix can be used as a starting point, see
>>>> commit 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using
>>>> __is_lm_address()")
>>> Yes， I check the history, fix virt_addr_valid() on PowerPC is what I
>>> firstly want to do,
>>>
>>> but I am not familiar with PPC, and also HARDENED_USERCOPY on other's
>>> ARCHs could
>>>
>>> has this issue too, so I add the workaround back.
>>>
>>>
>>> 1) PPC maintainer/expert, any suggestion ?
>>>
>>> 2) Maybe we could add some check to WARN this scenario.
>>>
>>> --- a/mm/usercopy.c
>>> +++ b/mm/usercopy.c
>>> @@ -229,6 +229,8 @@ static inline void check_heap_object(const void
>>> *ptr, unsigned long n,
>>> if (!virt_addr_valid(ptr))
>>> return;
>>>
>>> + WARN_ON_ONCE(is_vmalloc_or_module_addr(ptr));
>
>>>
>>>> In the meantime, can you provide more information on your config,
>>>> especially which memory model is used ?
>>> Some useful configs,
>>>
>>> CONFIG_PPC64=y
>>> CONFIG_PPC_BOOK3E_64=y
>>> CONFIG_E5500_CPU=y
>>> CONFIG_TARGET_CPU_BOOL=y
>>> CONFIG_PPC_BOOK3E=y
>>> CONFIG_E500=y
>>> CONFIG_PPC_E500MC=y
>>> CONFIG_PPC_FPU=y
>>> CONFIG_FSL_EMB_PERFMON=y
>>> CONFIG_FSL_EMB_PERF_EVENT=y
>>> CONFIG_FSL_EMB_PERF_EVENT_E500=y
>>> CONFIG_BOOKE=y
>>> CONFIG_PPC_FSL_BOOK3E=y
>>> CONFIG_PTE_64BIT=y
>>> CONFIG_PHYS_64BIT=y
>>> CONFIG_PPC_MMU_NOHASH=y
>>> CONFIG_PPC_BOOK3E_MMU=y
>>> CONFIG_SELECT_MEMORY_MODEL=y
>>> CONFIG_FLATMEM_MANUAL=y
>>> CONFIG_FLATMEM=y
>>> CONFIG_FLAT_NODE_MEM_MAP=y
>>> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
>>>
>> OK so it is PPC64 book3e and with flatmem.
>>
>> The problem is virt_to_pfn() which uses __pa()
>>
>> __pa(x) on PPC64 is (x) & 0x0fffffffffffffffUL
>>
>> And on book3e/64 we have
>>
>> VMALLOC_START = KERN_VIRT_START = ASM_CONST(0x8000000000000000)
>>
>>
>> It means that __pa() will return a valid PFN for VMALLOCed addresses.
>>
>>
>> So an additional check is required in virt_addr_valid(), maybe check
>> that (kaddr & PAGE_OFFSET) == PAGE_OFFSET
>>
>> Can you try that ?
>>
>> #define virt_addr_valid(kaddr) ((kaddr & PAGE_OFFSET) == PAGE_OFFSET &&
>> pfn_valid(virt_to_pfn(kaddr)))
>
> I got this commit,
>
> commit 4dd7554a6456d124c85e0a4ad156625b71390b5c
>
> Author: Nicholas Piggin <npiggin@gmail.com>
> Date: Wed Jul 24 18:46:37 2019 +1000
>
> powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses
>
> Ensure __va is given a physical address below PAGE_OFFSET, and __pa is
> given a virtual address above PAGE_OFFSET.
>
> It has check the PAGE_OFFSET in __pa, will test it and resend the
> patch(with above warning changes).
What did you get with this commit? Is this what causes the crash?
riscv for example with flatmem also relies on pfn_valid to do the right
thing, so as far as I can see the check should exclude vmalloc addresses
and it's just a matter of virt_addr_valid not to give virt_to_pfn an
address < PAGE_OFFSET.
If we take riscv's implementation
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 254687258f42..7713188516a6 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -132,7 +132,10 @@ 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; \
+ (unsigned long)(_addr) >= PAGE_OFFSET && pfn_valid(virt_to_pfn(_addr)); \
+})
/*
* On Book-E parts we need __va to parse the device tree and we can't
^ permalink raw reply related
* [PATCH v2 2/2] mm: usercopy: Warn vmalloc/module address in check_heap_object()
From: Kefeng Wang @ 2021-12-25 12:06 UTC (permalink / raw)
To: Kees Cook, Laura Abbott, Mark Rutland, linux-mm, Andrew Morton,
linux-kernel, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
Cc: Kefeng Wang, Nicholas Piggin
In-Reply-To: <20211225120621.13908-1-wangkefeng.wang@huawei.com>
virt_addr_valid() could be insufficient to validate the virt addr
on some architecture, which could lead to potential BUG which has
been found on arm64/powerpc64.
Let's add WARN_ON to check if the virt addr is passed virt_addr_valid()
but is a vmalloc/module address.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
mm/usercopy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/usercopy.c b/mm/usercopy.c
index b3de3c4eefba..ce83e0b137dd 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -228,6 +228,8 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
if (!virt_addr_valid(ptr))
return;
+ WARN_ON_ONCE(is_vmalloc_or_module_addr(ptr));
+
/*
* When CONFIG_HIGHMEM=y, kmap_to_page() will give either the
* highmem page or fallback to virt_to_page(). The following
--
2.26.2
^ permalink raw reply related
* [PATCH v2 0/2] mm: Fix kernel BUG in __check_heap_object() on PowerPC64
From: Kefeng Wang @ 2021-12-25 12:06 UTC (permalink / raw)
To: Kees Cook, Laura Abbott, Mark Rutland, linux-mm, Andrew Morton,
linux-kernel, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
Cc: Kefeng Wang, Nicholas Piggin
v2:
- Fix powerpc virt_addr_valid() instead of workaround in
check_heap_object(), suggested by Christophe and Nicholas
- Add WARN_ON in check_heap_object() incase of virt_addr_valid is
insufficient on some archs
Kefeng Wang (2):
powerpc: Fix virt_addr_valid() check
mm: usercopy: Warn vmalloc/module address in check_heap_object()
arch/powerpc/include/asm/page.h | 5 ++++-
mm/usercopy.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
--
2.26.2
^ permalink raw reply
* [PATCH v2 1/2] powerpc: Fix virt_addr_valid() check
From: Kefeng Wang @ 2021-12-25 12:06 UTC (permalink / raw)
To: Kees Cook, Laura Abbott, Mark Rutland, linux-mm, Andrew Morton,
linux-kernel, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
Cc: Kefeng Wang, Nicholas Piggin
In-Reply-To: <20211225120621.13908-1-wangkefeng.wang@huawei.com>
When run ethtool eth0, 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().
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
arch/powerpc/include/asm/page.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 254687258f42..300d4c105a3a 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -132,7 +132,10 @@ 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; \
+ (unsigned long)(_addr) >= PAGE_OFFSET && 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] Revert "mm/usercopy: Drop extra is_vmalloc_or_module() check"
From: Kefeng Wang @ 2021-12-25 12:00 UTC (permalink / raw)
To: Nicholas Piggin, Andrew Morton, Benjamin Herrenschmidt,
Christophe Leroy, Kees Cook, Laura Abbott,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, Mark Rutland, Michael Ellerman,
Paul Mackerras
In-Reply-To: <1640429980.38ev9qg7xc.astroid@bobo.none>
On 2021/12/25 19:04, Nicholas Piggin wrote:
> Excerpts from Kefeng Wang's message of December 25, 2021 12:05 pm:
>
...
>>> Can you try that ?
>>>
>>> #define virt_addr_valid(kaddr) ((kaddr & PAGE_OFFSET) == PAGE_OFFSET &&
>>> pfn_valid(virt_to_pfn(kaddr)))
>> I got this commit,
>>
>> commit 4dd7554a6456d124c85e0a4ad156625b71390b5c
>>
>> Author: Nicholas Piggin <npiggin@gmail.com>
>> Date: Wed Jul 24 18:46:37 2019 +1000
>>
>> powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses
>>
>> Ensure __va is given a physical address below PAGE_OFFSET, and __pa is
>> given a virtual address above PAGE_OFFSET.
>>
>> It has check the PAGE_OFFSET in __pa, will test it and resend the
>> patch(with above warning changes).
> What did you get with this commit? Is this what causes the crash?
I mean that your patch does the check to make sure the virt addr should
above PAGE_OFFSET,
and we can add the check in the virt_addr_valid too.
>
> riscv for example with flatmem also relies on pfn_valid to do the right
> thing, so as far as I can see the check should exclude vmalloc addresses
> and it's just a matter of virt_addr_valid not to give virt_to_pfn an
> address < PAGE_OFFSET.
>
> If we take riscv's implementation
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 254687258f42..7713188516a6 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -132,7 +132,10 @@ 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; \
> + (unsigned long)(_addr) >= PAGE_OFFSET && pfn_valid(virt_to_pfn(_addr)); \
> +})
Yes, I send a new v2 with this change, thanks
>
> /*
> * On Book-E parts we need __va to parse the device tree and we can't
>
> .
^ permalink raw reply
* Re: [PATCH V2 5/8] sched: s390: Remove unused TASK_SIZE_OF
From: Heiko Carstens @ 2021-12-25 16:25 UTC (permalink / raw)
To: guoren
Cc: juri.lelli, linux-s390, x86, arnd, peterz, linuxppc-dev, Guo Ren,
linux-kernel, inux-parisc, mingo, sparclinux, tglx, linux-mips,
will, linux-riscv, linux-arm-kernel
In-Reply-To: <20211225045430.2868608-6-guoren@kernel.org>
On Sat, Dec 25, 2021 at 12:54:27PM +0800, guoren@kernel.org wrote:
> From: Guo Ren <guoren@linux.alibaba.com>
>
> This macro isn't used in Linux sched, now. Delete in
> include/linux/sched.h and arch's include/asm.
>
> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/s390/include/asm/processor.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
I could pick this up for s390, however sender (From: field) of this patch
series does not match From: and Signed-off-by: fields above.
In general I don't pick up such patches, since this doesn't match the
"Developer's Certificate of Origin" requirements.
-> Documentation/process/submitting-patches.rst
^ permalink raw reply
* Re: code conditional on non-existing PPC_EARLY_DEBUG_MICROWATT.
From: Michael Ellerman @ 2021-12-25 22:42 UTC (permalink / raw)
To: Christophe Leroy, Lukas Bulwahn, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev@lists.ozlabs.org
Cc: kernel-janitors, Linux Kernel Mailing List
In-Reply-To: <27eefbf2-fc2c-7800-1397-8acfea7ed7e8@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 23/12/2021 à 11:21, Lukas Bulwahn a écrit :
>> Dear Benjamin, dear Paul, dear Michael,
>>
>> with commit 48b545b8018d ("powerpc/microwatt: Use standard 16550 UART
>> for console"), you have some code in arch/powerpc/kernel/udbg_16550.c,
>> conditional on the Kconfig symbol PPC_EARLY_DEBUG_MICROWATT. However,
>> since then, the definition of this Kconfig symbol was never introduced
>> to the mainline repository or current linux-next, nor am I finding any
>> pending patch for that.
>>
>> Are you going to add this config definition soon? Or did you identify
>> that this setup code in udbg_16550.c is not actually needed and can we
>> simply drop this code again?
>>
>> This issue was identified with the script ./scripts/checkkconfigsymbols.py.
>>
>
> Was it forgotten when handling comments to
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200509050340.GD1464954@thinks.paulus.ozlabs.org/
> ?
Yes. I reported it internally to some folks but I guess they haven't had
time to send a fixup patch.
I'm pretty sure we just need the first three hunks of that patch, but it
would be good if someone with a Microwatt setup could test it.
cheers
^ permalink raw reply
* [PATCH 2/3] arm64: Support huge vmalloc mappings
From: Kefeng Wang @ 2021-12-26 8:39 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Kefeng Wang, Catalin Marinas, Dave Hansen, Nicholas Piggin,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Paul Mackerras,
Thomas Gleixner, Will Deacon
In-Reply-To: <20211226083912.166512-1-wangkefeng.wang@huawei.com>
This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
vmalloc mappings, it is disabled by default, use hugevmalloc=on to
enable it in some scenarios.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/arm64/Kconfig | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4107136097a6..235a23b08809 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1630,7 +1630,7 @@
precedence over memory_hotplug.memmap_on_memory.
- hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+ hugevmalloc= [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
Format: { on | off }
Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
@@ -3415,7 +3415,7 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
- nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
+ nohugevmalloc [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c4207cf9bb17..6cedb06b4cab 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -143,6 +143,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_COMPILER_H
+ select HAVE_ARCH_HUGE_VMALLOC
select HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
--
2.26.2
^ permalink raw reply related
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