[RFC PATCH v2 12/20] powerpc/64e: Remove unneeded #ifdef CONFIG_PPC_E500

When it is a nohash/64 it can't be anything else than CONFIG_PPC_E500 so remove the #ifdef as they are always true. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/nohash/tlb.c | 13 - 1 file changed, 13 deletions(-) diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/power

[RFC PATCH v2 11/20] powerpc/mm: Complement huge_pte_alloc() for all non HUGEPD setups

huge_pte_alloc() for non-HUGEPD targets is reserved for 8xx at the moment. In order to convert other targets for non-HUGEPD, complement huge_pte_alloc() to support any standard cont-PxD setup. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/hugetlbpage.c | 25 - 1

[RFC PATCH v2 10/20] powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries

pXd_offset() are used on real pointers and not on on-stack copies. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/pgtable.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c index 59f0d7706d2f..51ee508ee

[RFC PATCH v2 09/20] powerpc/mm: Remove _PAGE_PSIZE

_PAGE_PSIZE macro is never used outside the place it is defined and is used only on 8xx and e500. Remove indirection, remove it and use its content directly. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/pte-40x.h | 3 --- arch/powerpc/include/asm/nohash/32/pte-44x.h

[RFC PATCH v2 08/20] powerpc/8xx: Simplify struct mmu_psize_def

On 8xx, only the shift field is used in struct mmu_psize_def Remove other fields and related macros. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/include/asm/nohash/32

Re: [PATCH v3 3/5] powerpc/64: Convert patch_instruction() to patch_u32()

Le 14/05/2024 à 04:59, Benjamin Gray a écrit : > On Tue, 2024-04-23 at 15:09 +0530, Naveen N Rao wrote: >> On Mon, Mar 25, 2024 at 04:53:00PM +1100, Benjamin Gray wrote: >>> This use of patch_instruction() is working on 32 bit data, and can >>> fail >>> if the data looks like a prefixed instructi

Re: [PATCH bpf v3] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH

:r7=0) > Observation SB+atomic_add+fetch Never 0 9 > > [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt > [2] https://www.kernel.org/doc/Documentation/atomic_t.txt > > Fixes: 65112709115f ("powerpc/bpf/64: add support for BPF_ATOMIC bitwise > operations"

Re: [PATCH bpf v2] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH

Le 08/05/2024 à 13:54, Puranjay Mohan a écrit : > [Vous ne recevez pas souvent de courriers de puran...@kernel.org. Découvrez > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > The Linux Kernel Memory Model [1][2] requires RMW operations that have a > return val

Re: [PATCH bpf] powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH

Le 08/05/2024 à 07:05, Michael Ellerman a écrit : > Puranjay Mohan writes: >> The Linux Kernel Memory Model [1][2] requires RMW operations that have a >> return value to be fully ordered. >> >> BPF atomic operations with BPF_FETCH (including BPF_XCHG and >> BPF_CMPXCHG) return a value back so th

Re: About the code updte of the arc/linux/arch/beta/kernel/irq_64.c

Hi Xia, Le 01/05/2024 à 08:22, 赵夏 a écrit : > Hi Christophe, > >   I identified that the function named "arch_local_irq_restore" of the > file irq_64.c was updated by you frequently in the last two years. You mean arch/powerpc/kernel/irq_64.c I guess ? I don't think I "frequently" changed it.

Re: [PATCH 1/2] radix/kfence: map __kfence_pool at page granularity

Le 24/04/2024 à 13:09, Hari Bathini a écrit : > When KFENCE is enabled, total system memory is mapped at page level > granularity. But in radix MMU mode, ~3GB additional memory is needed > to map 100GB of system memory at page level granularity when compared > to using 2MB direct mapping. This is

Re: [PATCH 6/7] powerpc: Replace CONFIG_4xx with CONFIG_44x

Le 06/05/2024 à 14:51, Michael Ellerman a écrit : > Replace 4xx usage with 44x, and replace 4xx_SOC with 44x. You can go one step further because CONFIG_44x implies CONFIG_BOOKE, see https://patchwork.ozlabs.org/project/linuxppc-dev/patch/d404d1257cd1d36aa6b25237f54eb2c2223ce447.1607519517.git.

Re: [PATCH V2 8/9] tools/perf: Add support to find global register variables using find_data_type_global_reg

Le 06/05/2024 à 14:19, Athira Rajeev a écrit : > There are cases where define a global register variable and associate it > with a specified register. Example, in powerpc, two registers are > defined to represent variable: > 1. r13: represents local_paca > register struct paca_struct *local_paca

Re: [PATCH V2 7/9] tools/perf: Update instruction tracking with add instruction

Le 06/05/2024 à 14:19, Athira Rajeev a écrit : > Update instruction tracking with add instruction. Apart from "mr" > instruction, the register state is carried on by other insns, ie, > "add, addi, addis". Since these are not memory instructions and doesn't > fall in the range of (32 to 63), add t

Re: [PATCH V2 6/9] tools/perf: Update instruction tracking for powerpc

Le 06/05/2024 à 14:19, Athira Rajeev a écrit : > Add instruction tracking function "update_insn_state_powerpc" for > powerpc. Example sequence in powerpc: > > ld r10,264(r3) > mr r31,r3 > < > ld r9,312(r31) Your approach looks fragile. mr is a simplified instruction which in fac

Re: [PATCH V2 5/9] tools/perf: Update parameters for reg extract functions to use raw instruction on powerpc

Le 06/05/2024 à 14:19, Athira Rajeev a écrit : > Use the raw instruction code and macros to identify memory instructions, > extract register fields and also offset. The implementation addresses > the D-form, X-form, DS-form instructions. Two main functions are added. > New parse function "load_st

Re: [PATCH V2 4/9] tools/perf: Add support to capture and parse raw instruction in objdump

Le 06/05/2024 à 14:19, Athira Rajeev a écrit : > Add support to capture and parse raw instruction in objdump. What's the purpose of using 'objdump' for reading raw instructions ? Can't they be read directly without invoking 'objdump' ? It looks odd to me to use objdump to provide readable text

Re: [PATCH v3] kprobe/ftrace: bail out if ftrace was killed

Le 01/05/2024 à 18:29, Stephen Brennan a écrit : > If an error happens in ftrace, ftrace_kill() will prevent disarming > kprobes. Eventually, the ftrace_ops associated with the kprobes will be > freed, yet the kprobes will still be active, and when triggered, they > will use the freed memory, lik

Re: [PATCH v4 14/15] kprobes: remove dependency on CONFIG_MODULES

Le 19/04/2024 à 17:49, Mike Rapoport a écrit : > Hi Masami, > > On Thu, Apr 18, 2024 at 06:16:15AM +0900, Masami Hiramatsu wrote: >> Hi Mike, >> >> On Thu, 11 Apr 2024 19:00:50 +0300 >> Mike Rapoport wrote: >> >>> From: "Mike Rapoport (IBM)" >>> >>> kprobes depended on CONFIG_MODULES because i

Re: [0/2] powerpc/powernv/vas: Adjustments for two function implementations

Le 16/04/2024 à 14:14, Markus Elfring a écrit : >> This is explicit in Kernel documentation: >> >> /** >>* kfree - free previously allocated memory >>* @object: pointer returned by kmalloc() or kmem_cache_alloc() >>* >>* If @object is NULL, no operation is performed. >>*/ >> >

Re: [0/2] powerpc/powernv/vas: Adjustments for two function implementations

Le 16/04/2024 à 13:11, Michael Ellerman a écrit : > Markus Elfring writes: >>> A few update suggestions were taken into account >>> from static source code analysis. >>> >>> Markus Elfring (2): >> >> I would appreciate a bit more information about the reasons >> why this patch series was rejecte

Re: [RFC PATCH 0/8] Reimplement huge pages without hugepd on powerpc 8xx

Le 15/04/2024 à 21:12, Christophe Leroy a écrit : > > > Le 12/04/2024 à 16:30, Peter Xu a écrit : >> On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: >>> >>> >>> Le 11/04/2024 à 18:15, Peter Xu a écrit : >>>> On Mon, M

Re: [RFC PATCH 0/8] Reimplement huge pages without hugepd on powerpc 8xx

Le 12/04/2024 à 16:30, Peter Xu a écrit : > On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: >> >> >> Le 11/04/2024 à 18:15, Peter Xu a écrit : >>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: >>>> On Mon, Mar 25,

Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG

Le 15/04/2024 à 17:35, Arnd Bergmann a écrit : > On Mon, Apr 15, 2024, at 04:19, Michael Ellerman wrote: >> "Arnd Bergmann" writes: >>> On Thu, Apr 11, 2024, at 11:27, Adrian Hunter wrote: >>>> On 11/04/24 11:22, Christophe Leroy wrote: >>>>

Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2

Le 10/04/2024 à 21:58, Peter Xu a écrit : >> >> e500 has two modes: 32 bits and 64 bits. >> >> For 32 bits: >> >> 8xx is the only one handling it through HW-assisted pagetable walk hence >> requiring a 2-level whatever the pagesize is. > > Hmm I think maybe finally I get it.. > > I think the co

Re: [RFC PATCH 0/8] Reimplement huge pages without hugepd on powerpc 8xx

Le 11/04/2024 à 18:15, Peter Xu a écrit : > On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: >> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: >>> This series reimplements hugepages with hugepd on powerpc 8xx. >>> >>> Unlik

Re: [RFC PATCH 2/7] mm: vmalloc: don't account for number of nodes for HUGE_VMAP allocations

Le 11/04/2024 à 18:05, Mike Rapoport a écrit : > From: "Mike Rapoport (IBM)" > > vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explictly > specify node ID will use huge pages only if size_per_node is larger than > PMD_SIZE. > Still the actual allocated memory is not distributed betwee

Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG

Le 11/04/2024 à 10:12, Christophe Leroy a écrit : > > > Le 11/04/2024 à 09:16, Adrian Hunter a écrit : >> On 11/04/24 10:04, Arnd Bergmann wrote: >>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote: >>>> BUG() does not return, and arch implementa

Re: [PATCH] bug: Fix no-return-statement warning with !CONFIG_BUG

Le 11/04/2024 à 09:16, Adrian Hunter a écrit : > On 11/04/24 10:04, Arnd Bergmann wrote: >> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote: >>> BUG() does not return, and arch implementations of BUG() use unreachable() >>> or other non-returning code. However with !CONFIG_BUG, the default >>

Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2

Le 10/04/2024 à 17:28, Peter Xu a écrit : > On Tue, Apr 09, 2024 at 08:43:55PM -0300, Jason Gunthorpe wrote: >> On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote: >>> In short, hugetlb mappings shouldn't be special comparing to other huge pXd >>> and large folio (cont-pXd) mappings for mos

Re: [PATCH] powerpc: align memory_limit to 16MB in early_parse_mem

Le 10/04/2024 à 17:22, Joel Savitz a écrit : > [Vous ne recevez pas souvent de courriers de jsav...@redhat.com. Découvrez > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > On Mon, Apr 1, 2024 at 10:17 AM Joel Savitz wrote: >> >> On Tue, Mar 26, 2024 at 12:45 A

Re: [PATCH] cpufreq: Covert to exit callback returning void

Le 10/04/2024 à 15:42, lizhe a écrit : > > Hi， >      I have already tested it, it is functioning properly, Please review. > > *Lizhe* > >                      Thanks > Please don't top-post, see https://docs.kernel.

Re: [RESEND PATCH net v4 1/2] soc: fsl: qbman: Always disable interrupts when taking cgr_lock

Hi Vladimir, Le 19/02/2024 à 16:30, Vladimir Oltean a écrit : > Hi Sean, > > On Thu, Feb 15, 2024 at 11:23:26AM -0500, Sean Anderson wrote: >> smp_call_function_single disables IRQs when executing the callback. To >> prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. >> This

Re: [PATCH 2/2] MAINTAINERS: Make cxl obsolete

Le 09/04/2024 à 06:37, Michael Ellerman a écrit : > Andrew Donnellan writes: >> The cxl driver is no longer actively maintained and we intend to remove it >> in a future kernel release. Change its status to obsolete, and update the >> sysfs ABI documentation accordingly. >> >> Signed-off-by: And

Re: [FSL P50x0] Kernel 6.9-rc1 compiling issue

Hi Christian, hi Hari, Le 04/04/2024 à 19:44, Christian Zigotzky a écrit : > Shall we use CONFIG_CRASH_DUMP to get int crashing_cpu = -1;? > > Further information: > https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html >

Re: [PATCH 1/2] powerpc: Apply __always_inline to interrupt_{enter,exit}_prepare()

will inheret instrumentation from their caller. > > KCSAN kernels were observed to compile without inlining these routines, > which would lead to grief on NMI handlers. > > Signed-off-by: Rohan McLure Reviewed-by: Christophe Leroy > --- > arch/powerpc/include/asm/interru

Re: [PATCH 2/2] powerpc/64: Only warn for kuap locked when KCSAN not present

Le 04/04/2024 à 06:45, Rohan McLure a écrit : > Arbitrary instrumented locations, including syscall handlers, can call > arch_local_irq_restore() transitively when KCSAN is enabled, and in turn > also replay_soft_interrupts_irqrestore(). The precondition on entry to > this routine that is checked

Re: [RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()

Le 27/03/2024 à 17:57, Jason Gunthorpe a écrit : > On Wed, Mar 27, 2024 at 09:58:35AM +0000, Christophe Leroy wrote: >>> Just general remarks on the ones with huge pages: >>> >>>hash 64k and hugepage 16M/16G >>>radix 64k/radix hugepage 2M/

Re: [PATCH v4 05/13] mm/arch: Provide pud_pfn() fallback

Le 03/04/2024 à 15:07, Jason Gunthorpe a écrit : > On Wed, Apr 03, 2024 at 12:26:43PM +0000, Christophe Leroy wrote: >> >> >> Le 03/04/2024 à 14:08, Jason Gunthorpe a écrit : >>> On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote: >>>> On Tu

Re: [PATCH v4 05/13] mm/arch: Provide pud_pfn() fallback

Le 03/04/2024 à 14:08, Jason Gunthorpe a écrit : > On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote: >> On Tue, Apr 02, 2024 at 07:53:20PM -0300, Jason Gunthorpe wrote: >>> On Tue, Apr 02, 2024 at 06:43:56PM -0400, Peter Xu wrote: >>> I actually tested this without hitting the issue

Re: [PATCH 01/34] powerpc/fsl-soc: hide unused const variable

NFIG_EPAPR_PARAVIRT for hcalls") > Signed-off-by: Arnd Bergmann Reviewed-by: Christophe Leroy > --- > arch/powerpc/sysdev/fsl_msi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c > index 8e6c

Re: [PATCH v3 2/2] powerpc/bpf: enable kfunc call

Le 02/04/2024 à 12:58, Hari Bathini a écrit : > Currently, bpf jit code on powerpc assumes all the bpf functions and > helpers to be kernel text. This is false for kfunc case, as function > addresses can be module addresses as well. So, ensure module addresses > are supported to enable kfunc supp

Re: [PATCH v3 1/2] powerpc64/bpf: fix tail calls for PCREL addressing

Le 02/04/2024 à 12:58, Hari Bathini a écrit : > With PCREL addressing, there is no kernel TOC. So, it is not setup in > prologue when PCREL addressing is used. But the number of instructions > to skip on a tail call was not adjusted accordingly. That resulted in > not so obvious failures while us

Re: [PATCH v11 00/11] Support page table check PowerPC

Le 28/03/2024 à 08:57, Christophe Leroy a écrit : > > > Le 28/03/2024 à 07:52, Christophe Leroy a écrit : >> >> >> Le 28/03/2024 à 05:55, Rohan McLure a écrit : >>> Support page table check on all PowerPC platforms. This works by >>> serialising

Re: [PATCH v11 00/11] Support page table check PowerPC

Le 28/03/2024 à 07:52, Christophe Leroy a écrit : > > > Le 28/03/2024 à 05:55, Rohan McLure a écrit : >> Support page table check on all PowerPC platforms. This works by >> serialising assignments, reassignments and clears of page table >> entries at each le

Re: [PATCH v11 00/11] Support page table check PowerPC

Le 28/03/2024 à 05:55, Rohan McLure a écrit : > Support page table check on all PowerPC platforms. This works by > serialising assignments, reassignments and clears of page table > entries at each level in order to ensure that anonymous mappings > have at most one writable consumer, and likewise

Re: [PATCH v11 09/11] poweprc: mm: Implement *_user_accessible_page() for ptes

Le 28/03/2024 à 05:55, Rohan McLure a écrit : > Page table checking depends on architectures providing an > implementation of p{te,md,ud}_user_accessible_page. With > refactorisations made on powerpc/mm, the pte_access_permitted() and > similar methods verify whether a userland page is accessible

Re: [PATCH v11 08/11] powerpc: mm: Add pud_pfn() stub

Le 28/03/2024 à 05:55, Rohan McLure a écrit : > The page table check feature requires that pud_pfn() be defined > on each consuming architecture. Since only 64-bit, Book3S platforms > allow for hugepages at this upper level, and since the calling code is > gated by a call to pud_user_accessible_p

Re: [PATCH] Add static_key_feature_checks_initialized flag

Le 27/03/2024 à 05:59, Nicholas Miehlbradt a écrit : > JUMP_LABEL_FEATURE_CHECK_DEBUG used static_key_initialized to determine > whether {cpu,mmu}_has_feature() was used before static keys were > initialized. However, {cpu,mmu}_has_feature() should not be used before > setup_feature_keys() is cal

Re: [RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()

Le 26/03/2024 à 16:01, Jason Gunthorpe a écrit : > On Mon, Mar 25, 2024 at 07:05:01PM +0000, Christophe Leroy wrote: > >> Not looked into details yet, but I guess so. >> >> By the way there is a wiki dedicated to huge pages on powerpc, you can >> have a look at i

Re: [PATCH v2 3/3] powerpc/code-patching: Restore 32-bit patching performance

up.eu/ > > Suggested-by: Christophe Leroy > Signed-off-by: Benjamin Gray > > --- > > v2: * New in v2 > > I think Suggested-by is an appropriate tag. The patch is Christophe's > from the link, I just added the commit description, so it could well > be better

Re: [RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()

Le 25/03/2024 à 17:19, Jason Gunthorpe a écrit : > On Mon, Mar 25, 2024 at 03:55:54PM +0100, Christophe Leroy wrote: >> Unlike many architectures, powerpc 8xx hardware tablewalk requires >> a two level process for all page sizes, allthough second level only >> has one entr

[RFC PATCH 8/8] powerpc/8xx: Add back support for 8M pages using contiguous PTE entries

is addressing an 8M page, this is required for the HW tablewalk assistance. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/hugetlb.h| 11 - .../include/asm/nohash/32/hugetlb-8xx.h | 28 +++- arch/powerpc/include/asm/nohash/32/pgalloc.h | 2 + arch

[RFC PATCH 7/8] powerpc/8xx: Remove support for 8M pages

Remove support for 8M pages in order to stop using hugepd. Support for 8M pages will be added back later using the same approach as for 512k pages, in extenso using contiguous page entries in the regular page table. Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig

Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2

Le 21/03/2024 à 23:07, pet...@redhat.com a écrit : > From: Peter Xu > > v3: > - Rebased to latest mm-unstalbe (a824831a082f, of March 21th) > - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also >pXd_huge() users) with pXd_leaf() [Jason] > - Add a comment for CONFIG_P

[RFC PATCH 6/8] powerpc/8xx: Fix size given to set_huge_pte_at()

set_huge_pte_at() expects the real page size, not the psize which is the index of the page definition in table mmu_psize_defs[] Fixes: 935d4f0c6dc8 ("mm: hugetlb: add huge page size param to set_huge_pte_at()") Signed-off-by: Christophe Leroy --- arch/powerpc/mm/nohash/8xx.c | 3 +

[RFC PATCH 5/8] powerpc/mm: Allow hugepages without hugepd

In preparation of implementing huge pages on powerpc 8xx without hugepd, enclose hugepd related code inside an ifdef CONFIG_ARCH_HAS_HUGEPD Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/hugetlb.h| 2 ++ arch/powerpc/include/asm/nohash/pgtable.h | 8 +--- arch

[RFC PATCH 4/8] mm: Provide mm_struct and address to huge_ptep_get()

pmd. In order to be consistent with huge_ptep_get_and_clear(), give mm and address to huge_ptep_get(). Signed-off-by: Christophe Leroy --- arch/arm64/include/asm/hugetlb.h | 2 +- fs/hugetlbfs/inode.c | 2 +- fs/proc/task_mmu.c | 8 +++--- fs/userfaultfd.c

[RFC PATCH 3/8] mm: Provide pmd to pte_leaf_size()

On powerpc 8xx, when a page is 8M size, the information is in the PMD entry. So provide it to pte_leaf_size(). Signed-off-by: Christophe Leroy --- arch/arm64/include/asm/pgtable.h | 2 +- arch/powerpc/include/asm/nohash/32/pte-8xx.h | 2 +- arch/riscv/include/asm/pgtable.h

[RFC PATCH 2/8] mm: Provide page size to pte_alloc_huge()

In order to be able to flag the PMD entry with _PMD_HUGE_8M on powerpc 8xx, provide page size to pte_alloc_huge() and use it through the newly introduced pte_alloc_size(). Signed-off-by: Christophe Leroy --- arch/arm64/mm/hugetlbpage.c | 2 +- arch/parisc/mm/hugetlbpage.c | 2 +- arch

[RFC PATCH 1/8] mm: Provide pagesize to pmd_populate()

use by pte_alloc_huge(). When an architecture doesn't provide pmd_populate_size(), pmd_populate() is used as a fallback. Signed-off-by: Christophe Leroy --- include/linux/mm.h | 12 +++- mm/filemap.c | 2 +- mm/internal.h | 2 +- mm/memory.c

[RFC PATCH 0/8] Reimplement huge pages without hugepd on powerpc 8xx

8M page. At the moment it has to look into each helper to know if the hugepage ptep is a PTE or a PMD in order to know it is a 8M page or a lower size. I hope this can me handled by core-mm in the future. There are probably several ways to implement stuff, so feedback is very welcome. Christophe

Re: [FSL P50x0] Kernel 6.9-rc1 compiling issue

Hi, Le 25/03/2024 à 06:18, Christian Zigotzky a écrit : > I have created a patch: > > --- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:14:02.201209476 +0100 > +++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:10:04.421425931 +0100 > @@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_d

Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()

Le 20/03/2024 à 17:09, Peter Xu a écrit : > On Wed, Mar 20, 2024 at 06:16:43AM +0000, Christophe Leroy wrote: >> At the first place that was to get a close fit between hardware >> pagetable topology and linux pagetable topology. But obviously we >> already stepped back for

Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()

Le 20/03/2024 à 00:26, Jason Gunthorpe a écrit : > On Tue, Mar 19, 2024 at 11:07:08PM +0000, Christophe Leroy wrote: >> >> >> Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit : >>> On Thu, Mar 14, 2024 at 01:11:59PM +, Christophe Leroy wrote: >>>> &

Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()

Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit : > On Thu, Mar 14, 2024 at 01:11:59PM +0000, Christophe Leroy wrote: >> >> >> Le 14/03/2024 à 13:53, Peter Xu a écrit : >>> On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote: >>>> >>&g

Re: [PATCH] powerpc: Use swapper_pg_dir instead of init_mm->pgd

Le 09/10/2022 à 19:31, Christophe Leroy a écrit : > init_mm->pgd is always swapper_pg_dir[] which is known > at build time. > > Directly use the later instead of loading it from init_mm > struct at every time. > > Signed-off-by: Christophe Leroy Dropping this p

[PATCH v2] powerpc: Handle error in mark_rodata_ro() and mark_initmem_nx()

mark_rodata_ro() and mark_initmem_nx() use functions that can fail like set_memory_nx() and set_memory_ro(), leading to a not protected kernel. In case of failure, panic. Link: https://github.com/KSPP/linux/issues/7 Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https

Re: [PATCH v1 2/2] powerpc/code-patching: Convert to open_patch_window()/close_patch_window()

Le 15/03/2024 à 09:38, Christophe Leroy a écrit : > > > Le 15/03/2024 à 03:59, Benjamin Gray a écrit : >> The existing patching alias page setup and teardown sections can be >> simplified to make use of the new open_patch_window() abstraction. >> >> This e

Re: [PATCH v1 2/2] powerpc/code-patching: Convert to open_patch_window()/close_patch_window()

Le 15/03/2024 à 09:38, Christophe Leroy a écrit : > > > Le 15/03/2024 à 03:59, Benjamin Gray a écrit : >> The existing patching alias page setup and teardown sections can be >> simplified to make use of the new open_patch_window() abstraction. >> >> This e

Re: Cannot load wireguard module

Hi, Le 15/03/2024 à 13:20, Michal Suchánek a écrit : > Hello, > > I cannot load the wireguard module. > > Loading the module provides no diagnostic other than 'No such device'. > > Please provide maningful diagnostics for loading software-only driver, > clearly there is no particular device nee

Re: [PATCH v1 2/2] powerpc/code-patching: Convert to open_patch_window()/close_patch_window()

Le 15/03/2024 à 03:59, Benjamin Gray a écrit : > The existing patching alias page setup and teardown sections can be > simplified to make use of the new open_patch_window() abstraction. > > This eliminates the _mm variants of the helpers, consumers no longer > need to check mm_patch_enabled(), a

Re: linux-next: manual merge of the powerpc tree with the mm-stable tree

Le 29/02/2024 à 07:37, Michael Ellerman a écrit : > Stephen Rothwell writes: >> Hi all, >> >> Today's linux-next merge of the powerpc tree got a conflict in: >> >>arch/powerpc/mm/pgtable_32.c >> >> between commit: >> >>a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor >>

Re: [PATCH v1 1/3] powerpc/code-patching: Test patch_instructions() during boot

Le 15/03/2024 à 03:57, Benjamin Gray a écrit : > patch_instructions() introduces new behaviour with a couple of > variations. Test each case of > >* a repeated 32-bit instruction, >* a repeated 64-bit instruction (ppc64), and >* a copied sequence of instructions > > for both on a si

Re: [PATCH v1 3/3] powerpc/code-patching: Optimise patch_memcpy() to 4 byte chunks

Le 15/03/2024 à 03:57, Benjamin Gray a écrit : > As we are patching instructions, we can assume the length is a multiple > of 4 and the destination address is aligned. > > Atomicity of patching a prefixed instruction is not a concern, as the > original implementation doesn't provide it anyway.

Re: [PATCH v1 2/3] powerpc/code-patching: Use dedicated memory routines for patching

Le 15/03/2024 à 03:57, Benjamin Gray a écrit : > The patching page set up as a writable alias may be in quadrant 1 > (userspace) if the temporary mm path is used. This causes sanitiser > failures if so. Sanitiser failures also occur on the non-mm path > because the plain memset family is instrume

Re: [PATCH v9 07/27] net: wan: Add support for QMC HDLC

erve Codina >> Reviewed-by: Christophe Leroy >> Acked-by: Jakub Kicinski >> --- > [ ... ] > >> + >> +static const struct of_device_id qmc_hdlc_id_table[] = { >> +{ .compatible = "fsl,qmc-hdlc" }, >> +{} /* sentinel */ >> +}; >&g

Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()

Le 14/03/2024 à 13:53, Peter Xu a écrit : > On Thu, Mar 14, 2024 at 08:45:34AM +0000, Christophe Leroy wrote: >> >> >> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit : >>> From: Peter Xu >>> >>> PowerPC book3s 4K mostly has the same definition o

Re: [PATCH v6 1/9] locking/mutex: introduce devm_mutex_init

mutex_init() > > Signed-off-by: George Stark > Suggested by-by: Christophe Leroy s/Suggested by-by/Suggested-by: Reviewed-by: Christophe Leroy > --- > include/linux/mutex.h| 27 +++ > kernel/locking/mutex-debug.c | 11 +++ > 2 fi

Re: [PATCH 12/13] mm/treewide: Remove pXd_huge()

Le 13/03/2024 à 22:47, pet...@redhat.com a écrit : > From: Peter Xu > > This API is not used anymore, drop it for the whole tree. > > Signed-off-by: Peter Xu > --- > arch/arm/mm/Makefile | 1 - > arch/arm/mm/hugetlbpage.c | 29 -

Re: [PATCH 11/13] mm/treewide: Replace pXd_huge() with pXd_leaf()

Le 13/03/2024 à 22:47, pet...@redhat.com a écrit : > From: Peter Xu > > Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(), > reuse it. Luckily, pXd_huge() isn't widely used. > > Signed-off-by: Peter Xu > --- > arch/arm/include/asm/pgtable-3level.h | 2 +- > arch/a

Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()

ge() treewide. > > NOTE: *_leaf() definition need to be moved before the inclusion of > asm/book3s/64/pgtable-4k.h, which defines pXd_huge() with it. > > [1] https://lore.kernel.org/r/87v85zo6w7.fsf@mail.lhotse > > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc: Ch

Re: [PATCH v10 11/12] powerpc: mm: Use set_pte_at_unchecked() for early-boot / internal usages

Le 13/03/2024 à 05:21, Rohan McLure a écrit : > In the new set_ptes() API, set_pte_at() (a special case of set_ptes()) > is intended to be instrumented by the page table check facility. There > are however several other routines that constitute the API for setting > page table entries, including

Re: [PATCH v10 10/12] poweprc: mm: Implement *_user_accessible_page() for ptes

Le 13/03/2024 à 05:21, Rohan McLure a écrit : > Page table checking depends on architectures providing an > implementation of p{te,md,ud}_user_accessible_page. With > refactorisations made on powerpc/mm, the pte_access_permitted() and > similar methods verify whether a userland page is accessible

Re: [PATCH v10 09/12] powerpc: mm: Add common pud_pfn stub for all platforms

Le 13/03/2024 à 05:21, Rohan McLure a écrit : > Prior to this commit, pud_pfn was implemented with BUILD_BUG as the inline > function for 64-bit Book3S systems but is never included, as its > invocations in generic code are guarded by calls to pud_devmap which return > zero on such systems. A fut

Re: [PATCH v10 08/12] powerpc: mm: Replace p{u,m,4}d_is_leaf with p{u,m,4}_leaf

re's already an equivalent commit in mm-stable, that will likely go into v6.9: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-stable&id=bd18b688220c7225fb50498dabd9f9d0c9988e67 > > Reviewed-by: Christophe Leroy > Signed-off-by: Rohan McLure > ---

Re: [PATCH v3 07/12] powerpc: Use initializer for struct vm_unmapped_area_info

rstand from this text that, as agreed, this patch removes the pointless/redundant zero-init of individual members. But it is not what is done, see below ? > > Signed-off-by: Rick Edgecombe > Acked-by: Michael Ellerman > Cc: Michael Ellerman > Cc: Nicholas Piggin > Cc:

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

Le 12/03/2024 à 16:30, George Stark a écrit : > [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com. > Découvrez pourquoi ceci est important à > https://aka.ms/LearnAboutSenderIdentification ] > > Hello Christophe > > On 3/12/24 14:51, Christophe Ler

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

Le 12/03/2024 à 12:39, George Stark a écrit : > [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com. > Découvrez pourquoi ceci est important à > https://aka.ms/LearnAboutSenderIdentification ] > > Hello Christophe > > Thanks for the review > You were right about typecheck -

Re: [PATCH] powerpc/kernel: Fix potential spectre v1 in syscall

+Nathan as this is RTAS related. Le 21/08/2018 à 20:42, Breno Leitao a écrit : > The rtas syscall reads a value from a user-provided structure and uses it > to index an array, being a possible area for a potential spectre v1 attack. > This is the code that exposes this problem. > > args.ret

Re: [PATCH 1/2] powerpc: Flush checkpointed gpr state for 32-bit processes in ptrace

Le 19/06/2018 à 21:54, Pedro Franco de Carvalho a écrit : > Would something like this be ok? > > I factored out the calls to flush_fp_to_thread and flush_altivec_to_thread, > although I don't really understand why these are necessary. The > tm_cvsx_get/set > functions also calls flush_vsx_to_th

Re: [PATCH] powerpc: build-time fixup alternate feature relative addresses

Le 29/01/2024 à 07:25, Sathvika Vasireddy a écrit : > Hi Christophe, Nick > > On 1/26/24 12:32 AM, Christophe Leroy wrote: >> Hi Nic, >> >> Le 21/05/2017 à 03:01, Nicholas Piggin a écrit : >>> Implement build-time fixup of alternate feature relative addr

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

jects that >>>>> often is bound to other resources and has no own devm wrapping. >>>>> Since mutex_destroy() actually does nothing in non-debug builds >>>>> frequently calling mutex_destroy() is just ignored which is safe >&g

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

Le 12/03/2024 à 02:10, Waiman Long a écrit : > On 3/11/24 19:47, George Stark wrote: >> Hello Waiman, Marek >> >> Thanks for the review. >> >> I've never used lockdep for debug but it seems preferable to >> keep that feature working. It could be look like this: >> >> diff --git a/include/linux/mu

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

g formally and can lead to a problem if mutex_destroy() will be >>> extended so introduce devm_mutex_init() >>> >>> Signed-off-by: George Stark >>> Signed-off-by: Christophe Leroy >> >>>   Hello Christophe. Hope you don't mind I put you SoB tag bec

Re: [RFC PATCH v2 1/3] powerpc/prom_init: Replace linux,sml-base/sml-size with linux,sml-log

Le 11/03/2024 à 14:20, Stefan Berger a écrit : > linux,sml-base holds the address of a buffer with the TPM log. This > buffer may become invalid after a kexec. To avoid accessing an invalid > address or corrupted buffer, embed the whole TPM log in the device tree > property linux,sml-log. This he

Re: [PATCH RFC 00/13] mm/treewide: Remove pXd_huge() API

Le 06/03/2024 à 11:41, pet...@redhat.com a écrit : > From: Peter Xu > > [based on akpm/mm-unstable latest commit a7f399ae964e] > > In previous work [1], we removed the pXd_large() API, which is arch > specific. This patchset further removes the hugetlb pXd_huge() API. > > Hugetlb was never s

Re: [PATCH 3/3] tools/perf/arch/powerc: Add get_arch_regnum for powerpc

Le 09/03/2024 à 08:25, Athira Rajeev a écrit : > The function get_dwarf_regnum() returns a DWARF register number > from a register name string. This calls arch specific function > get_arch_regnum to return register number for corresponding arch. > Add mappings for register name to register number

Re: [PATCH 1/3] tools/perf/arch/powerpc: Add load/store in powerpc annotate instructions for data type profling

Le 09/03/2024 à 08:25, Athira Rajeev a écrit : > Add powerpc instruction nmemonic table to associate load/store > instructions with move_ops. mov_ops is used to identify mem_type > to associate instruction with data type and offset. Also initialize > and allocate arch specific fields for nr_instr

Re: [PATCH 01/19] vdso: Consolidate vdso_calc_delta()

Le 08/03/2024 à 14:14, Adrian Hunter a écrit : > [Vous ne recevez pas souvent de courriers de adrian.hun...@intel.com. > Découvrez pourquoi ceci est important à > https://aka.ms/LearnAboutSenderIdentification ] > > Consolidate vdso_calc_delta(), in preparation for further simplification. > >

<    1   2   3   4   5   6   7   8   9   10   >