Re: [PATCH 26/26] KVM: Hide KVM internal data structures and values from kernel at-large

On Sat, Sep 16, 2023 at 6:02 AM Sean Christopherson wrote: > > Wrap all KVM internal APIs, data structures, values, etc. in public > headers with "#ifdef __KVM__" to effectively hide KVM's internal details > from other subsystems and the kernel at-large. Hiding KVM details for > all

Re: [PATCH 22/26] entry/kvm: KVM: Move KVM details related to signal/-EINTR into KVM proper

On Sat, Sep 16, 2023 at 6:02 AM Sean Christopherson wrote: > > Move KVM's morphing of pending signals into exits to userspace into KVM > proper, and drop the @vcpu param from xfer_to_guest_mode_handle_work(). > How KVM responds to -EINTR is a detail that really belongs in KVM itself, > and

Re: [PATCH v3 04/11] leds: aw2013: use devm API to cleanup module's resources

George Stark писал(а) 14.12.2023 03:30: > In this driver LEDs are registered using devm_led_classdev_register() > so they are automatically unregistered after module's remove() is done. > led_classdev_unregister() calls module's led_set_brightness() to turn off > the LEDs and that callback uses

Re: [PATCH 19/26] KVM: Standardize include paths across all architectures

On Sat, Sep 16, 2023 at 6:01 AM Sean Christopherson wrote: > > Standardize KVM's include paths across all architectures by declaring > the KVM-specific includes in the common Makefile.kvm. Having common KVM > "own" the included paths reduces the temptation to unnecessarily add > virt/kvm to arch

Re: [PATCH 15/26] KVM: Move include/kvm/iodev.h to include/linux as kvm_iodev.h

On Sat, Sep 16, 2023 at 6:01 AM Sean Christopherson wrote: > > Move iodev.h, the last remaining holdout in include/kvm, to the standard > include/linux directory as kvm_iodev.h and delete include/kvm. > > Signed-off-by: Sean Christopherson For KVM RISC-V: Acked-by: Anup Patel Regards, Anup >

[PATCH 01/13] kmsan: Export kmsan_handle_dma

kmsan_handle_dma is required by virtio drivers. Export kmsan_handle_dma so that the drivers can be compiled as modules. Signed-off-by: Nicholas Miehlbradt --- mm/kmsan/hooks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c index

[PATCH 05/13] powerpc: Unpoison buffers populated by hcalls

plpar_hcall provides to the hypervisor a buffer where return data should be placed. The hypervisor initializes the buffers which is not visible to KMSAN so unpoison them manually. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/platforms/pseries/hvconsole.c | 2 ++

[PATCH 07/13] powerpc/kprobes: Unpoison instruction in kprobe struct

KMSAN does not unpoison the ainsn field of a kprobe struct correctly. Manually unpoison it to prevent false positives. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/kernel/kprobes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/kprobes.c

[PATCH 10/13] powerpc: Define KMSAN metadata address ranges for vmalloc and ioremap

Splits the vmalloc region into four. The first quarter is the new vmalloc region, the second is used to store shadow metadata and the third is used to store origin metadata. The fourth quarter is unused. Do the same for the ioremap region. Module data is stored in the vmalloc region so alias the

[PATCH 11/13] powerpc: Implement architecture specific KMSAN interface

arch_kmsan_get_meta_or_null finds the metadata addresses for addresses in the ioremap region which is mapped separately on powerpc. kmsan_vir_addr_valid is the same as virt_addr_valid except excludes the check that addr is less than high_memory since this function can be called on addresses

[PATCH 06/13] powerpc/pseries/nvram: Unpoison buffer populated by rtas_call

rtas_call provides a buffer where the return data should be placed. Rtas initializes the buffer which is not visible to KMSAN so unpoison it manually. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/platforms/pseries/nvram.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 12/13] powerpc/string: Add KMSAN support

KMSAN expects functions __mem{set,cpy,move} so add aliases pointing to the respective functions. Disable use of architecture specific memset{16,32,64} to ensure that metadata is correctly updated and strn{cpy,cmp} and mem{chr,cmp} which are implemented in assembly and therefore cannot be

[PATCH 13/13] powerpc: Enable KMSAN on powerpc

Enable KMSAN in the Kconfig. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e33e3250c478..71cc7d2a0a72 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -217,6 +217,7

[PATCH 08/13] powerpc: Unpoison pt_regs

pt_regs is initialized ppc_save_regs which is implemented in assembly and therefore does not mark the struct as initialized. Unpoison it so that it will not generate false positives. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/include/asm/interrupt.h | 2 ++ arch/powerpc/kernel/irq_64.c

[PATCH 09/13] powerpc: Disable KMSAN checks on functions which walk the stack

Functions which walk the stack read parts of the stack which cannot be instrumented by KMSAN e.g. the backchain. Disable KMSAN sanitization of these functions to prevent false positives. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/kernel/process.c| 6 +++---

[PATCH 00/13] kmsan: Enable on powerpc

This series provides the minimal support for Kernal Memory Sanitizer on powerpc pseries le guests. Kernal Memory Sanitizer is a tool which detects uses of uninitialized memory. Currently KMSAN is clang only. The clang support for powerpc has not yet been merged, the pull request can be found

[PATCH 02/13] hvc: Fix use of uninitialized array in udbg_hvc_putc

All elements of bounce_buffer are eventually read and passed to the hypervisor so it should probably be fully initialized. Signed-off-by: Nicholas Miehlbradt --- drivers/tty/hvc/hvc_vio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/hvc/hvc_vio.c

[PATCH 03/13] powerpc: Disable KMSAN santitization for prom_init, vdso and purgatory

Other sanitizers are disabled for these, disable KMSAN too. prom_init.o can only reference a limited set of external symbols. KMSAN adds additional references which are not permitted so disable sanitization. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/kernel/Makefile | 2 ++

[PATCH 04/13] powerpc: Disable CONFIG_DCACHE_WORD_ACCESS when KMSAN is enabled

Word sized accesses may read uninitialized data when optimizing loads. Disable this optimization when KMSAN is enabled to prevent false positives. Signed-off-by: Nicholas Miehlbradt --- arch/powerpc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig

Re: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

Samuel Holland writes: > On 2023-12-11 6:23 AM, Michael Ellerman wrote: >> Hi Samuel, >> >> Thanks for trying to clean all this up. >> >> One problem below. >> >> Samuel Holland writes: >>> Now that all previously-supported architectures select >>> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can

Re: [PATCH] scsi: ibmvscsi: replace deprecated strncpy with strscpy

On Mon, 30 Oct 2023 20:40:48 +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect partition_name to be NUL-terminated based on its usage with >

Re: [PATCH] scsi: ibmvfc: replace deprecated strncpy with strscpy

On Mon, 30 Oct 2023 19:04:33 +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect these fields to be NUL-terminated as the property names from >

Re: [PATCH] scsi: ipr: Remove obsolete check for old CPUs

On Mon, 27 Nov 2023 22:17:40 +1100, Michael Ellerman wrote: > The IPR driver has a routine to check whether it's running on certain > CPU versions and if so whether the adapter is supported on that CPU. > > But none of the CPUs it checks for are supported by Linux anymore. > > The most recent

Re: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

- Original Message - > From: "Samuel Holland" > To: "Michael Ellerman" > Cc: "linux-kernel" , "amd-gfx" > , "linux-arch" > , "linux-arm-kernel" > , loonga...@lists.linux.dev, > "linuxppc-dev" , "x86" , > linux-ri...@lists.infradead.org, "Christoph > Hellwig" , "Timothy Pearson" >

Re: [PATCH v3 02/11] locking: add define if mutex_destroy() is not an empty function

On 12/13/23 17:30, George Stark wrote: mutex_destroy() is only a debug helper and an empty function on non-debug configurations still we can't legally ignore it because it's the established API call and it can be extended theoretically in the future. Sometimes it could be useful to know e.g.

Re: [RFC PATCH 10/12] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

On 2023-12-11 6:23 AM, Michael Ellerman wrote: > Hi Samuel, > > Thanks for trying to clean all this up. > > One problem below. > > Samuel Holland writes: >> Now that all previously-supported architectures select >> ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead >> of

Re: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()

On Thu, Dec 14, 2023, Maxim Levitsky wrote: > On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote: > > On Sun, Dec 10, 2023, Jim Mattson wrote: > > > On Thu, Dec 7, 2023 at 8:21 AM Sean Christopherson > > > wrote: > > > > Doh. We got the less obvious cases and missed the obvious one. >

Re: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()

On Wed, 2023-12-13 at 14:31 -0800, Jim Mattson wrote: > On Wed, Dec 13, 2023 at 2:25 PM Maxim Levitsky wrote: > > On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote: > > > On Sun, Dec 10, 2023, Jim Mattson wrote: > > > > On Thu, Dec 7, 2023 at 8:21 AM Sean Christopherson > > > >

Re: [PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

On Thu, Dec 14, 2023 at 12:36 AM Andy Shevchenko wrote: > On Thu, Dec 14, 2023 at 12:30 AM George Stark > wrote: > > > > Using of devm API leads to a certain order of releasing resources. > > So all dependent resources which are not devm-wrapped should be deleted > > with respect to

Re: [PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

On Thu, Dec 14, 2023 at 12:30 AM George Stark wrote: > > Using of devm API leads to a certain order of releasing resources. > So all dependent resources which are not devm-wrapped should be deleted > with respect to devm-release order. Mutex is one of such objects that > often is bound to other

Re: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()

On Wed, Dec 13, 2023 at 2:25 PM Maxim Levitsky wrote: > > On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote: > > On Sun, Dec 10, 2023, Jim Mattson wrote: > > > On Thu, Dec 7, 2023 at 8:21 AM Sean Christopherson > > > wrote: > > > > Doh. We got the less obvious cases and missed the

[PATCH v3 00/11] devm_led_classdev_register() usage problem

This patch series fixes the problem of devm_led_classdev_register misusing. The basic problem is described in [1]. Shortly when devm_led_classdev_register() is used then led_classdev_unregister() called after driver's remove() callback. led_classdev_unregister() calls driver's brightness_set

[PATCH v3 01/11] leds: aw2013: unlock mutex before destroying it

In the probe() callback in case of error mutex is destroyed being locked which is not allowed so unlock the mutex before destroying. Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Signed-off-by: George Stark Reviewed-by: Andy Shevchenko --- drivers/leds/leds-aw2013.c | 1 + 1 file changed, 1

[PATCH v3 04/11] leds: aw2013: use devm API to cleanup module's resources

In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's

[PATCH v3 02/11] locking: add define if mutex_destroy() is not an empty function

mutex_destroy() is only a debug helper and an empty function on non-debug configurations still we can't legally ignore it because it's the established API call and it can be extended theoretically in the future. Sometimes it could be useful to know e.g. in the higher-level API if mutex_destroy()

[PATCH v3 03/11] devm-helpers: introduce devm_mutex_init

Using of devm API leads to a certain order of releasing resources. So all dependent resources which are not devm-wrapped should be deleted with respect to devm-release order. Mutex is one of such objects that often is bound to other resources and has no own devm wrapper. Since mutex_destroy()

Re: [PATCH v4 10/12] KVM: x86: never write to memory from kvm_vcpu_check_block()

On Tue, 2023-12-12 at 07:28 -0800, Sean Christopherson wrote: > On Sun, Dec 10, 2023, Jim Mattson wrote: > > On Thu, Dec 7, 2023 at 8:21 AM Sean Christopherson > > wrote: > > > Doh. We got the less obvious cases and missed the obvious one. > > > > > > Ugh, and we also missed a related mess in

[PATCH] powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV

When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer execption. Here is the complete stack [ 19.944378] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)^M [ 19.944388] BUG: Kernel NULL pointer dereference on read at 0x^M [

Re: [RFC PATCH 06/12] LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT

On 12/8/23 13:54, Samuel Holland wrote: LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in asm/fpu.h, so it only needs to add kernel_fpu_available() and export the CFLAGS adjustments. Signed-off-by: Samuel Holland --- arch/loongarch/Kconfig | 1 +

Re: [RFC PATCH 04/12] arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT

On Thu, Dec 07, 2023 at 09:54:34PM -0800, Samuel Holland wrote: > arm64 provides an equivalent to the common kernel-mode FPU API, but in a > different header and using different function names. Add a wrapper > header, and export CFLAGS adjustments as found in lib/raid6/Makefile. > >

Re: [PATCH] Reapply "kbuild: Create directory for target DTB"

On Tue, 2023-12-12 at 17:13 +, Masahiro Yamada wrote: > > > On Wed, Dec 13, 2023 at 1:17 AM Matthias Schiffer > wrote: > > > > This reverts commit dd7699e37f289fa433f42c6bcc108468c8b198c0. > > > > On powerpc, dtb-y is usually empty unless CONFIG_OF_ALL_DTBS is set. While > > passing a DTB

Re: [PATCH v4 0/5] powerpc/smp: Topology and shared processor optimizations

Srikar Dronamraju writes: > * Srikar Dronamraju [2023-11-09 11:19:28]: > > Hi Michael, > >> PowerVM systems configured in shared processors mode have some unique >> challenges. Some device-tree properties will be missing on a shared >> processor. Hence some sched domains may not make sense for

Re: [PATCH] MAINTAINERS: powerpc: Add Aneesh & Naveen

Michael Ellerman wrote: Aneesh and Naveen are helping out with some aspects of upstream maintenance, add them as reviewers. Signed-off-by: Michael Ellerman --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) Acked-by: Naveen N. Rao Thanks, Naveen diff --git a/MAINTAINERS

Re: [PATCH] MAINTAINERS: powerpc: Add Aneesh & Naveen

Michael Ellerman writes: > Aneesh and Naveen are helping out with some aspects of upstream > maintenance, add them as reviewers. > Acked-by: Aneesh Kumar K.V (IBM) > Signed-off-by: Michael Ellerman > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS