[PATCH v2 00/12] mm: jit/text allocator

From: "Mike Rapoport (IBM)" Hi, module_alloc() is used everywhere as a mean to allocate memory for code. Beside being semantically wrong, this unnecessarily ties all subsystmes that need to allocate code, such as ftrace, kprobes and BPF to modules and puts the burden of code allocation to the m

[PATCH v2 01/12] nios2: define virtual address space for modules

From: "Mike Rapoport (IBM)" nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26 cannot reach all of vmalloc address space. Define module space as 32MiB below the kernel base and switch nios2 to use vmalloc for module allocations. Suggested-by: Thomas Gleixner Signed-off-by:

[PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

From: "Mike Rapoport (IBM)" module_alloc() is used everywhere as a mean to allocate memory for code. Beside being semantically wrong, this unnecessarily ties all subsystems that need to allocate code, such as ftrace, kprobes and BPF to modules and puts the burden of code allocation to the module

[PATCH v2 03/12] mm/execmem, arch: convert simple overrides of module_alloc to execmem

From: "Mike Rapoport (IBM)" Several architectures override module_alloc() only to define address range for code allocations different than VMALLOC address space. Provide a generic implementation in execmem that uses the parameters for address space ranges, required alignment and page protections

[PATCH v2 04/12] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

From: "Mike Rapoport (IBM)" Extend execmem parameters to accommodate more complex overrides of module_alloc() by architectures. This includes specification of a fallback range required by arm, arm64 and powerpc and support for allocation of KASAN shadow required by arm64, s390 and x86. The core

[PATCH v2 05/12] modules, execmem: drop module_alloc

From: "Mike Rapoport (IBM)" Define default parameters for address range for code allocations using the current values in module_alloc() and make execmem_text_alloc() use these defaults when an architecure does not supply its specific parameters. With this, execmem_text_alloc() implements memory

[PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

From: "Mike Rapoport (IBM)" Data related to code allocations, such as module data section, need to comply with architecture constraints for its placement and its allocation right now was done using execmem_text_alloc(). Create a dedicated API for allocating data related to code allocations and a

[PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions

From: "Mike Rapoport (IBM)" The memory allocations for kprobes on arm64 can be placed anywhere in vmalloc address space and currently this is implemented with an override of alloc_insn_page() in arm64. Extend execmem_params with a range for generated code allocations and make kprobes on arm64 us

[PATCH v2 08/12] riscv: extend execmem_params for kprobes allocations

From: "Mike Rapoport (IBM)" RISC-V overrides kprobes::alloc_insn_range() to use the entire vmalloc area rather than limit the allocations to the modules area. Slightly reorder execmem_params initialization to support both 32 and 64 bit variantsi and add definition of jit area to execmem_params t

[PATCH v2 09/12] powerpc: extend execmem_params for kprobes allocations

From: "Mike Rapoport (IBM)" powerpc overrides kprobes::alloc_insn_page() to remove writable permissions when STRICT_MODULE_RWX is on. Add definition of jit area to execmem_params to allow using the generic kprobes::alloc_insn_page() with the desired permissions. As powerpc uses breakpoint instr

[PATCH v2 10/12] arch: make execmem setup available regardless of CONFIG_MODULES

From: "Mike Rapoport (IBM)" execmem does not depend on modules, on the contrary modules use execmem. To make execmem available when CONFIG_MODULES=n, for instance for kprobes, split execmem_params initialization out from arch/kernel/module.c and compile it when CONFIG_EXECMEM=y Signed-off-by: M

[PATCH v2 11/12] x86/ftrace: enable dynamic ftrace without CONFIG_MODULES

From: "Mike Rapoport (IBM)" Dynamic ftrace must allocate memory for code and this was impossible without CONFIG_MODULES. With execmem separated from the modules code, execmem_text_alloc() is available regardless of CONFIG_MODULES. Remove dependency of dynamic ftrace on CONFIG_MODULES and make C

[PATCH v2 12/12] kprobes: remove dependcy on CONFIG_MODULES

From: "Mike Rapoport (IBM)" kprobes depended on CONFIG_MODULES because it has to allocate memory for code. Since code allocations are now implemented with execmem, kprobes can be enabled in non-modular kernels. Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside modules, ma

[PATCH AUTOSEL 6.3 16/30] ASoC: fsl_sai: Enable BCI bit if SAI works on synchronous mode with BYP asserted

From: Chancel Liu [ Upstream commit 32cf0046a652116d6a216d575f3049a9ff9dd80d ] There's an issue on SAI synchronous mode that TX/RX side can't get BCLK from RX/TX it sync with if BYP bit is asserted. It's a workaround to fix it that enable SION of IOMUX pad control and assert BCI. For example if

[PATCH AUTOSEL 6.1 15/26] ASoC: fsl_sai: Enable BCI bit if SAI works on synchronous mode with BYP asserted

From: Chancel Liu [ Upstream commit 32cf0046a652116d6a216d575f3049a9ff9dd80d ] There's an issue on SAI synchronous mode that TX/RX side can't get BCLK from RX/TX it sync with if BYP bit is asserted. It's a workaround to fix it that enable SION of IOMUX pad control and assert BCI. For example if

Re: ppc64le vmlinuz is huge when building with BTF

[Cc linuxppc-dev] Dominique Martinet wrote: Alan Maguire wrote on Thu, Jun 15, 2023 at 03:31:49PM +0100: However the problem I suspect is this: 51 .debug_info 0a488b55 026f8d20 2**0 CONTENTS, READONLY, DEBUGGING [...] The debug info

[PATCH v2 00/16] Add support for DAX vmemmap optimization for ppc64

This patch series implements changes required to support DAX vmemmap optimization for ppc64. The vmemmap optimization is only enabled with radix MMU translation and 1GB PUD mapping with 64K page size. The patch series also split hugetlb vmemmap optimization as a separate Kconfig variable so that ar

[PATCH v2 01/16] powerpc/mm/book3s64: Use pmdp_ptep helper instead of typecasting.

No functional change in this patch. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index 2297aa764ecd..5f8c6fbe8a

[PATCH v2 02/16] powerpc/book3s64/mm: mmu_vmemmap_psize is used by radix

This should not be within CONFIG_PPC_64S_HASHS_MMU. We use mmu_vmemmap_psize on radix while mapping the vmemmap area. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch

[PATCH v2 03/16] powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo

On memory unplug reduce DirectMap page count correctly. root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M:115343360 kB DirectMap1G: 0 kB Before fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace r

[PATCH v2 04/16] powerpc/book3s64/mm: Use PAGE_KERNEL instead of opencoding

No functional change in this patch. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index 15a099e53cde..76f6a1f3

[PATCH v2 05/16] powerpc/mm/dax: Fix the condition when checking if altmap vmemap can cross-boundary

Without this fix, the last subsection vmemmap can end up in memory even if the namespace is created with -M mem and has sufficient space in the altmap area. Fixes: cf387d9644d8 ("libnvdimm/altmap: Track namespace boundaries in altmap") Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/init_64.

[PATCH v2 06/16] mm/hugepage pud: Allow arch-specific helper function to check huge page pud support

Architectures like powerpc would like to enable transparent huge page pud support only with radix translation. To support that add has_transparent_pud_hugepage() helper that architectures can override. Signed-off-by: Aneesh Kumar K.V --- drivers/nvdimm/pfn_devs.c | 2 +- include/linux/pgtable.h

[PATCH v2 07/16] mm: Change pudp_huge_get_and_clear_full take vm_area_struct as arg

We will use this in a later patch to do tlb flush when clearing pud entries on powerpc. This is similar to commit 93a98695f2f9 ("mm: change pmdp_huge_get_and_clear_full take vm_area_struct as arg") Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 4 ++-- mm/debug_vm_pgtable.c | 2

[PATCH v2 08/16] mm/vmemmap: Improve vmemmap_can_optimize and allow architectures to override

dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within vmemmap such that tail page mapping can point to the second PAGE_SIZE area. Enforce that in vmemmap_can_optimize() function. Architectures like powerpc also want to enable vmemmap optimization conditionally (only with radix MMU

[PATCH v2 10/16] mm: Add __HAVE_ARCH_PUD_SAME similar to __HAVE_ARCH_P4D_SAME

This helps architectures to override pmd_same and pud_same independently. Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 2fe19720075e..8c5174d1f9db 100644 --- a/include/linu

[PATCH v2 12/16] mm/vmemmap optimization: Split hugetlb and devdax vmemmap optimization

Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap optimization includes an update of both the permissions (writeable to read-only) and the output address (pfn) of the vmemmap ptes. That is not supported without unmapping of pte(marking it invalid) by some architectures. With DA

[PATCH v2 13/16] powerpc/book3s64/mm: Enable transparent pud hugepage

This is enabled only with radix translation and 1G hugepage size. This will be used with devdax device memory with a namespace alignment of 1G. Anon transparent hugepage is not supported even though we do have helpers checking pud_trans_huge(). We should never find that return true. The only expec

[PATCH v2 14/16] powerpc/book3s64/vmemmap: Switch radix to use a different vmemmap handling function

This is in preparation to update radix to implement vmemmap optimization for devdax. Below are the rules w.r.t radix vmemmap mapping 1. First try to map things using PMD (2M) 2. With altmap if altmap cross-boundary check returns true, fall back to PAGE_SIZE 3. If we can't allocate PMD_SIZE back

[PATCH v2 15/16] powerpc/book3s64/radix: Add support for vmemmap optimization for radix

With 2M PMD-level mapping, we require 32 struct pages and a single vmemmap page can contain 1024 struct pages (PAGE_SIZE/sizeof(struct page)). Hence with 64K page size, we don't use vmemmap deduplication for PMD-level mapping. Signed-off-by: Aneesh Kumar K.V --- Documentation/mm/vmemmap_dedup.rs

[PATCH v2 16/16] powerpc/book3s64/radix: Remove mmu_vmemmap_psize

This is not used by radix anymore. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 10 -- arch/powerpc/mm/init_64.c| 21 ++--- 2 files changed, 14 insertions(+), 17 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_pg

Re: [PATCH v2 12/12] kprobes: remove dependcy on CONFIG_MODULES

Mike Rapoport writes: > From: "Mike Rapoport (IBM)" > > kprobes depended on CONFIG_MODULES because it has to allocate memory for > code. I think you can remove the MODULES dependency from BPF_JIT as well: --8<-- diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig index 2dfe1079f772..fa4587027

[PATCH v2 09/16] mm/vmemmap: Allow architectures to override how vmemmap optimization works

Architectures like powerpc will like to use different page table allocators and mapping mechanisms to implement vmemmap optimization. Similar to vmemmap_populate allow architectures to implement vmemap_populate_compound_pages Signed-off-by: Aneesh Kumar K.V --- mm/sparse-vmemmap.c | 3 +++ 1 fil

[PATCH v2 11/16] mm/huge pud: Use transparent huge pud helpers only with CONFIG_TRANSPARENT_HUGEPAGE

pudp_set_wrprotect and move_huge_pud helpers are only used when CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and move_huge_pmd_helpers use architecture override only if CONFIG_TRANSPARENT_HUGEPAGE is set Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 2 ++

Re: ppc64le vmlinuz is huge when building with BTF

Naveen N Rao wrote on Fri, Jun 16, 2023 at 04:28:53PM +0530: > > We're not stripping anything in vmlinuz for other archs -- the linker > > script already should be including only the bare minimum to decompress > > itself (+compressed useful bits), so I guess it's a Kbuild issue for the > > arch. >

Re: [PATCH v9 00/14] pci: Work around ASMedia ASM2824 PCIe link training failures

On Thu, 15 Jun 2023, Bjorn Helgaas wrote: > > If doing it this way, which I actually like, I think it would be a little > > bit better performance- and style-wise if this was written as: > > > > if (pci_is_pcie(dev)) { > > bridge = pci_upstream_bridge(dev); > > retra

Re: [PATCH v4 04/34] pgtable: Create struct ptdesc

On Mon, Jun 12, 2023 at 02:03:53PM -0700, Vishal Moola (Oracle) wrote: > Currently, page table information is stored within struct page. As part > of simplifying struct page, create struct ptdesc for page table > information. > > Signed-off-by: Vishal Moola (Oracle) > --- > include/linux/pgtable

[RFC PATCH v1 0/3] powerpc/objtool: First step towards uaccess validation (v1)

This RFC is a first step towards the validation of userspace accesses. For the time being it targets only PPC32 and includes hacks directly in core part of objtool. It doesn't yet include handling of uaccess at all but is a first step to support objtool validation. Assembly files have been kept

[RFC PATCH v1 2/3] powerpc: Mark all .S files invalid for objtool

A lot of work is required in .S files in order to get them ready for objtool checks. For the time being, exclude them from the checks. This is done with the script below: #!/bin/sh DIRS=`find arch/powerpc -name "*.S" -exec dirname {} \; | sort | uniq` for d in $DIRS

[RFC PATCH v1 3/3] powerpc: WIP draft support to objtool check

This draft messy patch is first try to add support of objtool check for powerpc. This is in preparation of doing uaccess validation for powerpc. For the time being, this is implemented for PPC32 only breaking support for other targets eventually. Will be reworked to be more generic once a final wo

[RFC PATCH v1 1/3] Revert "powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto"

This reverts commit 1e688dd2a3d6759d416616ff07afc4bb836c4213. That commit aimed at optimising the code around generation of WARN_ON/BUG_ON but this leads to a lot of dead code erroneously generated by GCC. text data bss dec hex filename 9551585 3627834 224376 13

Re: [RFC PATCH v1 3/3] powerpc: WIP draft support to objtool check

Few comments.. On Fri, Jun 16, 2023 at 03:47:52PM +0200, Christophe Leroy wrote: > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 0fcf99c91400..f945fe271706 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -236,6 +236,7 @@ static bool __dead_end_functi

[PATCH v2 0/6] watchdog/hardlockup: Cleanup configuration of hardlockup detectors

Hi, this patchset is supposed to replace the last patch in the patchset cleaning up after introducing the buddy detector, see https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid Changes against v1: + Better explained the C-like ordering in the 1st pat

[PATCH v2 1/6] watchdog/hardlockup: Sort hardlockup detector related config values a logical way

There are four possible variants of hardlockup detectors: + buddy: available when SMP is set. + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set. + sparc64 special variant: available when HAVE_NMI_WATCHDOG is

[PATCH v2 2/6] watchdog/hardlockup: Make the config checks more straightforward

There are four possible variants of hardlockup detectors: + buddy: available when SMP is set. + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set. + sparc64 special variant: available when HAVE_NMI_WATCHDOG is

[PATCH v2 3/6] watchdog/hardlockup: Declare arch_touch_nmi_watchdog() only in linux/nmi.h

arch_touch_nmi_watchdog() needs a different implementation for various hardlockup detector implementations. And it does nothing when any hardlockup detector is not built at all. arch_touch_nmi_watchdog() is declared via linux/nmi.h. And it must be defined as an empty function when there is no hard

[PATCH v2 4/6] watchdog/hardlockup: Make HAVE_NMI_WATCHDOG sparc64-specific

There are several hardlockup detector implementations and several Kconfig values which allow selection and build of the preferred one. CONFIG_HARDLOCKUP_DETECTOR was introduced by the commit 23637d477c1f53acb ("lockup_detector: Introduce CONFIG_HARDLOCKUP_DETECTOR") in v2.6.36. It was a preparatio

[PATCH v2 5/6] watchdog/sparc64: Define HARDLOCKUP_DETECTOR_SPARC64

The HAVE_ prefix means that the code could be enabled. Add another variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix. It will be set when it should be built. It will make it compatible with the other hardlockup detectors. Before, it is far from obvious that the SPARC64 variant is a

[PATCH v2 6/6] watchdog/hardlockup: Define HARDLOCKUP_DETECTOR_ARCH

The HAVE_ prefix means that the code could be enabled. Add another variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix. It will be set when it should be built. It will make it compatible with the other hardlockup detectors. The change allows to clean up dependencies of PPC_WATCHDOG and

Re: [PATCH v2 0/6] watchdog/hardlockup: Cleanup configuration of hardlockup detectors

On Fri 2023-06-16 17:06:12, Petr Mladek wrote: > Hi, > > this patchset is supposed to replace the last patch in the patchset cleaning > up after introducing the buddy detector, see > https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid > > Changes against

Re: [PATCH v2 01/12] nios2: define virtual address space for modules

On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote: >  void *module_alloc(unsigned long size) >  { > -   if (size == 0) > -   return NULL; > -   return kmalloc(size, GFP_KERNEL); > -} > - > -/* Free memory returned from module_alloc */ > -void module_memfree(void *module_reg

Re: [PATCH v2 04/12] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote: > -void *module_alloc(unsigned long size) > -{ > -   gfp_t gfp_mask = GFP_KERNEL; > -   void *p; > - > -   if (PAGE_ALIGN(size) > MODULES_LEN) > -   return NULL; > +static struct execmem_params execmem_params = { > +   

Re: [PATCH v2 1/6] watchdog/hardlockup: Sort hardlockup detector related config values a logical way

Hi, On Fri, Jun 16, 2023 at 8:06 AM Petr Mladek wrote: > > There are four possible variants of hardlockup detectors: > > + buddy: available when SMP is set. > > + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. > > + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is

Re: [PATCH v2 2/6] watchdog/hardlockup: Make the config checks more straightforward

Hi, On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote: > > There are four possible variants of hardlockup detectors: > > + buddy: available when SMP is set. > > + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set. > > + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is

Re: [PATCH v2 4/6] watchdog/hardlockup: Make HAVE_NMI_WATCHDOG sparc64-specific

Hi, On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote: > > There are several hardlockup detector implementations and several Kconfig > values which allow selection and build of the preferred one. > > CONFIG_HARDLOCKUP_DETECTOR was introduced by the commit 23637d477c1f53acb > ("lockup_detector: In

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

On Fri, Jun 16, 2023 at 11:50:28AM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > module_alloc() is used everywhere as a mean to allocate memory for code. > > Beside being semantically wrong, this unnecessarily ties all subsystems > that need to allocate code, such as ftrace, kpro

Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Data related to code allocations, such as module data section, need > to > comply with architecture constraints for its placement and its > allocation right now was done using execmem_text_alloc(). > > Crea

Re: [PATCH v2 00/12] mm: jit/text allocator

On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > Hi, > > module_alloc() is used everywhere as a mean to allocate memory for > code. > > Beside being semantically wrong, this unnecessarily ties all > subsystmes > that need to allocate code, such as ftrace

Re: ppc64le vmlinuz is huge when building with BTF

Dominique Martinet wrote: Naveen N Rao wrote on Fri, Jun 16, 2023 at 04:28:53PM +0530: > We're not stripping anything in vmlinuz for other archs -- the linker > script already should be including only the bare minimum to decompress > itself (+compressed useful bits), so I guess it's a Kbuild iss

Re: [PATCH v2 01/12] nios2: define virtual address space for modules

On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26 > cannot reach all of vmalloc address space. > > Define module space as 32MiB below the kernel base and switch nios2 to > use vmalloc fo

Re: [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc()

On Fri, Jun 16, 2023 at 9:48 AM Kent Overstreet wrote: > > On Fri, Jun 16, 2023 at 11:50:28AM +0300, Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > > > module_alloc() is used everywhere as a mean to allocate memory for code. > > > > Beside being semantically wrong, this unnecessarily ti

Re: [PATCH v2 03/12] mm/execmem, arch: convert simple overrides of module_alloc to execmem

On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > Several architectures override module_alloc() only to define address > range for code allocations different than VMALLOC address space. > > Provide a generic implementation in execmem that uses the parameters

Re: [PATCH v2 04/12] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: [...] > diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c > index 5af4975caeb5..c3d999f3a3dd 100644 > --- a/arch/arm64/kernel/module.c > +++ b/arch/arm64/kernel/module.c > @@ -17,56 +17,50 @@ > #include > #include > #incl

Re: [PATCH v2 05/12] modules, execmem: drop module_alloc

On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > Define default parameters for address range for code allocations using > the current values in module_alloc() and make execmem_text_alloc() use > these defaults when an architecure does not supply its specifi

[PATCH v4 03/25] powerpc/iommu: Setup a default domain and remove set_platform_dma_ops

POWER is using the set_platform_dma_ops() callback to hook up its private dma_ops, but this is buired under some indirection and is weirdly happening for a BLOCKED domain as well. For better documentation create a PLATFORM domain to manage the dma_ops, since that is what it is for, and make the BL

[PATCH v4 07/25] iommu/mtk_iommu_v1: Implement an IDENTITY domain

What mtk does during mtk_iommu_v1_set_platform_dma() is actually putting the iommu into identity mode. Make this available as a proper IDENTITY domain. The mtk_iommu_v1_def_domain_type() from commit 8bbe13f52cb7 ("iommu/mediatek-v1: Add def_domain_type") explains this was needed to allow probe_fin

[PATCH v4 04/25] iommu: Add IOMMU_DOMAIN_PLATFORM for S390

The PLATFORM domain will be set as the default domain and attached as normal during probe. The driver will ignore the initial attach from a NULL domain to the PLATFORM domain. After this, the PLATFORM domain's attach_dev will be called whenever we detach from an UNMANAGED domain (eg for VFIO). Thi

[PATCH v4 24/25] iommu: Convert simple drivers with DOMAIN_DMA to domain_alloc_paging()

These drivers are all trivially converted since the function is only called if the domain type is going to be IOMMU_DOMAIN_UNMANAGED/DMA. Tested-by: Heiko Stuebner Tested-by: Steven Price Tested-by: Marek Szyprowski Tested-by: Nicolin Chen Signed-off-by: Jason Gunthorpe --- drivers/iommu/arm

[PATCH v4 05/25] iommu/fsl_pamu: Implement a PLATFORM domain

This driver is nonsensical. To not block migrating the core API away from NULL default_domains give it a hacky of a PLATFORM domain that keeps it working exactly as it always did. Leave some comments around to warn away any future people looking at this. Signed-off-by: Jason Gunthorpe --- drive

[PATCH v4 22/25] iommu: Add __iommu_group_domain_alloc()

Allocate a domain from a group. Automatically obtains the iommu_ops to use from the device list of the group. Convert the internal callers to use it. Tested-by: Steven Price Tested-by: Marek Szyprowski Tested-by: Nicolin Chen Signed-off-by: Jason Gunthorpe --- drivers/iommu/iommu.c | 66 +

[PATCH v4 13/25] iommu/omap: Implement an IDENTITY domain

What omap does during omap_iommu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. This driver does not support IOMMU_DOMAIN_DMA, however it cannot be compiled on ARM64 either. Most likely it i

[PATCH v4 02/25] iommu: Add IOMMU_DOMAIN_PLATFORM

This is used when the iommu driver is taking control of the dma_ops, currently only on S390 and power spapr. It is designed to preserve the original ops->detach_dev() semantic that these S390 was built around. Provide an opaque domain type and a 'default_domain' ops value that allows the driver to

[PATCH v4 23/25] iommu: Add ops->domain_alloc_paging()

This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING domain, so it saves a few lines in a lot of drivers needlessly checking the type. More critically, this allows us to sweep out all the IOMMU_DOMAIN_UNMANAGED and IOMMU_DOMAIN_DMA checks from a lot of the drivers, simplifying

[PATCH v4 21/25] iommu: Require a default_domain for all iommu drivers

At this point every iommu driver will cause a default_domain to be selected, so we can finally remove this gap from the core code. The following table explains what each driver supports and what the resulting default_domain will be: ops->defaut_domain

[PATCH v4 25/25] iommu: Convert remaining simple drivers to domain_alloc_paging()

These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively allows them to support that mode. The prior work to require default_domains makes this safe because every one of these drivers is either compilation incompatible with dma-iommu.c, or already establishing a default_domain. In

[PATCH v4 11/25] iommu/tegra-smmu: Implement an IDENTITY domain

What tegra-smmu does during tegra_smmu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. Signed-off-by: Jason Gunthorpe --- drivers/iommu/tegra-smmu.c | 37 ---

[PATCH v4 08/25] iommu: Reorganize iommu_get_default_domain_type() to respect def_domain_type()

Except for dart every driver returns 0 or IDENTITY from def_domain_type(). The drivers that return IDENTITY have some kind of good reason, typically that quirky hardware really can't support anything other than IDENTITY. Arrange things so that if the driver says it needs IDENTITY then iommu_get_d

[PATCH v4 12/25] iommu/tegra-smmu: Support DMA domains in tegra

All ARM64 iommu drivers should support IOMMU_DOMAIN_DMA to enable dma-iommu.c. tegra is blocking dma-iommu usage, and also default_domain's, because it wants an identity translation. This is needed for some device quirk. The correct way to do this is to support IDENTITY domains and use ops->def_do

[PATCH v4 18/25] iommu/ipmmu: Add an IOMMU_IDENTITIY_DOMAIN

This brings back the ops->detach_dev() code that commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it into an IDENTITY domain. Also reverts commit 584d334b1393 ("iommu/ipmmu-vmsa: Remove ipmmu_utlb_disable()") Signed-off-by: Jason Gunthorpe --- drivers/iommu/ipmmu-vms

[PATCH v4 19/25] iommu/mtk_iommu: Add an IOMMU_IDENTITIY_DOMAIN

This brings back the ops->detach_dev() code that commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it into an IDENTITY domain. Signed-off-by: Jason Gunthorpe --- drivers/iommu/mtk_iommu.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/driv

[PATCH v4 06/25] iommu/tegra-gart: Remove tegra-gart

Thierry says this is not used anymore, and doesn't think it makes sense as an iommu driver. The HW it supports is about 10 years old now and newer HW uses different IOMMU drivers. As this is the only driver with a GART approach, and it doesn't really meet the driver expectations from the IOMMU cor

[PATCH v4 14/25] iommu/msm: Implement an IDENTITY domain

What msm does during omap_iommu_set_platform_dma() is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. This driver does not support IOMMU_DOMAIN_DMA, however it cannot be compiled on ARM64 either. Most likely it is

[PATCH v4 09/25] iommu: Allow an IDENTITY domain as the default_domain in ARM32

Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the same stuff, the way they relate to the IOMMU core is quiet different. dma-iommu.c expects the core code to setup an UNMANAGED domain (of type IOMMU_DOMAIN_DMA) and then configures itself to use that domain. This becomes the

[PATCH v4 16/25] iommu: Remove ops->set_platform_dma_ops()

All drivers are now using IDENTITY or PLATFORM domains for what this did, we can remove it now. It is no longer possible to attach to a NULL domain. Tested-by: Heiko Stuebner Tested-by: Niklas Schnelle Tested-by: Steven Price Tested-by: Marek Szyprowski Tested-by: Nicolin Chen Signed-off-by:

[PATCH v4 00/25] iommu: Make default_domain's mandatory

[ It would be good to get this in linux-next, we have some good test coverage on the ARM side already, thanks! ] It has been a long time coming, this series completes the default_domain transition and makes it so that the core IOMMU code will always have a non-NULL default_domain for every driver

[PATCH v4 01/25] iommu: Add iommu_ops->identity_domain

This allows a driver to set a global static to an IDENTITY domain and the core code will automatically use it whenever an IDENTITY domain is requested. By making it always available it means the IDENTITY can be used in error handling paths to force the iommu driver into a known state. Devices impl

[PATCH v4 17/25] iommu/qcom_iommu: Add an IOMMU_IDENTITIY_DOMAIN

This brings back the ops->detach_dev() code that commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it into an IDENTITY domain. Signed-off-by: Jason Gunthorpe --- drivers/iommu/arm/arm-smmu/qcom_iommu.c | 39 + 1 file changed, 39 insertions(+) d

[PATCH v4 10/25] iommu/exynos: Implement an IDENTITY domain

What exynos calls exynos_iommu_detach_device is actually putting the iommu into identity mode. Move to the new core support for ARM_DMA_USE_IOMMU by defining ops->identity_domain. Tested-by: Marek Szyprowski Acked-by: Marek Szyprowski Signed-off-by: Jason Gunthorpe --- drivers/iommu/exynos-io

[PATCH v4 15/25] iommufd/selftest: Make the mock iommu driver into a real driver

I've avoided doing this because there is no way to make this happen without an intrusion into the core code. Up till now this has avoided needing the core code's probe path with some hackery - but now that default domains are becoming mandatory it is unavoidable. The core probe path must be run to

[PATCH v4 20/25] iommu/sun50i: Add an IOMMU_IDENTITIY_DOMAIN

Prior to commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") the sun50i_iommu_detach_device() function was being called by ops->detach_dev(). This is an IDENTITY domain so convert sun50i_iommu_detach_device() into sun50i_iommu_identity_attach() and a full IDENTITY domain and thus hook it ba

Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

On Fri, Jun 16, 2023 at 1:51 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > Data related to code allocations, such as module data section, need to > comply with architecture constraints for its placement and its > allocation right now was done using execmem_text_alloc(). > > Create a

Re: [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions

On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > The memory allocations for kprobes on arm64 can be placed anywhere in > vmalloc address space and currently this is implemented with an override > of alloc_insn_page() in arm64. > > Extend execmem_params with

Re: [PATCH v2 08/12] riscv: extend execmem_params for kprobes allocations

On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > RISC-V overrides kprobes::alloc_insn_range() to use the entire vmalloc area > rather than limit the allocations to the modules area. > > Slightly reorder execmem_params initialization to support both 32 and 6

Re: [PATCH v2 09/12] powerpc: extend execmem_params for kprobes allocations

On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > powerpc overrides kprobes::alloc_insn_page() to remove writable > permissions when STRICT_MODULE_RWX is on. > > Add definition of jit area to execmem_params to allow using the generic > kprobes::alloc_insn_pa

Re: [PATCH v2 10/12] arch: make execmem setup available regardless of CONFIG_MODULES

On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > execmem does not depend on modules, on the contrary modules use > execmem. > > To make execmem available when CONFIG_MODULES=n, for instance for > kprobes, split execmem_params initialization out from > arch/

Re: [PATCH v2 11/12] x86/ftrace: enable dynamic ftrace without CONFIG_MODULES

On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport wrote: > > From: "Mike Rapoport (IBM)" > > Dynamic ftrace must allocate memory for code and this was impossible > without CONFIG_MODULES. > > With execmem separated from the modules code, execmem_text_alloc() is > available regardless of CONFIG_MODULE

Re: [PATCH v9 00/14] pci: Work around ASMedia ASM2824 PCIe link training failures

On Fri, Jun 16, 2023 at 01:27:52PM +0100, Maciej W. Rozycki wrote: > On Thu, 15 Jun 2023, Bjorn Helgaas wrote: > As per my earlier remark: > > > I think making a system halfway-fixed would make little sense, but with > > the actual fix actually made last as you suggested I think this can be > >

Re: [PATCH v4 04/34] pgtable: Create struct ptdesc

On Thu, Jun 15, 2023 at 12:57:19AM -0700, Hugh Dickins wrote: > Probably just trivial collisions in most architectures, which either > of us can easily adjust to the other; powerpc likely to be more awkward, > but fairly easily resolved; s390 quite a problem. > > I've so far been unable to post a

Re: [PATCH v4 04/34] pgtable: Create struct ptdesc

On Thu, Jun 15, 2023 at 12:57 AM Hugh Dickins wrote: > > On Mon, 12 Jun 2023, Vishal Moola (Oracle) wrote: > > > Currently, page table information is stored within struct page. As part > > of simplifying struct page, create struct ptdesc for page table > > information. > > > > Signed-off-by: Visha

[powerpc:merge] BUILD SUCCESS 12ffddc6444780aec83fa5086673ec005c0bace4

been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r001-20230616 gcc arc allyesconfig

  1   2   >