Re: [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP
On Mon, Mar 24, 2025, at 14:50, Greg Ungerer wrote: > On 24/3/25 18:02, Arnd Bergmann wrote: >> On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote: >>> On 15/3/25 20:59, Arnd Bergmann wrote: >> >> Does this fixup work for you? > > Yes, this looks good, works for me. > Feel free to add this if you like: > > Acked-by: Greg Ungerer Added now, thanks! >> On a related note, I'm curious about how the MCF54xx chips are >> used in practice, as I see that they are the only coldfire chips >> with PCI and they all have an MMU. Are there actual users of these >> chips that have PCI but choose not to use the MMU? > > No, I think everyone with these uses them with MMU enabled. > > It is probably more of an historical curiosity to use them with > the MMU disabled. That supported pre-dated mainline kernels having > full ColdFire MMU support by a good few years. Ok, good to know. Given that there are no other chips that allow PCI on !MMU kernels, I wonder if we should just make PCI itself depend on MMU, and remove the "depends on MMU" for any PCI drivers that currently have it. There is no fundamental dependency here, but it is something that breaks occasionally because of in-kernel interfaces that don't work as expected on !MMU configurations, and with an extra dependency we could stop fixing those. Arnd
Re: [PATCH v4 1/3] lsm: introduce new hooks for setting/getting inode fsxattr
On Fri, Mar 21, 2025 at 08:48:40PM +0100, Andrey Albershteyn wrote:
> Introduce new hooks for setting and getting filesystem extended
> attributes on inode (FS_IOC_FSGETXATTR).
>
> Cc: seli...@vger.kernel.org
> Cc: Paul Moore
>
> Signed-off-by: Andrey Albershteyn
> ---
> fs/ioctl.c| 7 ++-
> include/linux/lsm_hook_defs.h | 4
> include/linux/security.h | 16
> security/security.c | 32
> 4 files changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index
> 638a36be31c14afc66a7fd6eb237d9545e8ad997..4434c97bc5dff5a3e8635e28745cd99404ff353e
> 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -525,10 +525,15 @@ EXPORT_SYMBOL(fileattr_fill_flags);
> int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa)
> {
> struct inode *inode = d_inode(dentry);
> + int error;
>
> if (!inode->i_op->fileattr_get)
> return -ENOIOCTLCMD;
>
> + error = security_inode_getfsxattr(inode, fa);
It would help for both of these hooks to pass the dentry instead of the
inode.
> + if (error)
> + return error;
> +
> return inode->i_op->fileattr_get(dentry, fa);
> }
> EXPORT_SYMBOL(vfs_fileattr_get);
> @@ -692,7 +697,7 @@ int vfs_fileattr_set(struct mnt_idmap *idmap, struct
> dentry *dentry,
> fa->flags |= old_ma.flags & ~FS_COMMON_FL;
> }
> err = fileattr_set_prepare(inode, &old_ma, fa);
> - if (!err)
> + if (!err && !security_inode_setfsxattr(inode, fa))
> err = inode->i_op->fileattr_set(idmap, dentry, fa);
> }
> inode_unlock(inode);
Re: [PATCH] tools/perf/arch/powerpc/util: Fix is_compat_mode build break in ppc64
On Fri, 21 Mar 2025 15:37:26 +0530, Likhitha Korrapati wrote:
> Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to
> handle compatible mode PVR for perf json events") introduced
> to select proper JSON events in case of compat mode using
> auxiliary vector. But this caused a compilation error in ppc64
> Big Endian.
>
> arch/powerpc/util/header.c: In function 'is_compat_mode':
> arch/powerpc/util/header.c:20:21: error: cast to pointer from
> integer of different size [-Werror=int-to-pointer-cast]
>20 | if (!strcmp((char *)platform, (char *)base_platform))
> | ^
> arch/powerpc/util/header.c:20:39: error: cast to pointer from
> integer of different size [-Werror=int-to-pointer-cast]
>20 | if (!strcmp((char *)platform, (char *)base_platform))
> |
>
> [...]
Applied to perf-tools-next, thanks!
Best regards,
Namhyung
Re: [PATCH] tools/perf/arch/powerpc/util: Fix is_compat_mode build break in ppc64
On 21/03/25 3:37 pm, Likhitha Korrapati wrote:
Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to
handle compatible mode PVR for perf json events") introduced
to select proper JSON events in case of compat mode using
auxiliary vector. But this caused a compilation error in ppc64
Big Endian.
arch/powerpc/util/header.c: In function 'is_compat_mode':
arch/powerpc/util/header.c:20:21: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
| ^
arch/powerpc/util/header.c:20:39: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
|
Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM)
return values in u64 which causes the compilation error.
Patch fixes this issue by changing u64 to "unsigned long".
Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle compatible
mode PVR for perf json events")
Signed-off-by: Likhitha Korrapati
---
tools/perf/arch/powerpc/util/header.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index c7df534dbf8f..0be74f048f96 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -14,8 +14,8 @@
static bool is_compat_mode(void)
{
- u64 base_platform = getauxval(AT_BASE_PLATFORM);
- u64 platform = getauxval(AT_PLATFORM);
+ unsigned long base_platform = getauxval(AT_BASE_PLATFORM);
+ unsigned long platform = getauxval(AT_PLATFORM);
if (!strcmp((char *)platform, (char *)base_platform))
return false;
Applied this patch on the powerpc kernel and it fixes the issue.
Without this patch:
INSTALL libsubcmd_headers
INSTALL libsymbol_headers
INSTALL libperf_headers
INSTALL libapi_headers
CC /output/arch/powerpc/util/header.o
CC /output/arch/powerpc/util/perf_regs.o
CC /output/arch/powerpc/util/mem-events.o
CC /output/arch/powerpc/util/pmu.o
CC /output/arch/powerpc/util/sym-handling.o
CC /output/arch/powerpc/util/evsel.o
CC /output/arch/powerpc/util/event.o
arch/powerpc/util/header.c: In function 'is_compat_mode':
arch/powerpc/util/header.c:20:21: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
| ^
arch/powerpc/util/header.c:20:39: error: cast to pointer from integer of
different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
| ^
cc1: all warnings being treated as errors
make[6]: *** [/linux/tools/build/Makefile.build:85:
/output/arch/powerpc/util/header.o] Error 1
make[6]: *** Waiting for unfinished jobs
make[5]: *** [/linux/tools/build/Makefile.build:138: util] Error 2
make[4]: *** [/linux/tools/build/Makefile.build:138: powerpc] Error 2
make[3]: *** [/linux/tools/build/Makefile.build:138: arch] Error 2
make[3]: *** Waiting for unfinished jobs
make[2]: *** [Makefile.perf:781: /output/perf-util-in.o] Error 2
make[1]: *** [Makefile.perf:280: sub-make] Error 2
make: *** [Makefile:76: all] Error 2
make: Leaving directory '/linux/tools/perf'
With this patch:
PERF_VERSION = 6.14.rc4.gbdfd7b9150f1
INSTALL libapi_headers
GEN perf-archive
GEN perf-iostat
INSTALL libperf_headers
CC /output/arch/powerpc/util/header.o
LD /output/arch/powerpc/util/perf-util-in.o
LD /output/arch/powerpc/perf-util-in.o
LD /output/arch/perf-util-in.o
CC /output/util/header.o
LD /output/util/perf-util-in.o
LD /output/perf-util-in.o
AR /output/libperf-util.a
LINK /output/perf
make: Leaving directory '/linux/tools/perf'
## tools/perf build completed rc = 0
## Build completed OK
Please add below tag:
Tested-by: Venkat Rao Bagalkote
Regards,
Venkat.
Re: [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP
Hi Arnd,
On 24/3/25 18:02, Arnd Bergmann wrote:
On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote:
Hi Arnd,
On 15/3/25 20:59, Arnd Bergmann wrote:
From: Arnd Bergmann
There is no need to go through the GENERIC_IOMAP wrapper for PIO on
nommu platforms, since these always come from PCI I/O space that is
itself memory mapped.
Instead, the generic ioport_map() can just return the MMIO location
of the ports directly by applying the PCI_IO_PA offset, while
ioread32/iowrite32 trivially turn into readl/writel as they do
on most other architectures.
Signed-off-by: Arnd Bergmann
With this applied this fails to build for me:
UPD include/generated/utsversion.h
CC init/version-timestamp.o
LD vmlinux
m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
`quirk_switchtec_ntb_dma_alias':
quirks.c:(.text+0x23e4): undefined reference to `pci_iomap'
m68k-linux-uclibc-ld: quirks.c:(.text+0x24fe): undefined reference to
`pci_iounmap'
m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
`disable_igfx_irq':
quirks.c:(.text+0x32f4): undefined reference to `pci_iomap'
m68k-linux-uclibc-ld: quirks.c:(.text+0x3348): undefined reference to
`pci_iounmap'
Thanks for the report, I was able to reproduce the problem now
and applied the fixup below. I had tested m5475evb_defconfig earlier,
and that built cleanly with PCI enabled, but I had missed how
that still used GENERIC_IOMAP because it has CONFIG_MMU enabled.
Does this fixup work for you?
Yes, this looks good, works for me.
Feel free to add this if you like:
Acked-by: Greg Ungerer
On a related note, I'm curious about how the MCF54xx chips are
used in practice, as I see that they are the only coldfire chips
with PCI and they all have an MMU. Are there actual users of these
chips that have PCI but choose not to use the MMU?
No, I think everyone with these uses them with MMU enabled.
It is probably more of an historical curiosity to use them with
the MMU disabled. That supported pre-dated mainline kernels having
full ColdFire MMU support by a good few years.
Regards
Greg
Arnd
8<-
From a36995e2a64711556c6773797367d165828f6705 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 24 Mar 2025 07:53:47 +0100
Subject: [PATCH] m68k: coldfire: select PCI_IOMAP for PCI
After I dropped CONFIG_GENERIC_IOMAP, some PCI drivers started failing
to link when CONFIG_MMU is disabled:
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/i740fb.ko] undefined!
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iomap_wc" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iomap" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/s3fb.ko] undefined!
...
It turns out that there were two mistakes in my patch: on !MMU I forgot
to enable CONFIG_GENERIC_PCI_IOMAP, and for Coldfire with MMU enabled,
teh GENERIC_IOMAP was left in place but incorrectly configured.
Fixes: 9d48cc07d0d7 ("m68k/nommu: stop using GENERIC_IOMAP")
Reported-by: Greg Ungerer
Signed-off-by: Arnd Bergmann
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index b50c275fa94d..eb5bb6d36899 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,12 +18,13 @@ config M68K
select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
- select GENERIC_IOMAP if HAS_IOPORT && MMU
+ select GENERIC_IOMAP if HAS_IOPORT && MMU && !COLDFIRE
select GENERIC_IRQ_SHOW
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_MULDI3
+ select GENERIC_PCI_IOMAP if PCI
select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
select HAVE_ARCH_LIBGCC_H
select HAVE_ARCH_SECCOMP
Re: [PATCH 1/2] mm/ptdump: Split note_page() into level specific callbacks
On 3/17/25 11:48, Anshuman Khandual wrote:
> Last argument passed down in note_page() is u64 assuming pxd_val() returned
> value (all page table levels) is 64 bit - which might not be the case going
> ahead when D128 page tables is enabled on arm64 platform. Besides pxd_val()
> is very platform specific and its type should not be assumed in generic MM.
>
> Split note_page() into individual page table level specific callbacks which
> accepts corresponding pxd_t argument instead and then subscribing platforms
> just derive pxd_val() from the entries as required and proceed as earlier.
>
> Also add a note_page_flush() callback for flushing the last page table page
> that was being handled earlier via level = -1.
Does this look good OR is there any concern OR an alternate approach ?
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Madhavan Srinivasan
> Cc: Nicholas Piggin
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Gerald Schaefer
> Cc: Heiko Carstens
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Andrew Morton
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@kvack.org
> Signed-off-by: Anshuman Khandual
> ---
> arch/arm64/include/asm/ptdump.h | 16 +--
> arch/arm64/mm/ptdump.c | 48 ++---
> arch/powerpc/mm/ptdump/ptdump.c | 46 +--
> arch/riscv/mm/ptdump.c | 46 +--
> arch/s390/mm/dump_pagetables.c | 46 +--
> arch/x86/mm/dump_pagetables.c | 39 ++-
> include/linux/ptdump.h | 9 ---
> mm/ptdump.c | 42 ++---
> 8 files changed, 267 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 6cf4aae05219..e5da9ce8a515 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -59,7 +59,13 @@ struct ptdump_pg_state {
>
> void ptdump_walk(struct seq_file *s, struct ptdump_info *info);
> void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> -u64 val);
> +pteval_t val);
> +void note_page_pte(struct ptdump_state *st, unsigned long addr, pte_t pte);
> +void note_page_pmd(struct ptdump_state *st, unsigned long addr, pmd_t pmd);
> +void note_page_pud(struct ptdump_state *st, unsigned long addr, pud_t pud);
> +void note_page_p4d(struct ptdump_state *st, unsigned long addr, p4d_t p4d);
> +void note_page_pgd(struct ptdump_state *st, unsigned long addr, pgd_t pgd);
> +void note_page_flush(struct ptdump_state *st);
> #ifdef CONFIG_PTDUMP_DEBUGFS
> #define EFI_RUNTIME_MAP_END DEFAULT_MAP_WINDOW_64
> void __init ptdump_debugfs_register(struct ptdump_info *info, const char
> *name);
> @@ -69,7 +75,13 @@ static inline void ptdump_debugfs_register(struct
> ptdump_info *info,
> #endif /* CONFIG_PTDUMP_DEBUGFS */
> #else
> static inline void note_page(struct ptdump_state *pt_st, unsigned long addr,
> - int level, u64 val) { }
> + int level, pteval_t val) { }
> +static inline void note_page_pte(struct ptdump_state *st, unsigned long
> addr, pte_t pte) { }
> +static inline void note_page_pmd(struct ptdump_state *st, unsigned long
> addr, pmd_t pmd) { }
> +static inline void note_page_pud(struct ptdump_state *st, unsigned long
> addr, pud_t pud) { }
> +static inline void note_page_p4d(struct ptdump_state *st, unsigned long
> addr, p4d_t p4d) { }
> +static inline void note_page_pgd(struct ptdump_state *st, unsigned long
> addr, pgd_t pgd) { }
> +static inline void note_page_flush(struct ptdump_state *st) { }
> #endif /* CONFIG_PTDUMP_CORE */
>
> #endif /* __ASM_PTDUMP_H */
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index 688fbe0271ca..fd1610b4fd15 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -189,7 +189,7 @@ static void note_prot_wx(struct ptdump_pg_state *st,
> unsigned long addr)
> }
>
> void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> -u64 val)
> +pteval_t val)
> {
> struct ptdump_pg_state *st = container_of(pt_st, struct
> ptdump_pg_state, ptdump);
> struct ptdump_pg_level *pg_level = st->pg_level;
> @@ -251,6 +251,38 @@ void note_page(struct ptdump_state *pt_st, unsigned long
> addr, int level,
>
> }
>
> +void note_page_pte(struct ptdump_state *pt_st, unsigned long addr, pte_t pte)
> +{
> + note_page(pt_st, addr, 4, pte_val(pte));
> +}
> +
> +void note_page_pmd(struct ptdump_state *pt_st, unsigned long addr, pmd_t pmd)
> +{
> + note_page(pt_st, addr, 3, pmd_val(pmd));
> +}
> +
> +void note_page_pud(struct ptdump_state *pt_st, unsigned long addr, pud_t pud)
> +{
> + note_page
Re: PowerPC: Observing Kernel softlockup while running ftrace selftest
On 12/03/25 11:32 am, Venkat Rao Bagalkote wrote: On 10/03/25 4:25 pm, Hari Bathini wrote: Venkat, can you confirm if the issue is reproducible disabling CONFIG_PPC_IRQ_SOFT_MASK_DEBUG ? Hari, This issue is reproducible after diabling CONFIG_PPC_IRQ_SOFT_MASK_DEBUG. # powerpc Debugging # CONFIG_PPC_DISABLE_WERROR=y CONFIG_PRINT_STACK_DEPTH=64 # CONFIG_HCALL_STATS is not set CONFIG_PPC_EMULATED_STATS=y # CONFIG_CODE_PATCHING_SELFTEST is not set CONFIG_JUMP_LABEL_FEATURE_CHECKS=y # CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is not set CONFIG_FTR_FIXUP_SELFTEST=y CONFIG_MSI_BITMAP_SELFTEST=y # CONFIG_GUEST_STATE_BUFFER_TEST is not set # CONFIG_PPC_IRQ_SOFT_MASK_DEBUG is not set CONFIG_PPC_RFI_SRR_DEBUG=y CONFIG_XMON=y # CONFIG_XMON_DEFAULT is not set CONFIG_XMON_DISASSEMBLY=y CONFIG_XMON_DEFAULT_RO_MODE=y CONFIG_DEBUGGER=y CONFIG_BOOTX_TEXT=y # CONFIG_PPC_EARLY_DEBUG is not set # end of powerpc Debugging Regards, Venkat. Hari, My bad. Issue is *NOT* reproducing after diabling CONFIG_PPC_IRQ_SOFT_MASK_DEBUG. Regards, Venkat. On 06/03/25 6:04 pm, Venkat Rao Bagalkote wrote: Greetings!!! I am observing soft lock up's while running ftrace selftest on linux- next kernel. Kernel Version: next-20250305 make run_tests TAP version 13 1..2 # timeout set to 0 # selftests: ftrace: poll # Error: Polling file is not specified not ok 1 selftests: ftrace: poll # exit=255 # timeout set to 0 # selftests: ftrace: ftracetest-ktap # TAP version 13 # 1..155 # ok 1 Basic trace file check # ok 2 Basic test for tracers # ok 3 Basic trace clock test # ok 4 Basic event tracing check # ok 5 Test tracefs GID mount option # ok 6 Change the ringbuffer size # ok 7 Change the ringbuffer sub-buffer size # ok 8 Snapshot and tracing_cpumask # ok 9 Snapshot and tracing setting # ok 10 Test file and directory ownership changes for eventfs # ok 11 Basic tests on writing to trace_marker # ok 12 trace_pipe and trace_marker # not ok 13 Test ftrace direct functions against tracers # UNRESOLVED # not ok 14 Test ftrace direct functions against kprobes # UNRESOLVED # ok 15 Generic dynamic event - add/remove probes with BTF arguments # SKIP # ok 16 Generic dynamic event - add/remove eprobe events # ok 17 Generic dynamic event - Repeating add/remove fprobe events # SKIP # ok 18 Generic dynamic event - add/remove fprobe events # SKIP # ok 19 Generic dynamic event - add/remove kprobe events # ok 20 Generic dynamic event - add/remove synthetic events # ok 21 Generic dynamic event - add/remove tracepoint probe events on module # SKIP # ok 22 Generic dynamic event - add/remove tracepoint probe events # SKIP # ok 23 Generic dynamic event - add/remove/test uprobe events # ok 24 Generic dynamic event - selective clear (compatibility) # ok 25 Checking dynamic events limitations # ok 26 Event probe event parser error log check # ok 27 Fprobe event VFS type argument # SKIP # ok 28 Function return probe entry argument access # SKIP # ok 29 Fprobe event parser error log check # SKIP # ok 30 Generic dynamic event - generic clear event # ok 31 Generic dynamic event - check if duplicate events are caught # ok 32 Tracepoint probe event parser error log check # SKIP # ok 33 event tracing - enable/disable with event level files # not ok 34 event tracing - enable/disable with module event # UNRESOLVED # ok 35 event tracing - restricts events based on pid notrace filtering # ok 36 event tracing - restricts events based on pid # ok 37 event tracing - enable/disable with subsystem level files # ok 38 event tracing - enable/disable with top level files # not ok 39 Test trace_printk from module # UNRESOLVED # ok 40 event filter function - test event filtering on functions # ok 41 ftrace - function graph filters with stack tracer # ok 42 ftrace - function graph filters # ok 43 ftrace - function graph filters # ok 44 ftrace - function profiler with function graph tracing # ok 45 ftrace - function graph print function return value # SKIP # ok 46 ftrace - function trace with cpumask # ok 47 ftrace - test for function event triggers # ok 48 ftrace - function glob filters # ok 49 ftrace - function pid notrace filters # ok 50 ftrace - function pid filters # ok 51 ftrace - stacktrace filter command Warnings: [ 2668.008907] watchdog: BUG: soft lockup - CPU#0 stuck for 2265s! [swapper/0:0] [ 2668.008954] Modules linked in: bonding(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) ip_set(E) rfkill(E) nf_tables(E) nfnetlink(E) mlx5_ib(E) ib_uverbs(E) ib_core(E) pseries_rng(E) vmx_crypto(E) dax_pmem(E) drm(E) drm_panel_orientation_quirks(E) xfs(E) sr_mod(E) cdrom(E) sd_mod(E) sg(E) lpfc(E) nd_pmem(E) nvmet_fc(E) nd_btt(E) ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) nvmet(E) nvme_fc(E) mlx5_core(E) nvme_fabrics(E) papr_scm(E) mlxfw(E) nvme_core(E) libnvdimm(E) tls(E) psample(E
Re: [PATCH 6/6] m68k/nommu: stop using GENERIC_IOMAP
On Mon, Mar 24, 2025, at 02:33, Greg Ungerer wrote:
> Hi Arnd,
>
> On 15/3/25 20:59, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> There is no need to go through the GENERIC_IOMAP wrapper for PIO on
>> nommu platforms, since these always come from PCI I/O space that is
>> itself memory mapped.
>>
>> Instead, the generic ioport_map() can just return the MMIO location
>> of the ports directly by applying the PCI_IO_PA offset, while
>> ioread32/iowrite32 trivially turn into readl/writel as they do
>> on most other architectures.
>>
>> Signed-off-by: Arnd Bergmann
>
> With this applied this fails to build for me:
>
>UPD include/generated/utsversion.h
>CC init/version-timestamp.o
>LD vmlinux
> m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
> `quirk_switchtec_ntb_dma_alias':
> quirks.c:(.text+0x23e4): undefined reference to `pci_iomap'
> m68k-linux-uclibc-ld: quirks.c:(.text+0x24fe): undefined reference to
> `pci_iounmap'
> m68k-linux-uclibc-ld: drivers/pci/quirks.o: in function
> `disable_igfx_irq':
> quirks.c:(.text+0x32f4): undefined reference to `pci_iomap'
> m68k-linux-uclibc-ld: quirks.c:(.text+0x3348): undefined reference to
> `pci_iounmap'
Thanks for the report, I was able to reproduce the problem now
and applied the fixup below. I had tested m5475evb_defconfig earlier,
and that built cleanly with PCI enabled, but I had missed how
that still used GENERIC_IOMAP because it has CONFIG_MMU enabled.
Does this fixup work for you?
On a related note, I'm curious about how the MCF54xx chips are
used in practice, as I see that they are the only coldfire chips
with PCI and they all have an MMU. Are there actual users of these
chips that have PCI but choose not to use the MMU?
Arnd
8<-
>From a36995e2a64711556c6773797367d165828f6705 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 24 Mar 2025 07:53:47 +0100
Subject: [PATCH] m68k: coldfire: select PCI_IOMAP for PCI
After I dropped CONFIG_GENERIC_IOMAP, some PCI drivers started failing
to link when CONFIG_MMU is disabled:
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/i740fb.ko] undefined!
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iomap_wc" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iomap" [drivers/video/fbdev/vt8623fb.ko] undefined!
ERROR: modpost: "pci_iounmap" [drivers/video/fbdev/s3fb.ko] undefined!
...
It turns out that there were two mistakes in my patch: on !MMU I forgot
to enable CONFIG_GENERIC_PCI_IOMAP, and for Coldfire with MMU enabled,
teh GENERIC_IOMAP was left in place but incorrectly configured.
Fixes: 9d48cc07d0d7 ("m68k/nommu: stop using GENERIC_IOMAP")
Reported-by: Greg Ungerer
Signed-off-by: Arnd Bergmann
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index b50c275fa94d..eb5bb6d36899 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -18,12 +18,13 @@ config M68K
select DMA_DIRECT_REMAP if M68K_NONCOHERENT_DMA && !COLDFIRE
select GENERIC_ATOMIC64
select GENERIC_CPU_DEVICES
- select GENERIC_IOMAP if HAS_IOPORT && MMU
+ select GENERIC_IOMAP if HAS_IOPORT && MMU && !COLDFIRE
select GENERIC_IRQ_SHOW
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_MULDI3
+ select GENERIC_PCI_IOMAP if PCI
select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
select HAVE_ARCH_LIBGCC_H
select HAVE_ARCH_SECCOMP
Re: [PATCH 02/11] mm: Call ctor/dtor for kernel PTEs
On 17/03/2025 15:16, Kevin Brodsky wrote:
> diff --git a/include/asm-generic/pgalloc.h b/include/asm-generic/pgalloc.h
> index e164ca66f0f6..3c8ec3bfea44 100644
> --- a/include/asm-generic/pgalloc.h
> +++ b/include/asm-generic/pgalloc.h
> @@ -23,6 +23,11 @@ static inline pte_t *__pte_alloc_one_kernel_noprof(struct
> mm_struct *mm)
>
> if (!ptdesc)
> return NULL;
> + if (!pagetable_pte_ctor(mm, ptdesc)) {
As reported by the CI [1], this can cause trouble on x86 because dtor
calls are missing in pud_free_pmd_page() and pmd_free_pte_page(). Will
fix in the next version.
- Kevin
[1] https://lore.kernel.org/oe-lkp/202503211612.e11bd73f-...@intel.com/
Re: [PATCH v5 0/6] kvm powerpc/book3s-hv: Expose Hostwide counters as perf-events
Tested on both KVM on LPAR and KVM for bare metal. For the series: Tested-by: Gautam Menghani
Re: [PATCH V2 0/9] Add support for configure and control of Hardware Trace Macro(HTM)
On 21/03/25 12:51 pm, Athira Rajeev wrote: H_HTM (Hardware Trace Macro) hypervisor call is an HCALL to export data from Hardware Trace Macro (HTM) function. The debugfs interface to export the HTM function data in a partition currently supports only dumping of HTM data in an lpar. Patchset add support for configuration and control of HTM function via debugfs interface. With the patchset, after loading htmdump module, below files are present: ls /sys/kernel/debug/powerpc/htmdump/ coreindexonchip htmcaps htmconfigure htmflags htminfo htmsetup htmstart htmstatus htmtype nodalchipindex nodeindex trace - nodeindex, nodalchipindex, coreindexonchip specifies which partition to configure the HTM for. - htmtype: specifies the type of HTM. Supported target is hardwareTarget. - trace: is to read the HTM data. - htmconfigure: Configure/Deconfigure the HTM. Writing 1 to the file will configure the trace, writing 0 to the file will do deconfigure. - htmstart: start/Stop the HTM. Writing 1 to the file will start the tracing, writing 0 to the file will stop the tracing. - htmstatus: get the status of HTM. This is needed to understand the HTM state after each operation. - htmsetup: set the HTM buffer size. Size of HTM buffer is in power of 2. - htminfo: provides the system processor configuration details. This is needed to understand the appropriate values for nodeindex, nodalchipindex, coreindexonchip. - htmcaps : provides the HTM capabilities like minimum/maximum buffer size, what kind of tracing the HTM supports etc. - htmflags : allows to pass flags to hcall. Currently supports controlling the wrapping of HTM buffer. Example usage: To collect HTM traces for a partition represented by nodeindex as zero, nodalchipindex as 1 and coreindexonchip as 12. # cd /sys/kernel/debug/powerpc/htmdump/ # echo 2 > htmtype # echo 0 > nodeindex # echo 1 > nodalchipindex # echo 12 > coreindexonchip # echo 1 > htmflags # to set noWrap for HTM buffers # echo 1 > htmconfigure # Configure the HTM # echo 1 > htmstart # Start the HTM # echo 0 > htmstart # Stop the HTM # echo 0 > htmconfigure # Deconfigure the HTM # cat htmstatus # Dump the status of HTM entries as data Changelog: V2: Venkat reported that patch 7 failed to apply on powerpc-next. Fixed that in V2. V2 pacth series applies cleanly on powerpc-next repo. Issue found with V1 is fixed. Athira Rajeev (9): powerpc/pseries/htmdump: Add htm_hcall_wrapper to integrate other htm operations powerpc/pseries/htmdump: Add htm configure support to htmdump module powerpc/pseries/htmdump: Add htm start support to htmdump module powerpc/pseries/htmdump: Add htm status support to htmdump module powerpc/pseries/htmdump: Add htm info support to htmdump module powerpc/pseries/htmdump: Add htm setup support to htmdump module powerpc/pseries/htmdump: Add htm flags support to htmdump module powerpc/pseries/htmdump: Add htm capabilities support to htmdump module powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface Documentation/arch/powerpc/htm.rst| 104 ++ arch/powerpc/include/asm/plpar_wrappers.h | 20 +- arch/powerpc/platforms/pseries/htmdump.c | 370 +- 3 files changed, 475 insertions(+), 19 deletions(-) create mode 100644 Documentation/arch/powerpc/htm.rst Applied the patches and verified all that functionalities are working as expected. Corss verified with the phyp data, and it matches. For the series please add below tag. Tested-by: Venkat Rao Bagalkote
[PATCH] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX
This option was removed from the Kconfig in commit
8c710f75256b ("net/sched: Retire tcindex classifier") but it was not
removed from the defconfigs.
Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier")
Signed-off-by: Johan Korsnes
Cc: Nicholas Piggin
Cc: Christophe Leroy
---
arch/powerpc/configs/ppc6xx_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/configs/ppc6xx_defconfig
b/arch/powerpc/configs/ppc6xx_defconfig
index ca0c90e95837..b8eb158a80fd 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -253,7 +253,6 @@ CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_CLS_BASIC=m
-CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
--
2.49.0
Re: [PATCH] arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX
Le 23/03/2025 à 20:11, Johan Korsnes a écrit :
[Vous ne recevez pas souvent de courriers de johan.kors...@gmail.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
This option was removed from the Kconfig in commit
8c710f75256b ("net/sched: Retire tcindex classifier") but it was not
removed from the defconfigs.
Fixes: 8c710f75256b ("net/sched: Retire tcindex classifier")
Signed-off-by: Johan Korsnes
Cc: Nicholas Piggin
Cc: Christophe Leroy
Reviewed-by: Christophe Leroy
---
arch/powerpc/configs/ppc6xx_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/configs/ppc6xx_defconfig
b/arch/powerpc/configs/ppc6xx_defconfig
index ca0c90e95837..b8eb158a80fd 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -253,7 +253,6 @@ CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_CLS_BASIC=m
-CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
--
2.49.0
Re: [PATCH v13 2/5] arm64: add support for ARCH_HAS_COPY_MC
On Fri, Feb 14, 2025 at 09:44:02AM +0800, Tong Tiangen wrote: > > > 在 2025/2/13 0:21, Catalin Marinas 写道: > > (catching up with old threads) > > > > On Mon, Dec 09, 2024 at 10:42:54AM +0800, Tong Tiangen wrote: > > > For the arm64 kernel, when it processes hardware memory errors for > > > synchronize notifications(do_sea()), if the errors is consumed within the > > > kernel, the current processing is panic. However, it is not optimal. > > > > > > Take copy_from/to_user for example, If ld* triggers a memory error, even > > > in > > > kernel mode, only the associated process is affected. Killing the user > > > process and isolating the corrupt page is a better choice. > > > > I agree that killing the user process and isolating the page is a better > > choice but I don't see how the latter happens after this patch. Which > > page would be isolated? > > The SEA is triggered when the page with hardware error is read. After > that, the page is isolated in memory_failure() (mf). The processing of > mf is mentioned in the comments of do_sea(). > > /* > * APEI claimed this as a firmware-first notification. > * Some processing deferred to task_work before ret_to_user(). > */ > > Some processing include mf. > > > > > > Add new fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR to identify insn > > > that can recover from memory errors triggered by access to kernel memory, > > > and this fixup type is used in __arch_copy_to_user(), This make the > > > regular > > > copy_to_user() will handle kernel memory errors. > > > > Is the assumption that the error on accessing kernel memory is > > transient? There's no way to isolate the kernel page and also no point > > in isolating the destination page either. > > Yes, it's transient, the kernel page in mf can't be isolated, the > transient access (ld) of this kernel page is currently expected to kill > the user-mode process to avoid error spread. > > > The SEA processes synchronization errors. Only hardware errors on the > source page can be detected (Through synchronous ld insn) and processed. > The destination page cannot be processed. I've considered the copy_to_user() case as only partially fixable. There are lots of cases to consider: 1) Many places where drivers copy to user in ioctl(2) calls. Killing the application solves the immediate problem, but if the problem with kernel memory is not transient, then you may run into it again. 2) Copy from Linux page cache to user for a read(2) system call. This one is a candidate for recovery. Might need help from the file system code. If the kernel page is a clean copy of data in the file system, then drop this page and re-read from storage into a new page. Then resume the copy_to_user(). If the page is modified, then need some file system action to somehow mark this range of addresses in the file as lost forever. First step in tackling this case is identifying that the source address is a page cache page. 3) Probably many other places where the kernel copies to user for other system calls. Would need to look at these on a case by case basis. Likely most have the same issue as ioctl(2) above. -Tony
