[PATCH v2] hwmon: (ibmpowernv) refactor deprecated strncpy
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. A suitable replacement is `memcpy` as we've already precisely calculated the number of bytes to copy while `buf` has been explicitly zero-initialized: | char buf[8] = { 0 }; Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-harden...@vger.kernel.org Signed-off-by: Justin Stitt --- Changes in v2: - prefer memcpy to strscpy (thanks Kees) - Link to v1: https://lore.kernel.org/r/20230914-strncpy-drivers-hwmon-ibmpowernv-c-v1-1-ba6b7f42c...@google.com --- drivers/hwmon/ibmpowernv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c index 594254d6a72d..70ca833259ab 100644 --- a/drivers/hwmon/ibmpowernv.c +++ b/drivers/hwmon/ibmpowernv.c @@ -234,7 +234,7 @@ static int get_sensor_index_attr(const char *name, u32 *index, char *attr) if (copy_len >= sizeof(buf)) return -EINVAL; - strncpy(buf, hash_pos + 1, copy_len); + memcpy(buf, hash_pos + 1, copy_len); err = kstrtou32(buf, 10, index); if (err) --- base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec change-id: 20230914-strncpy-drivers-hwmon-ibmpowernv-c-80a03f16d93a Best regards, -- Justin Stitt
[powerpc:next] BUILD SUCCESS ff25ad0aa280012eda5699713a9f0b468a1d6e4e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: ff25ad0aa280012eda5699713a9f0b468a1d6e4e powerpc/configs: Set more PPC debug configs elapsed time: 873m configs tested: 167 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc archsdk_defconfig gcc arc randconfig-001-20230918 gcc arc randconfig-001-20230919 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm assabet_defconfig gcc arm defconfig gcc arm footbridge_defconfig gcc arm randconfig-001-20230918 gcc arm randconfig-001-20230919 gcc arm stm32_defconfig gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20230919 gcc i386 buildonly-randconfig-002-20230919 gcc i386 buildonly-randconfig-003-20230919 gcc i386 buildonly-randconfig-004-20230919 gcc i386 buildonly-randconfig-005-20230919 gcc i386 buildonly-randconfig-006-20230919 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20230919 gcc i386 randconfig-002-20230919 gcc i386 randconfig-003-20230919 gcc i386 randconfig-004-20230919 gcc i386 randconfig-005-20230919 gcc i386 randconfig-006-20230919 gcc i386 randconfig-011-20230919 gcc i386 randconfig-012-20230919 gcc i386 randconfig-013-20230919 gcc i386 randconfig-014-20230919 gcc i386 randconfig-015-20230919 gcc i386 randconfig-016-20230919 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20230918 gcc loongarch randconfig-001-20230919 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68k amcore_defconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc openrisc virt_defconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc allyesconfig gcc powerpc
Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX
Geert Uytterhoeven writes: > Upstream Linux never had a "README.legal" file, but it was present > in early source releases of Linux/m68k. It contained a simple copyright > notice and a link to a version of the "COPYING" file that predated the > addition of the "only valid GPL version is v2" clause. > > Get rid of the references to non-existent files by replacing the > boilerplate with SPDX license identifiers. > > Signed-off-by: Geert Uytterhoeven LGTM. Acked-by: Michael Ellerman (powerpc) cheers
[powerpc:merge] BUILD SUCCESS 02e81f784e0b24ab2d6ec1b2dbf3e319187db74c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 02e81f784e0b24ab2d6ec1b2dbf3e319187db74c powerpc/ci: Usage Fedora 38 for all builds elapsed time: 743m configs tested: 151 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20230918 gcc arc randconfig-001-20230919 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm bcm2835_defconfig clang arm defconfig gcc arm omap1_defconfig clang arm randconfig-001-20230918 gcc arm stm32_defconfig gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20230919 gcc i386 buildonly-randconfig-002-20230919 gcc i386 buildonly-randconfig-003-20230919 gcc i386 buildonly-randconfig-004-20230919 gcc i386 buildonly-randconfig-005-20230919 gcc i386 buildonly-randconfig-006-20230919 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20230918 gcc i386 randconfig-002-20230918 gcc i386 randconfig-003-20230918 gcc i386 randconfig-004-20230918 gcc i386 randconfig-005-20230918 gcc i386 randconfig-006-20230918 gcc i386 randconfig-011-20230918 gcc i386 randconfig-012-20230918 gcc i386 randconfig-013-20230918 gcc i386 randconfig-014-20230918 gcc i386 randconfig-015-20230918 gcc i386 randconfig-016-20230918 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20230918 gcc loongarch randconfig-001-20230919 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips sb1250_swarm_defconfig clang nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc allyesconfig gcc powerpc linkstation_defconfig gcc powerpc lite5200b_defconfig clang powerpc ppc40x_defconfig gcc powerpc
[powerpc:fixes-test] BUILD SUCCESS c3f4309693758b13fbb34b3741c2e2801ad28769
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: c3f4309693758b13fbb34b3741c2e2801ad28769 powerpc/dexcr: Move HASHCHK trap handler elapsed time: 727m configs tested: 146 configs skipped: 161 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc archsdk_defconfig gcc arcnsim_700_defconfig gcc arc randconfig-001-20230919 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm assabet_defconfig gcc armclps711x_defconfig gcc arm defconfig gcc arm exynos_defconfig gcc arm footbridge_defconfig gcc arm randconfig-001-20230919 gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc i386 buildonly-randconfig-001-20230919 gcc i386 buildonly-randconfig-002-20230919 gcc i386 buildonly-randconfig-003-20230919 gcc i386 buildonly-randconfig-004-20230919 gcc i386 buildonly-randconfig-005-20230919 gcc i386 buildonly-randconfig-006-20230919 gcc i386 randconfig-001-20230919 gcc i386 randconfig-002-20230919 gcc i386 randconfig-003-20230919 gcc i386 randconfig-004-20230919 gcc i386 randconfig-005-20230919 gcc i386 randconfig-006-20230919 gcc i386 randconfig-011-20230919 gcc i386 randconfig-012-20230919 gcc i386 randconfig-013-20230919 gcc i386 randconfig-014-20230919 gcc i386 randconfig-015-20230919 gcc i386 randconfig-016-20230919 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20230919 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc allyesconfig gcc powerpc bamboo_defconfig gcc powerpc mpc834x_itx_defconfig gcc riscvallmodconfig gcc riscv allnoconfig gcc riscvallyesconfig gcc riscv defconfig gcc riscv randconfig-001-20230919 gcc riscv rv32_defconfig gcc s390
Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
On Monday, September 18th, 2023 at 19:41, Segher Boessenkool wrote: > On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote: > > > ReiserFS has been considered deprecated for 19 months since commit > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > > several architectures that still build it into their defconfig kernels. > > > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > > from defconfig files before the filesystem's removal. > > > This is essentially equivalent to deleting the filesystem now. Why do > this? Is there such a hurry? This is not equivalent to deleting the filesystem. The filesystem can still be configured into kernels, and few distros use a defconfig kernel anyway. > > > Segher Cheers, Peter Lafreniere
Re: [RFC PATCH v12 10/33] KVM: Set the stage for handling only shared mappings in mmu_notifier events
On Mon, Sep 18, 2023, Michael Roth wrote: > On Wed, Sep 13, 2023 at 06:55:08PM -0700, Sean Christopherson wrote: > > Add flags to "struct kvm_gfn_range" to let notifier events target only > > shared and only private mappings, and write up the existing mmu_notifier > > events to be shared-only (private memory is never associated with a > > userspace virtual address, i.e. can't be reached via mmu_notifiers). > > > > Add two flags so that KVM can handle the three possibilities (shared, > > private, and shared+private) without needing something like a tri-state > > enum. > > > > Link: https://lore.kernel.org/all/zjx0hk+kpqp0k...@google.com > > Signed-off-by: Sean Christopherson > > --- > > include/linux/kvm_host.h | 2 ++ > > virt/kvm/kvm_main.c | 7 +++ > > 2 files changed, 9 insertions(+) > > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index d8c6ce6c8211..b5373cee2b08 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -263,6 +263,8 @@ struct kvm_gfn_range { > > gfn_t start; > > gfn_t end; > > union kvm_mmu_notifier_arg arg; > > + bool only_private; > > + bool only_shared; > > bool may_block; > > }; > > bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range); > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 174de2789657..a41f8658dfe0 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -635,6 +635,13 @@ static __always_inline kvm_mn_ret_t > > __kvm_handle_hva_range(struct kvm *kvm, > > * the second or later invocation of the handler). > > */ > > gfn_range.arg = range->arg; > > + > > + /* > > +* HVA-based notifications aren't relevant to private > > +* mappings as they don't have a userspace mapping. > > +*/ > > + gfn_range.only_private = false; > > + gfn_range.only_shared = true; > > gfn_range.may_block = range->may_block; > > Who is supposed to read only_private/only_shared? Is it supposed to be > plumbed onto arch code and handled specially there? Yeah, that's the idea. Though I don't know that it's worth using for SNP, the cost of checking the RMP may be higher than just eating the extra faults. > I ask because I see elsewhere you have: > > /* > * If one or more memslots were found and thus zapped, notify arch code > * that guest memory has been reclaimed. This needs to be done *after* > * dropping mmu_lock, as x86's reclaim path is slow. > */ > if (__kvm_handle_hva_range(kvm, _range).found_memslot) > kvm_arch_guest_memory_reclaimed(kvm); > > and if there are any MMU notifier events that touch HVAs, then > kvm_arch_guest_memory_reclaimed()->wbinvd_on_all_cpus() will get called, > which causes the performance issues for SEV and SNP that Ashish had brought > up. Technically that would only need to happen if there are GPAs in that > memslot that aren't currently backed by gmem pages (and then gmem could handle > its own wbinvd_on_all_cpus() (or maybe clflush per-page)). > > Actually, even if there are shared pages in the GPA range, the > kvm_arch_guest_memory_reclaimed()->wbinvd_on_all_cpus() can be skipped for > guests that only use gmem pages for private memory. Is that acceptable? Yes, that was my original plan. I may have forgotten that exact plan at one point or another and not communicated it well. But the idea is definitely that if a VM type, a.k.a. SNP guests, is required to use gmem for private memory, then there's no need to blast WBINVD because barring a KVM bug, the mmu_notifier event can't have freed private memory, even if it *did* zap SPTEs. For gmem, if KVM doesn't precisely zap only shared SPTEs for SNP (is that even possible to do race-free?), then KVM needs to blast WBINVD when freeing memory from gmem even if there are no SPTEs. But that seems like a non-issue for a well-behaved setup because the odds of there being *zero* SPTEs should be nil. > Just trying to figure out where this only_private/only_shared handling ties > into that (or if it's a separate thing entirely). It's mostly a TDX thing. I threw it in this series mostly to "formally" document that the mmu_notifier path only affects shared mappings. If the code causes confusion without the TDX context, and won't be used by SNP, we can and should drop it from the initial merge and have it go along with the TDX series.
Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote: > ReiserFS has been considered deprecated for 19 months since commit > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > several architectures that still build it into their defconfig kernels. > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > from defconfig files before the filesystem's removal. This is essentially equivalent to deleting the filesystem now. Why do this? Is there such a hurry? Segher
Re: [RFC PATCH v12 10/33] KVM: Set the stage for handling only shared mappings in mmu_notifier events
On Wed, Sep 13, 2023 at 06:55:08PM -0700, Sean Christopherson wrote: > Add flags to "struct kvm_gfn_range" to let notifier events target only > shared and only private mappings, and write up the existing mmu_notifier > events to be shared-only (private memory is never associated with a > userspace virtual address, i.e. can't be reached via mmu_notifiers). > > Add two flags so that KVM can handle the three possibilities (shared, > private, and shared+private) without needing something like a tri-state > enum. > > Link: https://lore.kernel.org/all/zjx0hk+kpqp0k...@google.com > Signed-off-by: Sean Christopherson > --- > include/linux/kvm_host.h | 2 ++ > virt/kvm/kvm_main.c | 7 +++ > 2 files changed, 9 insertions(+) > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index d8c6ce6c8211..b5373cee2b08 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -263,6 +263,8 @@ struct kvm_gfn_range { > gfn_t start; > gfn_t end; > union kvm_mmu_notifier_arg arg; > + bool only_private; > + bool only_shared; > bool may_block; > }; > bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range); > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 174de2789657..a41f8658dfe0 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -635,6 +635,13 @@ static __always_inline kvm_mn_ret_t > __kvm_handle_hva_range(struct kvm *kvm, >* the second or later invocation of the handler). >*/ > gfn_range.arg = range->arg; > + > + /* > + * HVA-based notifications aren't relevant to private > + * mappings as they don't have a userspace mapping. > + */ > + gfn_range.only_private = false; > + gfn_range.only_shared = true; > gfn_range.may_block = range->may_block; Who is supposed to read only_private/only_shared? Is it supposed to be plumbed onto arch code and handled specially there? I ask because I see elsewhere you have: /* * If one or more memslots were found and thus zapped, notify arch code * that guest memory has been reclaimed. This needs to be done *after* * dropping mmu_lock, as x86's reclaim path is slow. */ if (__kvm_handle_hva_range(kvm, _range).found_memslot) kvm_arch_guest_memory_reclaimed(kvm); and if there are any MMU notifier events that touch HVAs, then kvm_arch_guest_memory_reclaimed()->wbinvd_on_all_cpus() will get called, which causes the performance issues for SEV and SNP that Ashish had brought up. Technically that would only need to happen if there are GPAs in that memslot that aren't currently backed by gmem pages (and then gmem could handle its own wbinvd_on_all_cpus() (or maybe clflush per-page)). Actually, even if there are shared pages in the GPA range, the kvm_arch_guest_memory_reclaimed()->wbinvd_on_all_cpus() can be skipped for guests that only use gmem pages for private memory. Is that acceptable? Just trying to figure out where this only_private/only_shared handling ties into that (or if it's a separate thing entirely). -Mike > > /* > -- > 2.42.0.283.g2d96d420d3-goog >
[PATCH 2/7] arch: powerpc: remove ReiserFS from defconfig
ReiserFS has been deprecated for a year and a half, yet is still built as part of a defconfig kernel. According to commit eb103a51640e ("reiserfs: Deprecate reiserfs"), the filesystem is slated to be removed in 2025. Remove it from the defconfig profiles now, as part of its deprecation process. Signed-off-by: Peter Lafreniere --- arch/powerpc/configs/44x/sam440ep_defconfig | 1 - arch/powerpc/configs/g5_defconfig | 4 arch/powerpc/configs/ppc64e_defconfig | 4 arch/powerpc/configs/ppc6xx_defconfig | 5 - 4 files changed, 14 deletions(-) diff --git a/arch/powerpc/configs/44x/sam440ep_defconfig b/arch/powerpc/configs/44x/sam440ep_defconfig index 51499ee6366b..2479ab62d12f 100644 --- a/arch/powerpc/configs/44x/sam440ep_defconfig +++ b/arch/powerpc/configs/44x/sam440ep_defconfig @@ -78,7 +78,6 @@ CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y -CONFIG_REISERFS_FS=y CONFIG_AUTOFS_FS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 71d9d112c0b6..9215bed53291 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -202,10 +202,6 @@ CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y -CONFIG_REISERFS_FS=y -CONFIG_REISERFS_FS_XATTR=y -CONFIG_REISERFS_FS_POSIX_ACL=y -CONFIG_REISERFS_FS_SECURITY=y CONFIG_XFS_FS=m CONFIG_XFS_POSIX_ACL=y CONFIG_FS_DAX=y diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig index 624c371ffcc3..4c05f4e4d505 100644 --- a/arch/powerpc/configs/ppc64e_defconfig +++ b/arch/powerpc/configs/ppc64e_defconfig @@ -175,10 +175,6 @@ CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y -CONFIG_REISERFS_FS=y -CONFIG_REISERFS_FS_XATTR=y -CONFIG_REISERFS_FS_POSIX_ACL=y -CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=y CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig index eaf3273372a9..f279703425d4 100644 --- a/arch/powerpc/configs/ppc6xx_defconfig +++ b/arch/powerpc/configs/ppc6xx_defconfig @@ -954,11 +954,6 @@ CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_JBD2_DEBUG=y -CONFIG_REISERFS_FS=m -CONFIG_REISERFS_PROC_INFO=y -CONFIG_REISERFS_FS_XATTR=y -CONFIG_REISERFS_FS_POSIX_ACL=y -CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y -- 2.42.0
[PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
ReiserFS has been considered deprecated for 19 months since commit eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are several architectures that still build it into their defconfig kernels. As ReiserFS will be removed in 2025, delete all ReiserFS-related options from defconfig files before the filesystem's removal. The series is intended to be approved/rejected on an arch-by-arch basis. No patch is dependant upon another in the series. See discussion originating in, Link: https://lore.kernel.org/linux-um/20230918125744.4342-1-pe...@n8pjl.ca/ Peter Lafreniere (7): arch: um: remove ReiserFS from defconfig arch: powerpc: remove ReiserFS from defconfig arch: sh: remove ReiserFS from defconfig arch: mips: remove ReiserFS from defconfig arch: m68k: remove ReiserFS from defconfig arch: arm: remove ReiserFS from defconfig arch: alpha: remove ReiserFS from defconfig arch/alpha/configs/defconfig| 1 - arch/arm/configs/pxa_defconfig | 4 arch/m68k/configs/amiga_defconfig | 1 - arch/m68k/configs/apollo_defconfig | 1 - arch/m68k/configs/atari_defconfig | 1 - arch/m68k/configs/bvme6000_defconfig| 1 - arch/m68k/configs/hp300_defconfig | 1 - arch/m68k/configs/mac_defconfig | 1 - arch/m68k/configs/multi_defconfig | 1 - arch/m68k/configs/mvme147_defconfig | 1 - arch/m68k/configs/mvme16x_defconfig | 1 - arch/m68k/configs/q40_defconfig | 1 - arch/m68k/configs/sun3_defconfig| 1 - arch/m68k/configs/sun3x_defconfig | 1 - arch/mips/configs/fuloong2e_defconfig | 1 - arch/mips/configs/jazz_defconfig| 4 arch/mips/configs/lemote2f_defconfig| 3 --- arch/mips/configs/malta_defconfig | 5 - arch/mips/configs/malta_kvm_defconfig | 5 - arch/mips/configs/maltaup_xpa_defconfig | 5 - arch/mips/configs/rm200_defconfig | 4 arch/powerpc/configs/44x/sam440ep_defconfig | 1 - arch/powerpc/configs/g5_defconfig | 4 arch/powerpc/configs/ppc64e_defconfig | 4 arch/powerpc/configs/ppc6xx_defconfig | 5 - arch/sh/configs/landisk_defconfig | 1 - arch/sh/configs/titan_defconfig | 1 - arch/um/configs/i386_defconfig | 1 - arch/um/configs/x86_64_defconfig| 1 - 29 files changed, 62 deletions(-) -- 2.42.0
Re: [RFC PATCH v12 14/33] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
On Wed, Sep 13, 2023 at 06:55:12PM -0700, Sean Christopherson wrote: > TODO > > Cc: Fuad Tabba > Cc: Vishal Annapurve > Cc: Ackerley Tng > Cc: Jarkko Sakkinen > Cc: Maciej Szmigiero > Cc: Vlastimil Babka > Cc: David Hildenbrand > Cc: Quentin Perret > Cc: Michael Roth > Cc: Wang > Cc: Liam Merwick > Cc: Isaku Yamahata > Co-developed-by: Kirill A. Shutemov > Signed-off-by: Kirill A. Shutemov > Co-developed-by: Yu Zhang > Signed-off-by: Yu Zhang > Co-developed-by: Chao Peng > Signed-off-by: Chao Peng > Co-developed-by: Ackerley Tng > Signed-off-by: Ackerley Tng > Co-developed-by: Isaku Yamahata > Signed-off-by: Isaku Yamahata > Signed-off-by: Sean Christopherson > --- > include/linux/kvm_host.h | 48 +++ > include/uapi/linux/kvm.h | 15 +- > include/uapi/linux/magic.h | 1 + > virt/kvm/Kconfig | 4 + > virt/kvm/Makefile.kvm | 1 + > virt/kvm/guest_mem.c | 593 + > virt/kvm/kvm_main.c| 61 +++- > virt/kvm/kvm_mm.h | 38 +++ > 8 files changed, 756 insertions(+), 5 deletions(-) > create mode 100644 virt/kvm/guest_mem.c > > +static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t > len) > +{ > + struct list_head *gmem_list = >i_mapping->private_list; > + pgoff_t start = offset >> PAGE_SHIFT; > + pgoff_t end = (offset + len) >> PAGE_SHIFT; > + struct kvm_gmem *gmem; > + > + /* > + * Bindings must stable across invalidation to ensure the start+end > + * are balanced. > + */ > + filemap_invalidate_lock(inode->i_mapping); > + > + list_for_each_entry(gmem, gmem_list, entry) { > + kvm_gmem_invalidate_begin(gmem, start, end); In v11 we used to call truncate_inode_pages_range() here to drop filemap's reference on the folio. AFAICT the folios are only getting free'd upon guest shutdown without this. Was this on purpose? > + kvm_gmem_invalidate_end(gmem, start, end); > + } > + > + filemap_invalidate_unlock(inode->i_mapping); > + > + return 0; > +} > + > +static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len) > +{ > + struct address_space *mapping = inode->i_mapping; > + pgoff_t start, index, end; > + int r; > + > + /* Dedicated guest is immutable by default. */ > + if (offset + len > i_size_read(inode)) > + return -EINVAL; > + > + filemap_invalidate_lock_shared(mapping); We take the filemap lock here, but not for kvm_gmem_get_pfn()->kvm_gmem_get_folio(). Is it needed there as well? > + > + start = offset >> PAGE_SHIFT; > + end = (offset + len) >> PAGE_SHIFT; > + > + r = 0; > + for (index = start; index < end; ) { > + struct folio *folio; > + > + if (signal_pending(current)) { > + r = -EINTR; > + break; > + } > + > + folio = kvm_gmem_get_folio(inode, index); > + if (!folio) { > + r = -ENOMEM; > + break; > + } > + > + index = folio_next_index(folio); > + > + folio_unlock(folio); > + folio_put(folio); > + > + /* 64-bit only, wrapping the index should be impossible. */ > + if (WARN_ON_ONCE(!index)) > + break; > + > + cond_resched(); > + } > + > + filemap_invalidate_unlock_shared(mapping); > + > + return r; > +} > + > +static int __kvm_gmem_create(struct kvm *kvm, loff_t size, struct vfsmount > *mnt) > +{ > + const char *anon_name = "[kvm-gmem]"; > + const struct qstr qname = QSTR_INIT(anon_name, strlen(anon_name)); > + struct kvm_gmem *gmem; > + struct inode *inode; > + struct file *file; > + int fd, err; > + > + inode = alloc_anon_inode(mnt->mnt_sb); > + if (IS_ERR(inode)) > + return PTR_ERR(inode); > + > + err = security_inode_init_security_anon(inode, , NULL); > + if (err) > + goto err_inode; > + > + inode->i_private = (void *)(unsigned long)flags; The 'flags' argument isn't added until the subsequent patch that adds THP support. > +static bool kvm_gmem_is_valid_size(loff_t size, u64 flags) > +{ > + if (size < 0 || !PAGE_ALIGNED(size)) > + return false; > + > + return true; > +} > + > +int kvm_gmem_create(struct kvm *kvm, struct kvm_create_guest_memfd *args) > +{ > + loff_t size = args->size; > + u64 flags = args->flags; > + u64 valid_flags = 0; > + > + if (flags & ~valid_flags) > + return -EINVAL; > + > + if (!kvm_gmem_is_valid_size(size, flags)) > + return -EINVAL; > + > + return __kvm_gmem_create(kvm, size, flags, kvm_gmem_mnt); > +} > + > +int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot, > + unsigned int fd, loff_t offset) > +{ > + loff_t size = slot->npages << PAGE_SHIFT; > + unsigned long start,
linux-next: added the kvm-ppc tree
Hi all, I have added the kvm-ppc tree today from https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git branch topic/ppc-kvm Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgpzIwJTAnsCi.pgp Description: OpenPGP digital signature
Re: [PATCHv3 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO
On Mon, Sep 18, 2023 at 07:42:30PM +0800, Xi Ruoyao wrote: > ... > My workstation suffers from too much correctable AER reporting as well > (related to Intel's errata "RPL013: Incorrectly Formed PCIe Packets May > Generate Correctable Errors" and/or the motherboard design, I guess). We should rate-limit correctable error reporting so it's not overwhelming. At the same time, I'm *also* interested in the cause of these errors, in case there's a Linux defect or a hardware erratum that we can work around. Do you have a bug report with any more details, e.g., a dmesg log and "sudo lspci -vv" output? Bjorn
Re: [PATCHv3 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO
On Mon, Sep 18, 2023 at 4:42 AM Xi Ruoyao wrote: > > On Mon, 2023-08-14 at 08:40 -0700, Grant Grundler wrote: > > On Sat, Aug 12, 2023 at 5:45 PM David Heidelberg > > wrote: > > > > > > Tested-by: David Heidelberg > > > > Thanks David! > > > > > For PATCH v4 please fix the typo reported by the bot :) > > > > Sorry - I'll do that today. > > Hi Grant, > > Is there an update of this series? Sorry, while I had good intentions, my work has completely derailed my attempts to make time for this. :( I'll give this another run. I'm also not offended if someone else picks this up and improves the situation. cheers, grant > > My workstation suffers from too much correctable AER reporting as well > (related to Intel's errata "RPL013: Incorrectly Formed PCIe Packets May > Generate Correctable Errors" and/or the motherboard design, I guess). > > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Mon, Sep 18, 2023 at 08:52:40AM -0700, Sean Christopherson wrote: > > I wonder if we should be making the VFIO drivers that need the kvm to > > ask for it? 'select CONFIG_NEED_VFIO_KVM' or something? > > I wondered the same thing, if only to make it easier to track which > drivers actually end up interacting directly with KVM. There are two usages I've seen.. GVT's uage is just totally broken: https://lore.kernel.org/kvm/661447fd-b041-c08d-cedc-341b31c40...@intel.com/ It is trying to use KVM to write protect IOVA DMA memory, and it just doesn't work. If we want to do something like this the core vfio code should provide this service and it should be wired into KVM properly. power and s390 have actual architectural "virtual machines" and they need actual arch operations to install VFIO devices into those things. In this regard having the arch opt into the integration would make some sense. I expect this will get worse in our CC future where VFIO devices will need to be passed into arch specific CC code somehow. This arch stuff isn't cleanly done, the code is sprinkled all over the place. Some in mdevs, some in PCI arch code, some in #ifdefs.. Maybe the CC people will clean it up instead of making the mess bigger :) Jason
Re: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO, don't do circular lookup
On Mon, Sep 18, 2023 at 08:49:57AM -0700, Sean Christopherson wrote: > On Mon, Sep 18, 2023, Jason Gunthorpe wrote: > > On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote: > > > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to > > > VFIO instead of having VFIO do a symbol lookup back into KVM. Having both > > > KVM and VFIO do symbol lookups increases the overall complexity and places > > > an unnecessary dependency on KVM (from VFIO) without adding any value. > > > > > > Signed-off-by: Sean Christopherson > > > --- > > > drivers/vfio/vfio.h | 2 ++ > > > drivers/vfio/vfio_main.c | 74 +++- > > > include/linux/vfio.h | 4 ++- > > > virt/kvm/vfio.c | 9 +++-- > > > 4 files changed, 47 insertions(+), 42 deletions(-) > > > > I don't mind this, but Christoph had disliked my prior attempt to do > > this with function pointers.. > > > > The get can be inlined, IIRC, what about putting a pointer to the put > > inside the kvm struct? > > That wouldn't allow us to achieve our goal, which is to hide the details of > "struct kvm" from VFIO (and the rest of the kernel). > What's the objection to handing VFIO a function pointer? Hmm, looks like it was this thread: https://lore.kernel.org/r/0-v1-33906a626da1+16b0-vfio_kvm_no_group_...@nvidia.com Your rational looks a little better to me. > > The the normal kvm get/put don't have to exported symbols at all? > > The export of kvm_get_kvm_safe() can go away (I forgot to do that in this > series), > but kvm_get_kvm() will hang around as it's needed by KVM sub-modules (PPC and > x86), > KVMGT (x86), and drivers/s390/crypto/vfio_ap_ops.c (no idea what to call that > beast). My thought would be to keep it as an inline, there should be some way to do that without breaking your desire to hide the bulk of the kvm struct content. Like put the refcount as the first element in the struct and just don't ifdef it away?. Jason
Re: [RFC PATCH v12 10/33] KVM: Set the stage for handling only shared mappings in mmu_notifier events
On Mon, Sep 18, 2023, Binbin Wu wrote: > > > On 9/14/2023 9:55 AM, Sean Christopherson wrote: > > Add flags to "struct kvm_gfn_range" to let notifier events target only > > shared and only private mappings, and write up the existing mmu_notifier > > events to be shared-only (private memory is never associated with a > > userspace virtual address, i.e. can't be reached via mmu_notifiers). > > > > Add two flags so that KVM can handle the three possibilities (shared, > > private, and shared+private) without needing something like a tri-state > > enum. > > How to understand the word "stage" in short log? Sorry, it's an idiom[*] that essentially means "to prepare for". I'll rephrase the shortlog to be more straightforward (I have a bad habit of using idioms). [*] https://dictionary.cambridge.org/us/dictionary/english/set-the-stage-for
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Mon, Sep 18, 2023, Jason Gunthorpe wrote: > On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote: > > Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if > > and only if VFIO itself is enabled. Similar to the recent change to have > > VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO > > just because the architecture supports VFIO is nonsensical. > > > > This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently > > fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The > > bug is benign as the only driver in all of Linux that actually uses the > > KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific. > > Hmm, I recall that all the S390 drivers need it as well. > > static int vfio_ap_mdev_open_device(struct vfio_device *vdev) > { > struct ap_matrix_mdev *matrix_mdev = > container_of(vdev, struct ap_matrix_mdev, vdev); > > if (!vdev->kvm) > return -EINVAL; > > return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm); Ah, I missed that the KVM reference was routed through VFIO in that case. > I wonder if we should be making the VFIO drivers that need the kvm to > ask for it? 'select CONFIG_NEED_VFIO_KVM' or something? I wondered the same thing, if only to make it easier to track which drivers actually end up interacting directly with KVM. > Regardless, I fully agree with getting rid of the arch flag. > > Reviewed-by: Jason Gunthorpe > > > --- a/virt/kvm/Makefile.kvm > > +++ b/virt/kvm/Makefile.kvm > > @@ -6,7 +6,9 @@ > > KVM ?= ../../../virt/kvm > > > > kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o > > -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o > > +ifdef CONFIG_VFIO > > +kvm-y += $(KVM)/vfio.o > > +endif > > I wonder if kvm-m magically works in kbuild so you don't need the ifdef? Yeah, that should work, no idea why I added the ifdef.
Re: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO, don't do circular lookup
On Mon, Sep 18, 2023, Jason Gunthorpe wrote: > On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote: > > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to > > VFIO instead of having VFIO do a symbol lookup back into KVM. Having both > > KVM and VFIO do symbol lookups increases the overall complexity and places > > an unnecessary dependency on KVM (from VFIO) without adding any value. > > > > Signed-off-by: Sean Christopherson > > --- > > drivers/vfio/vfio.h | 2 ++ > > drivers/vfio/vfio_main.c | 74 +++- > > include/linux/vfio.h | 4 ++- > > virt/kvm/vfio.c | 9 +++-- > > 4 files changed, 47 insertions(+), 42 deletions(-) > > I don't mind this, but Christoph had disliked my prior attempt to do > this with function pointers.. > > The get can be inlined, IIRC, what about putting a pointer to the put > inside the kvm struct? That wouldn't allow us to achieve our goal, which is to hide the details of "struct kvm" from VFIO (and the rest of the kernel). What's the objection to handing VFIO a function pointer? > The the normal kvm get/put don't have to exported symbols at all? The export of kvm_get_kvm_safe() can go away (I forgot to do that in this series), but kvm_get_kvm() will hang around as it's needed by KVM sub-modules (PPC and x86), KVMGT (x86), and drivers/s390/crypto/vfio_ap_ops.c (no idea what to call that beast). Gah, KVMGT doesn't actually need to call get/put, that can be handled by kvm_page_track_register_notifier(). I am planning on making exports for sub-modules conditional on there actually being submodules, so that's 2 of the 3 gone, but tackling the s390 crypto driver is an entirely different story.
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote: > Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if > and only if VFIO itself is enabled. Similar to the recent change to have > VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO > just because the architecture supports VFIO is nonsensical. > > This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently > fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The > bug is benign as the only driver in all of Linux that actually uses the > KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific. Hmm, I recall that all the S390 drivers need it as well. static int vfio_ap_mdev_open_device(struct vfio_device *vdev) { struct ap_matrix_mdev *matrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev); if (!vdev->kvm) return -EINVAL; return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm); I wonder if we should be making the VFIO drivers that need the kvm to ask for it? 'select CONFIG_NEED_VFIO_KVM' or something? Regardless, I fully agree with getting rid of the arch flag. Reviewed-by: Jason Gunthorpe > --- a/virt/kvm/Makefile.kvm > +++ b/virt/kvm/Makefile.kvm > @@ -6,7 +6,9 @@ > KVM ?= ../../../virt/kvm > > kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o > -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o > +ifdef CONFIG_VFIO > +kvm-y += $(KVM)/vfio.o > +endif I wonder if kvm-m magically works in kbuild so you don't need the ifdef? Jason
Re: [PATCH 05/26] vfio: KVM: Pass get/put helpers from KVM to VFIO, don't do circular lookup
On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote: > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to > VFIO instead of having VFIO do a symbol lookup back into KVM. Having both > KVM and VFIO do symbol lookups increases the overall complexity and places > an unnecessary dependency on KVM (from VFIO) without adding any value. > > Signed-off-by: Sean Christopherson > --- > drivers/vfio/vfio.h | 2 ++ > drivers/vfio/vfio_main.c | 74 +++- > include/linux/vfio.h | 4 ++- > virt/kvm/vfio.c | 9 +++-- > 4 files changed, 47 insertions(+), 42 deletions(-) I don't mind this, but Christoph had disliked my prior attempt to do this with function pointers.. The get can be inlined, IIRC, what about putting a pointer to the put inside the kvm struct? The the normal kvm get/put don't have to exported symbols at all? Jason
Re: [PATCH 03/26] virt: Declare and define vfio_file_set_kvm() iff CONFIG_KVM is enabled
On Fri, Sep 15, 2023 at 05:30:55PM -0700, Sean Christopherson wrote: > Hide vfio_file_set_kvm() and its unique helpers if KVM is not enabled, > nothing else in the kernel (or out of the kernel) should be using a > KVM specific helper. > > Signed-off-by: Sean Christopherson > --- > drivers/vfio/vfio_main.c | 2 +- > include/linux/vfio.h | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) Patch subject should be vfio not virt Reviewed-by: Jason Gunthorpe > @@ -1388,6 +1387,7 @@ void vfio_file_set_kvm(struct file *file, struct kvm > *kvm) > vfio_device_file_set_kvm(file, kvm); > } > EXPORT_SYMBOL_GPL(vfio_file_set_kvm); > +#endif We could even put this in a symbol namespace.. Jason
Re: [PATCH 02/26] vfio: Move KVM get/put helpers to colocate it with other KVM related code
On Fri, Sep 15, 2023 at 05:30:54PM -0700, Sean Christopherson wrote: > Move the definitions of vfio_device_get_kvm_safe() and vfio_device_put_kvm() > down in vfio_main.c to colocate them with other KVM-specific functions, > e.g. to allow wrapping them all with a single CONFIG_KVM check. > > Signed-off-by: Sean Christopherson > --- > drivers/vfio/vfio_main.c | 104 +++ > 1 file changed, 52 insertions(+), 52 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [PATCH 01/26] vfio: Wrap KVM helpers with CONFIG_KVM instead of CONFIG_HAVE_KVM
On Fri, Sep 15, 2023 at 05:30:53PM -0700, Sean Christopherson wrote: > Wrap the helpers for getting references to KVM instances with a check on > CONFIG_KVM being enabled, not on CONFIG_HAVE_KVM being defined. PPC does > NOT select HAVE_KVM, despite obviously supporting KVM, and guarding code > to get references to KVM based on whether or not the architecture supports > KVM is nonsensical. > > Drop the guard around linux/kvm_host.h entirely, conditionally including a > generic headers is completely unnecessary. > > Signed-off-by: Sean Christopherson > --- > drivers/vfio/vfio.h | 2 +- > drivers/vfio/vfio_main.c | 4 +--- > 2 files changed, 2 insertions(+), 4 deletions(-) Reviewed-by: Jason Gunthorpe Jason
[PATCH v3 3/3] doc: trusted-encrypted: add DCP as new trust source
Update the documentation for trusted and encrypted KEYS with DCP as new trust source: - Describe security properties of DCP trust source - Describe key usage - Document blob format Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir --- .../security/keys/trusted-encrypted.rst | 85 +++ 1 file changed, 85 insertions(+) diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 9bc9db8ec651..4452070afbe9 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -42,6 +42,14 @@ safe. randomly generated and fused into each SoC at manufacturing time. Otherwise, a common fixed test key is used instead. + (4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + Rooted to a one-time programmable key (OTP) that is generally burnt + in the on-chip fuses and is accessible to the DCP encryption engine only. + DCP provides two keys that can be used as root of trust: the OTP key + and the UNIQUE key. Default is to use the UNIQUE key, but selecting + the OTP key can be done via a module parameter (dcp_use_otp_key). + * Execution isolation (1) TPM @@ -57,6 +65,12 @@ safe. Fixed set of operations running in isolated execution environment. + (4) DCP + + Fixed set of cryptographic operations running in isolated execution + environment. Only basic blob key encryption is executed there. + The actual key sealing/unsealing is done on main processor/kernel space. + * Optional binding to platform integrity state (1) TPM @@ -79,6 +93,11 @@ safe. Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs for platform integrity. + (4) DCP + + Relies on Secure/Trusted boot process (called HAB by vendor) for + platform integrity. + * Interfaces and APIs (1) TPM @@ -94,6 +113,11 @@ safe. Interface is specific to silicon vendor. + (4) DCP + + Vendor-specific API that is implemented as part of the DCP crypto driver in + ``drivers/crypto/mxs-dcp.c``. + * Threat model The strength and appropriateness of a particular trust source for a given @@ -129,6 +153,13 @@ selected trust source: CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device is probed. + * DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs) + + The DCP hardware device itself does not provide a dedicated RNG interface, + so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have + a dedicated hardware RNG that is independent from DCP which can be enabled + to back the kernel RNG. + Users may override this by specifying ``trusted.rng=kernel`` on the kernel command-line to override the used RNG with the kernel's random number pool. @@ -231,6 +262,19 @@ Usage:: CAAM-specific format. The key length for new keys is always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). +Trusted Keys usage: DCP +--- + +Usage:: + +keyctl add trusted name "new keylen" ring +keyctl add trusted name "load hex_blob" ring +keyctl print keyid + +"keyctl print" returns an ASCII hex copy of the sealed key, which is in format +specific to this DCP key-blob implementation. The key length for new keys is +always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits). + Encrypted Keys usage @@ -426,3 +470,44 @@ string length. privkey is the binary representation of TPM2B_PUBLIC excluding the initial TPM2B header which can be reconstructed from the ASN.1 octed string length. + +DCP Blob Format +--- + +The Data Co-Processor (DCP) provides hardware-bound AES keys using its +AES encryption engine only. It does not provide direct key sealing/unsealing. +To make DCP hardware encryption keys usable as trust source, we define +our own custom format that uses a hardware-bound key to secure the sealing +key stored in the key blob. + +Whenever a new trusted key using DCP is generated, we generate a random 128-bit +blob encryption key (BEK) and 128-bit nonce. The BEK and nonce are used to +encrypt the trusted key payload using AES-128-GCM. + +The BEK itself is encrypted using the hardware-bound key using the DCP's AES +encryption engine with AES-128-ECB. The encrypted BEK, generated nonce, +BEK-encrypted payload and authentication tag make up the blob format together +with a version number, payload length and authentication tag:: + +/* + * struct dcp_blob_fmt - DCP BLOB format. + * + * @fmt_version: Format version, currently being %1 + * @blob_key: Random AES 128 key which is used to encrypt @payload, + *
[PATCH v3 1/3] crypto: mxs-dcp: Add support for hardware provided keys
DCP is capable to performing AES with hardware-bound keys. These keys are not stored in main memory and are therefore not directly accessible by the operating system. So instead of feeding the key into DCP, we need to place a reference to such a key before initiating the crypto operation. Keys are referenced by a one byte identifiers. DCP supports 6 different keys: 4 slots in the secure memory area, a one time programmable key which can be burnt via on-chip fuses and an unique device key. Using these keys is restricted to in-kernel users that use them as building block for other crypto tools such as trusted keys. Allowing userspace (e.g. via AF_ALG) to use these keys to crypt or decrypt data is a security risk, because there is no access control mechanism. Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir --- drivers/crypto/mxs-dcp.c | 104 ++- include/soc/fsl/dcp.h| 17 +++ 2 files changed, 110 insertions(+), 11 deletions(-) create mode 100644 include/soc/fsl/dcp.h diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c index f6b7bce0e656..2dc664fb2faf 100644 --- a/drivers/crypto/mxs-dcp.c +++ b/drivers/crypto/mxs-dcp.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -101,6 +102,7 @@ struct dcp_async_ctx { struct crypto_skcipher *fallback; unsigned intkey_len; uint8_t key[AES_KEYSIZE_128]; + boolkey_referenced; }; struct dcp_aes_req_ctx { @@ -155,6 +157,7 @@ static struct dcp *global_sdcp; #define MXS_DCP_CONTROL0_HASH_TERM (1 << 13) #define MXS_DCP_CONTROL0_HASH_INIT (1 << 12) #define MXS_DCP_CONTROL0_PAYLOAD_KEY (1 << 11) +#define MXS_DCP_CONTROL0_OTP_KEY (1 << 10) #define MXS_DCP_CONTROL0_CIPHER_ENCRYPT(1 << 8) #define MXS_DCP_CONTROL0_CIPHER_INIT (1 << 9) #define MXS_DCP_CONTROL0_ENABLE_HASH (1 << 6) @@ -168,6 +171,8 @@ static struct dcp *global_sdcp; #define MXS_DCP_CONTROL1_CIPHER_MODE_ECB (0 << 4) #define MXS_DCP_CONTROL1_CIPHER_SELECT_AES128 (0 << 0) +#define MXS_DCP_CONTROL1_KEY_SELECT_SHIFT 8 + static int mxs_dcp_start_dma(struct dcp_async_ctx *actx) { int dma_err; @@ -224,13 +229,16 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, struct dcp *sdcp = global_sdcp; struct dcp_dma_desc *desc = >coh->desc[actx->chan]; struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); + bool key_referenced = actx->key_referenced; int ret; - key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key, - 2 * AES_KEYSIZE_128, DMA_TO_DEVICE); - ret = dma_mapping_error(sdcp->dev, key_phys); - if (ret) - return ret; + if (!key_referenced) { + key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key, + 2 * AES_KEYSIZE_128, DMA_TO_DEVICE); + ret = dma_mapping_error(sdcp->dev, key_phys); + if (ret) + return ret; + } src_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_in_buf, DCP_BUF_SZ, DMA_TO_DEVICE); @@ -255,8 +263,12 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, MXS_DCP_CONTROL0_INTERRUPT | MXS_DCP_CONTROL0_ENABLE_CIPHER; - /* Payload contains the key. */ - desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY; + if (key_referenced) + /* Set OTP key bit to select the key via KEY_SELECT. */ + desc->control0 |= MXS_DCP_CONTROL0_OTP_KEY; + else + /* Payload contains the key. */ + desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY; if (rctx->enc) desc->control0 |= MXS_DCP_CONTROL0_CIPHER_ENCRYPT; @@ -270,6 +282,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, else desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_CBC; + if (key_referenced) + desc->control1 |= sdcp->coh->aes_key[0] << MXS_DCP_CONTROL1_KEY_SELECT_SHIFT; + desc->next_cmd_addr = 0; desc->source = src_phys; desc->destination = dst_phys; @@ -284,9 +299,9 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, err_dst: dma_unmap_single(sdcp->dev, src_phys, DCP_BUF_SZ, DMA_TO_DEVICE); err_src: - dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128, -DMA_TO_DEVICE); - + if (!key_referenced) + dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128, +DMA_TO_DEVICE); return ret; } @@ -453,7 +468,7 @@ static int
[PATCH v3 0/3] DCP as trusted keys backend
This is a revival of the previous patch set submitted by Richard Weinberger: https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/ v2 is here: https://lore.kernel.org/keyrings/2023091215.24274-1-da...@sigma-star.at/ v2 -> v3: - Addressed review comments from Jarkko Sakkinen v1 -> v2: - Revive and rebase to latest version - Include review comments from Ahmad Fatoum The Data CoProcessor (DCP) is an IP core built into many NXP SoCs such as i.mx6ull. Similar to the CAAM engine used in more powerful SoCs, DCP can AES- encrypt/decrypt user data using a unique, never-disclosed, device-specific key. Unlike CAAM though, it cannot directly wrap and unwrap blobs in hardware. As DCP offers only the bare minimum feature set and a blob mechanism needs aid from software. A blob in this case is a piece of sensitive data (e.g. a key) that is encrypted and authenticated using the device-specific key so that unwrapping can only be done on the hardware where the blob was wrapped. This patch series adds a DCP based, trusted-key backend and is similar in spirit to the one by Ahmad Fatoum [0] that does the same for CAAM. It is of interest for similar use cases as the CAAM patch set, but for lower end devices, where CAAM is not available. Because constructing and parsing the blob has to happen in software, we needed to decide on a blob format and chose the following: struct dcp_blob_fmt { __u8 fmt_version; __u8 blob_key[AES_KEYSIZE_128]; __u8 nonce[AES_KEYSIZE_128]; __le32 payload_len; __u8 payload[]; } __packed; The `fmt_version` is currently 1. The encrypted key is stored in the payload area. It is AES-128-GCM encrypted using `blob_key` and `nonce`, GCM auth tag is attached at the end of the payload (`payload_len` does not include the size of the auth tag). The `blob_key` itself is encrypted in AES-128-ECB mode by DCP using the OTP or UNIQUE device key. A new `blob_key` and `nonce` are generated randomly, when sealing/exporting the DCP blob. This patchset was tested with dm-crypt on an i.MX6ULL board. [0] https://lore.kernel.org/keyrings/20220513145705.2080323-1-a.fat...@pengutronix.de/ David Gstir (3): crypto: mxs-dcp: Add support for hardware provided keys KEYS: trusted: Introduce support for NXP DCP-based trusted keys doc: trusted-encrypted: add DCP as new trust source .../admin-guide/kernel-parameters.txt | 13 + .../security/keys/trusted-encrypted.rst | 85 + MAINTAINERS | 9 + drivers/crypto/mxs-dcp.c | 104 +- include/keys/trusted_dcp.h| 11 + include/soc/fsl/dcp.h | 17 + security/keys/trusted-keys/Kconfig| 9 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 6 +- security/keys/trusted-keys/trusted_dcp.c | 311 ++ 10 files changed, 554 insertions(+), 13 deletions(-) create mode 100644 include/keys/trusted_dcp.h create mode 100644 include/soc/fsl/dcp.h create mode 100644 security/keys/trusted-keys/trusted_dcp.c -- 2.35.3
[PATCH v3 2/3] KEYS: trusted: Introduce support for NXP DCP-based trusted keys
DCP (Data Co-Processor) is the little brother of NXP's CAAM IP. Beside of accelerated crypto operations, it also offers support for hardware-bound keys. Using this feature it is possible to implement a blob mechanism just like CAAM offers. Unlike on CAAM, constructing and parsing the blob has to happen in software. We chose the following format for the blob: /* * struct dcp_blob_fmt - DCP BLOB format. * * @fmt_version: Format version, currently being %1 * @blob_key: Random AES 128 key which is used to encrypt @payload, *@blob_key itself is encrypted with OTP or UNIQUE device key in *AES-128-ECB mode by DCP. * @nonce: Random nonce used for @payload encryption. * @payload_len: Length of the plain text @payload. * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key, * GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it. * * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len + * AES_BLOCK_SIZE. */ struct dcp_blob_fmt { __u8 fmt_version; __u8 blob_key[AES_KEYSIZE_128]; __u8 nonce[AES_KEYSIZE_128]; __le32 payload_len; __u8 payload[]; } __packed; @payload is the key provided by trusted_key_ops->seal(). By default the UNIQUE device key is used, it is also possible to use the OTP key. While the UNIQUE device key should be unique it is not entirely clear whether this is the case due to unclear documentation. If someone wants to be sure they can burn their own unique key into the OTP fuse and set the use_otp_key module parameter. Co-developed-by: Richard Weinberger Signed-off-by: Richard Weinberger Co-developed-by: David Oberhollenzer Signed-off-by: David Oberhollenzer Signed-off-by: David Gstir --- .../admin-guide/kernel-parameters.txt | 13 + MAINTAINERS | 9 + include/keys/trusted_dcp.h| 11 + security/keys/trusted-keys/Kconfig| 9 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 6 +- security/keys/trusted-keys/trusted_dcp.c | 311 ++ 7 files changed, 359 insertions(+), 2 deletions(-) create mode 100644 include/keys/trusted_dcp.h create mode 100644 security/keys/trusted-keys/trusted_dcp.c diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 0a1731a0f0ef..c11eda8b38e0 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6566,6 +6566,7 @@ - "tpm" - "tee" - "caam" + - "dcp" If not specified then it defaults to iterating through the trust source list starting with TPM and assigns the first trust source as a backend which is initialized @@ -6581,6 +6582,18 @@ If not specified, "default" is used. In this case, the RNG's choice is left to each individual trust source. + trusted.dcp_use_otp_key + This is intended to be used in combination with + trusted.source=dcp and will select the DCP OTP key + instead of the DCP UNIQUE key blob encryption. + + trusted.dcp_skip_zk_test + This is intended to be used in combination with + trusted.source=dcp and will disable the check if all + the blob key is zero'ed. This is helpful for situations where + having this key zero'ed is acceptable. E.g. in testing + scenarios. + tsc=Disable clocksource stability checks for TSC. Format: [x86] reliable: mark tsc clocksource as reliable, this diff --git a/MAINTAINERS b/MAINTAINERS index 90f13281d297..988d01226131 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11647,6 +11647,15 @@ S: Maintained F: include/keys/trusted_caam.h F: security/keys/trusted-keys/trusted_caam.c +KEYS-TRUSTED-DCP +M: David Gstir +R: sigma star Kernel Team +L: linux-integr...@vger.kernel.org +L: keyri...@vger.kernel.org +S: Supported +F: include/keys/trusted_dcp.h +F: security/keys/trusted-keys/trusted_dcp.c + KEYS-TRUSTED-TEE M: Sumit Garg L: linux-integr...@vger.kernel.org diff --git a/include/keys/trusted_dcp.h b/include/keys/trusted_dcp.h new file mode 100644 index ..9aaa42075b40 --- /dev/null +++ b/include/keys/trusted_dcp.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (C) 2021 sigma star gmbh + */ + +#ifndef TRUSTED_DCP_H +#define TRUSTED_DCP_H + +extern struct trusted_key_ops dcp_trusted_key_ops; + +#endif diff --git a/security/keys/trusted-keys/Kconfig
Re: [PATCH 1/3] core/device: Add function to return child node using name at substring "@"
On Thu, Sep 14, 2023 at 10:02:04PM +0530, Athira Rajeev wrote: Add a function dt_find_by_name_before_addr() that returns the child node if it matches till first occurrence at "@" of a given name, otherwise NULL. This is helpful for cases with node name like: "name@addr". In scenarios where nodes are added with "name@addr" format and if the value of "addr" is not known, that node can't be matched with node name or addr. Hence matching with substring as node name will return the expected result. Patch adds dt_find_by_name_before_addr() function and testcase for the same in core/test/run-device.c Series applied to skiboot master with the fixup we discussed. -- Reza Arbab
Re: [PATCH 18/26] KVM: s390: Stop adding virt/kvm to the arch include path
On Fri, 15 Sep 2023 17:31:10 -0700 Sean Christopherson wrote: > Don't add virt/kvm to KVM s390's include path, the headers in virt/kvm are > intended to be used only by other code in virt/kvm, i.e. are "private" to > the core KVM code. It's not clear that s390 *ever* included a header from > virt/kvm, i.e. odds are good the "-Ivirt/kvm" was copied from a x86's > Makefile when s390 support was first added. > > The only headers in virt/kvm at the time were the x86 specific ioapic.h, > and iodev.h, neither of which shows up as an #include in the diff for the > commit range 37817f2982d0f..e976a2b997fc4. > > Signed-off-by: Sean Christopherson > --- > arch/s390/kvm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile > index 02217fb4ae10..f17249ab2a72 100644 > --- a/arch/s390/kvm/Makefile > +++ b/arch/s390/kvm/Makefile > @@ -5,7 +5,7 @@ > > include $(srctree)/virt/kvm/Makefile.kvm > > -ccflags-y := -Ivirt/kvm -Iarch/s390/kvm > +ccflags-y := -Iarch/s390/kvm > > kvm-y += kvm-s390.o intercept.o interrupt.o priv.o sigp.o > kvm-y += diag.o gaccess.o guestdbg.o vsie.o pv.o Acked-by: Claudio Imbrenda
Re: [PATCH 10/26] KVM: s390: Stop selecting and depending on HAVE_KVM
On Fri, 15 Sep 2023 17:31:02 -0700 Sean Christopherson wrote: > Now that nothing in s390 or architecture agnostic code consumes HAVE_KVM, > stop selecting it in s390. This is one of several steps towards deleting > HAVE_KVM from the common KVM Kconfig. > > Signed-off-by: Sean Christopherson > --- > arch/s390/Kconfig | 1 - > arch/s390/kvm/Kconfig | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index ae29e4392664..8a5dca0036d9 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -193,7 +193,6 @@ config S390 > select HAVE_KPROBES > select HAVE_KPROBES_ON_FTRACE > select HAVE_KRETPROBES > - select HAVE_KVM > select HAVE_LIVEPATCH > select HAVE_MEMBLOCK_PHYS_MAP > select HAVE_MOD_ARCH_SPECIFIC > diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig > index 459d536116a6..9056cee72945 100644 > --- a/arch/s390/kvm/Kconfig > +++ b/arch/s390/kvm/Kconfig > @@ -19,7 +19,6 @@ if VIRTUALIZATION > config KVM > def_tristate y > prompt "Kernel-based Virtual Machine (KVM) support" > - depends on HAVE_KVM > select PREEMPT_NOTIFIERS > select HAVE_KVM_CPU_RELAX_INTERCEPT > select HAVE_KVM_VCPU_ASYNC_IOCTL it looks like we don't use HAVE_KVM on s390x Reviewed-by: Claudio Imbrenda
Re: [PATCHv3 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO
On Mon, 2023-08-14 at 08:40 -0700, Grant Grundler wrote: > On Sat, Aug 12, 2023 at 5:45 PM David Heidelberg > wrote: > > > > Tested-by: David Heidelberg > > Thanks David! > > > For PATCH v4 please fix the typo reported by the bot :) > > Sorry - I'll do that today. Hi Grant, Is there an update of this series? My workstation suffers from too much correctable AER reporting as well (related to Intel's errata "RPL013: Incorrectly Formed PCIe Packets May Generate Correctable Errors" and/or the motherboard design, I guess). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
[PATCH v2 1/2] m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX
Upstream Linux never had a "README.legal" file, but it was present in early source releases of Linux/m68k. It contained a simple copyright notice and a link to a version of the "COPYING" file that predated the addition of the "only valid GPL version is v2" clause. Get rid of the references to non-existent files by replacing the boilerplate with SPDX license identifiers. Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer --- v2: - Add Acked-by, - s/existant/existent/. --- arch/m68k/68000/entry.S | 7 ++- arch/m68k/bvme6000/config.c | 5 + arch/m68k/coldfire/entry.S | 7 ++- arch/m68k/ifpsp060/Makefile | 6 ++ arch/m68k/kernel/entry.S| 7 ++- arch/m68k/kernel/head.S | 8 ++-- arch/m68k/mvme147/config.c | 5 + arch/m68k/mvme16x/config.c | 5 + arch/m68k/q40/config.c | 5 + 9 files changed, 14 insertions(+), 41 deletions(-) diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S index 7d63e2f1555a03dc..72e95663b62ffd54 100644 --- a/arch/m68k/68000/entry.S +++ b/arch/m68k/68000/entry.S @@ -1,12 +1,9 @@ -/* +/* SPDX-License-Identifier: GPL-2.0-or-later + * * entry.S -- non-mmu 68000 interrupt and exception entry points * * Copyright (C) 1991, 1992 Linus Torvalds * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file README.legal in the main directory of this archive - * for more details. - * * Linux/m68k support by Hamish Macdonald */ diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c index e604fe6602461334..8a2ee69a09f6659c 100644 --- a/arch/m68k/bvme6000/config.c +++ b/arch/m68k/bvme6000/config.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * arch/m68k/bvme6000/config.c * @@ -8,10 +9,6 @@ * linux/amiga/config.c * * Copyright (C) 1993 Hamish Macdonald - * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file README.legal in the main directory of this archive - * for more details. */ #include diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S index 35104c5417ff4d07..4ea08336e2fb0aae 100644 --- a/arch/m68k/coldfire/entry.S +++ b/arch/m68k/coldfire/entry.S @@ -1,4 +1,5 @@ -/* +/* SPDX-License-Identifier: GPL-2.0-or-later + * * entry.S -- interrupt and exception processing for ColdFire * * Copyright (C) 1999-2007, Greg Ungerer (g...@snapgear.com) @@ -13,10 +14,6 @@ * * Copyright (C) 1991, 1992 Linus Torvalds * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file README.legal in the main directory of this archive - * for more details. - * * Linux/m68k support by Hamish Macdonald * * 68060 fixes by Jesper Skov diff --git a/arch/m68k/ifpsp060/Makefile b/arch/m68k/ifpsp060/Makefile index 56b530a96c2f33b5..00d0621f547ccb93 100644 --- a/arch/m68k/ifpsp060/Makefile +++ b/arch/m68k/ifpsp060/Makefile @@ -1,7 +1,5 @@ -# Makefile for 680x0 Linux 68060 integer/floating point support package +# SPDX-License-Identifier: GPL-2.0-or-later # -# This file is subject to the terms and conditions of the GNU General Public -# License. See the file "README.legal" in the main directory of this archive -# for more details. +# Makefile for 680x0 Linux 68060 integer/floating point support package obj-y := fskeleton.o iskeleton.o os.o diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S index 4dd2fd7acba9ea07..3bcdd32a6b36613d 100644 --- a/arch/m68k/kernel/entry.S +++ b/arch/m68k/kernel/entry.S @@ -1,13 +1,10 @@ -/* -*- mode: asm -*- +/* SPDX-License-Identifier: GPL-2.0-or-later + * -*- mode: asm -*- * * linux/arch/m68k/kernel/entry.S * * Copyright (C) 1991, 1992 Linus Torvalds * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file README.legal in the main directory of this archive - * for more details. - * * Linux/m68k support by Hamish Macdonald * * 68060 fixes by Jesper Skov diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S index 9e812d8606be8301..852255cf60dec132 100644 --- a/arch/m68k/kernel/head.S +++ b/arch/m68k/kernel/head.S @@ -1,4 +1,5 @@ -/* -*- mode: asm -*- +/* SPDX-License-Identifier: GPL-2.0-or-later +** -*- mode: asm -*- ** ** head.S -- This file contains the initial boot code for the ** Linux/68k kernel. @@ -25,11 +26,6 @@ **for linux-2.1.115 ** 1999/02/11 Richard Zidlicky: added Q40 support (initial version 99/01/01) ** 2004/05/13 Kars de Jong: Finalised HP300 support -** -** This file is subject to the terms and conditions of the GNU General Public -** License. See the file README.legal in the main directory of this archive -** for more details. -** */ /* diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c index 7dfacd0b207a9750..8b5dc07f0811f2fc 100644 --- a/arch/m68k/mvme147/config.c +++ b/arch/m68k/mvme147/config.c @@ -1,3
[PATCH v2 0/2] m68k/powerpc: Kill references to non-existent README.legal
Hi all, Several source files contain license boilerplate that refers to the file "README.legal", which never existed in upstream Linux. This is a relic from the early port of Linux to the m68k processor family, before it was merged in v1.3.94. Later, copies of this boilerplate ended up in the PowerPC port. The "README.legal" file (from e.g. [1]) read: ---8<- Legal information about the Linux/68k software package All files contained in this archive are copyrighted by one or more person. They are not in the public domain. Most of the files are copyrighted by Linus Torvalds, the original writer of Linux for IBM PC clone systems. Some parts are copyrighted by other IBM PC linux developers. Other parts are copyrighted by Linux/68k developers. This package is subject to the terms and conditions of the GNU General Public License. A copy of this license may be found in the file named "COPYING" which should be in the same directory as this file. If the file has been omitted, you may obtain it by writing to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ->8--- Note that the "COPYING" file at that time corresponded to the version from upstream Linux v0.99.11 until v2.1.104, and thus predated the addition of the "only valid GPL version is v2" clause in v2.4.0-test8. This patch series gets rid of the references to README.legal by replacing the boilerplate with SPDX license identifiers. Changes compared to v1[2]: - Add Acked-by, - s/existant/existent/. Thanks for your comments! [1] https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/680x0/v0.9/linux-0.9.tar.gz [2] "[PATCH 0/2] m68k/powerpc: Kill references to non-existent README.legal https://lore.kernel.org/r/cover.1694095086.git.ge...@linux-m68k.org Geert Uytterhoeven (2): m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX arch/m68k/68000/entry.S | 7 ++- arch/m68k/bvme6000/config.c | 5 + arch/m68k/coldfire/entry.S | 7 ++- arch/m68k/ifpsp060/Makefile | 6 ++ arch/m68k/kernel/entry.S| 7 ++- arch/m68k/kernel/head.S | 8 ++-- arch/m68k/mvme147/config.c | 5 + arch/m68k/mvme16x/config.c | 5 + arch/m68k/q40/config.c | 5 + arch/powerpc/kernel/ptrace/ptrace.c | 5 + arch/powerpc/kernel/signal.c| 5 + arch/powerpc/kernel/signal.h| 7 ++- 12 files changed, 18 insertions(+), 54 deletions(-) -- 2.34.1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
[PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX
Upstream Linux never had a "README.legal" file, but it was present in early source releases of Linux/m68k. It contained a simple copyright notice and a link to a version of the "COPYING" file that predated the addition of the "only valid GPL version is v2" clause. Get rid of the references to non-existent files by replacing the boilerplate with SPDX license identifiers. Signed-off-by: Geert Uytterhoeven --- v2: - s/existant/existent/. --- arch/powerpc/kernel/ptrace/ptrace.c | 5 + arch/powerpc/kernel/signal.c| 5 + arch/powerpc/kernel/signal.h| 7 ++- 3 files changed, 4 insertions(+), 13 deletions(-) diff --git a/arch/powerpc/kernel/ptrace/ptrace.c b/arch/powerpc/kernel/ptrace/ptrace.c index 5d7a72b41ae71158..727ed4a145451356 100644 --- a/arch/powerpc/kernel/ptrace/ptrace.c +++ b/arch/powerpc/kernel/ptrace/ptrace.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * PowerPC version *Copyright (C) 1995-1996 Gary Thomas (g...@linuxppc.org) @@ -9,10 +10,6 @@ * * Modified by Cort Dougan (c...@hq.fsmlabs.com) * and Paul Mackerras (pau...@samba.org). - * - * This file is subject to the terms and conditions of the GNU General - * Public License. See the file README.legal in the main directory of - * this archive for more details. */ #include diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c index 68a91e553e14cea2..aa17e62f37547a79 100644 --- a/arch/powerpc/kernel/signal.c +++ b/arch/powerpc/kernel/signal.c @@ -1,12 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * Common signal handling code for both 32 and 64 bits * *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation *Extracted from signal_32.c and signal_64.c - * - * This file is subject to the terms and conditions of the GNU General - * Public License. See the file README.legal in the main directory of - * this archive for more details. */ #include diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h index a429c57ed4331805..58ecea1cdc27ae80 100644 --- a/arch/powerpc/kernel/signal.h +++ b/arch/powerpc/kernel/signal.h @@ -1,10 +1,7 @@ -/* +/* SPDX-License-Identifier: GPL-2.0-or-later + * *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation *Extracted from signal_32.c and signal_64.c - * - * This file is subject to the terms and conditions of the GNU General - * Public License. See the file README.legal in the main directory of - * this archive for more details. */ #ifndef _POWERPC_ARCH_SIGNAL_H -- 2.34.1
Re: [PATCH tty v1 00/74] serial: wrappers for uart port lock
On Mon, Sep 18, 2023 at 10:29:30AM +0206, John Ogness wrote: > On 2023-09-14, John Ogness wrote: > > Provide and use wrapper functions for spin_[un]lock*(port->lock) > > invocations so that the console mechanics can be applied later on at a > > single place and does not require to copy the same logic all over the > > drivers. > > For the full 74-patch series: > > Signed-off-by: John Ogness > > Sorry that my SoB was missing from the initial posting. Thanks for this, I'll rebuild my tree with this added. greg k-h
Re: [PATCH tty v1 00/74] serial: wrappers for uart port lock
On 2023-09-14, John Ogness wrote: > Provide and use wrapper functions for spin_[un]lock*(port->lock) > invocations so that the console mechanics can be applied later on at a > single place and does not require to copy the same logic all over the > drivers. For the full 74-patch series: Signed-off-by: John Ogness Sorry that my SoB was missing from the initial posting. John Ogness
Questions: Should kernel panic when PCIe fatal error occurs?
Hi, all folks, Error reporting and recovery are one of the important features of PCIe, and the kernel has been supporting them since version 2.6, 17 years ago. I am very curious about the expected behavior of the software. I first recap the error classification and then list my questions bellow it. ## Recap: Error classification - Fatal Errors Fatal errors are uncorrectable error conditions which render the particular Link and related hardware unreliable. For Fatal errors, a reset of the components on the Link may be required to return to reliable operation. Platform handling of Fatal errors, and any efforts to limit the effects of these errors, is platform implementation specific. (PCIe 6.0.1, sec 6.2.2.2.1 Fatal Errors). - Non-Fatal Errors Non-fatal errors are uncorrectable errors which cause a particular transaction to be unreliable but the Link is otherwise fully functional. Isolating Non-fatal from Fatal errors provides Requester/Receiver logic in a device or system management software the opportunity to recover from the error without resetting the components on the Link and disturbing other transactions in progress. Devices not associated with the transaction in error are not impacted by the error. (PCIe 6.0.1, sec 6.2.2.2.1 Non-Fatal Errors). ## What the kernel do? The Linux kernel supports both the OS native and firmware first modes in AER and DPC drivers. The error recovery API is defined in `struct pci_error_handlers`, and the recovery process is performed in several stages in pcie_do_recovery(). One main difference in handling PCIe errors is that the kernel only resets the link when a fatal error is detected. ## Questions 1. Should kernel panic when fatal errors occur without AER recovery? IMHO, the answer is NO. The AER driver handles both fatal and non-fatal errors, and I have not found any panic changes in the recovery path in OS native mode. As far as I know, on many X86 platforms, struct `acpi_hest_generic_status::error_severity` is set as CPER_SEV_FATAL in firmware first mode. As a result, kernel will panic immediately in ghes_proc() when fatal AER errors occur, and there is no chance to handle the error and perform recovery in AER driver. For fatal and non-fatal errors, struct `acpi_hest_generic_status::error_severity` should as CPER_SEV_RECOVERABLE, and struct `acpi_hest_generic_data::error_severity` should reflect its real severity. Then, the kernel is equivalent to handling PCIe errors in Firmware first mode as it does in OS native mode. Please correct me if I am wrong. However, I have changed my mind on this issue as I encounter a case where a error propagation is detected due to fatal DLLP (Data Link Protocol Error) error. A DLLP error occurred in the Compute node, causing the node to panic because `struct acpi_hest_generic_status::error_severity` was set as CPER_SEV_FATAL. However, data corruption was still detected in the storage node by CRC. 2. Should kernel panic when AER recovery failed? This question is actually a TODO that was added when the AER driver was first upstreamed 17 years ago, and it is still relevant today. The kernel does not proactively panic regardless of the error types occurring in OS native mode. The DLLP error propagation case indicates that the kernel might should panic when recovery failed? 3. Should DPC be enabled by default to contain fatal and non-fatal error? According to the PCIe specification, DPC halts PCIe traffic below a Downstream Port after an unmasked uncorrectable error is detected at or below the Port, avoiding the potential spread of any data corruption. The kernel configures DPC to be triggered only on ERR_FATAL. Literally speaking, only fatal error have the potential spread of any data corruption? In addition, the AER Severity is programable by the Uncorrectable Error Severity Register (Offset 0Ch in PCIe AER cap). If a default fatal error, e.g. DLLP, set as non-fatal, DPC will not be triggered. Looking forward to any comments and reply :) Thank you. Best Regards, Shuai [1] https://github.com/torvalds/linux/commit/6c2b374d74857e892080ee726184ec1d15e7d4e4#diff-fea64904d30501b59d2e948189bbedc476fc270ed4c15e4ae29d7f0efd06771aR438
Re: [PATCH v5 28/31] pinctrl: Add support for the Lantic PEF2256 pinmux
On Tue, 12 Sep 2023 13:04:56 +0200 Linus Walleij wrote: > Hi Herve, > > thanks for your patch! > > On Tue, Sep 12, 2023 at 12:15 PM Herve Codina > wrote: > > > The Lantiq PEF2256 is a framer and line interface component designed to > > fulfill all required interfacing between an analog E1/T1/J1 line and the > > digital PCM system highway/H.100 bus. > > > > This kind of component can be found in old telecommunication system. > > It was used to digital transmission of many simultaneous telephone calls > > by time-division multiplexing. Also using HDLC protocol, WAN networks > > can be reached through the framer. > > > > This pinmux support handles the pin muxing part (pins RP(A..D) and pins > > XP(A..D)) of the PEF2256. > > > > Signed-off-by: Herve Codina > > Reviewed-by: Christophe Leroy > > Signed-off-by: Christophe Leroy > > Nice to see this as a proper pin control driver! > > > drivers/pinctrl/pinctrl-pef2256-regs.h | 65 ++ > > drivers/pinctrl/pinctrl-pef2256.c | 308 + > > Do you really need a separate header just for some registers? > But it's a matter of taste so I'm not gonna complain if you want > it this way. Will be move to the .c file in the next iteration. > > > +config PINCTRL_PEF2256 > > + tristate "Lantiq PEF2256 (FALC56) pin controller driver" > > + depends on OF && FRAMER_PEF2256 > > + select PINMUX > > select PINCONF Will be added in the next iteration. > > > + select GENERIC_PINCONF > > This brings it in implicitly but I prefer that you just select it. > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > I think SPDX mandates that you start the tag with C99 comments Already replied by Mark, C style comment is correct -> No change. > > // SPDX-License-Identifier: GPL-2.0-only > > > + /* We map 1 group <-> 1 pin */ > > Also known as "the qualcomm trick", but hey: it's fine. > > > +static int pef2256_register_pinctrl(struct pef2256_pinctrl *pef2256) > > +{ > > + struct pinctrl_dev *pctrl; > > + > > + pef2256->pctrl_desc.name= dev_name(pef2256->dev); > > + pef2256->pctrl_desc.owner = THIS_MODULE; > > + pef2256->pctrl_desc.pctlops = _pctlops; > > + pef2256->pctrl_desc.pmxops = _pmxops; > > + if (pef2256->version == PEF2256_VERSION_1_2) { > > + pef2256->pctrl_desc.pins = pef2256_v12_pins; > > + pef2256->pctrl_desc.npins = ARRAY_SIZE(pef2256_v12_pins); > > + pef2256->functions = pef2256_v12_functions; > > + pef2256->nfunctions = ARRAY_SIZE(pef2256_v12_functions); > > + } else { > > + pef2256->pctrl_desc.pins = pef2256_v2x_pins; > > + pef2256->pctrl_desc.npins = ARRAY_SIZE(pef2256_v2x_pins); > > + pef2256->functions = pef2256_v2x_functions; > > + pef2256->nfunctions = ARRAY_SIZE(pef2256_v2x_functions); > > + } > > + > > + pctrl = devm_pinctrl_register(pef2256->dev, >pctrl_desc, > > pef2256); > > + if (IS_ERR(pctrl)) { > > + dev_err(pef2256->dev, "pinctrl driver registration > > failed\n"); > > + return PTR_ERR(pctrl); > > + } > > + > > + return 0; > > You could use > return dev_err_probe(...); Indeed, I will change. > > > + pef2256_reset_pinmux(pef2256_pinctrl); > > + ret = pef2256_register_pinctrl(pef2256_pinctrl); > > + if (ret) > > + return ret; > > Or you could use it down here. > > With or without these changes (because they are nitpicks) > Reviewed-by: Linus Walleij > > Yours, > Linus Walleij Thanks for your comment. Best regards, Hervé
Re: [PATCH v5 25/31] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
On Mon, 18 Sep 2023 09:49:19 +0200 Herve Codina wrote: > Hi Christophe, > > On Tue, 12 Sep 2023 18:49:26 + > Christophe Leroy wrote: > > > Le 12/09/2023 à 20:13, Conor Dooley a écrit : > > > Yo, > > > > > > I'm not au fait enough with this to leave particularly meaningful > > > comments, so just some minor ones for you. > > > > > > On Tue, Sep 12, 2023 at 12:14:44PM +0200, Herve Codina wrote: > > >> The Lantiq PEF2256 is a framer and line interface component designed to > > >> fulfill all required interfacing between an analog E1/T1/J1 line and the > > >> digital PCM system highway/H.100 bus. > > >> > > >> Signed-off-by: Herve Codina > > >> Signed-off-by: Christophe Leroy > > > > > > Missing a co-developed-by? > > > > No, I guess it's a left-over of version v4 that I sent-out while Hervé > > was AFK. > > > > If a v6 is sent I think this line can be removed. > > May I move to reviewed-by ? Your signed-of tag is present on all patches (left-over of version v4) May I remove your signed-of (or move to reviewed-by if relevant) in all patches present in this series ? Best regards, Hervé > > > > > Christophe > > > -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes
On 9/14/2023 9:55 AM, Sean Christopherson wrote: From: Chao Peng [...] +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES +/* + * Returns true if _all_ gfns in the range [@start, @end) have attributes + * matching @attrs. + */ +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, +unsigned long attrs) +{ + XA_STATE(xas, >mem_attr_array, start); + unsigned long index; + bool has_attrs; + void *entry; + + rcu_read_lock(); + + if (!attrs) { + has_attrs = !xas_find(, end); IIUIC, xas_find() is inclusive for "end", so here should be "end - 1" ? + goto out; + } + + has_attrs = true; + for (index = start; index < end; index++) { + do { + entry = xas_next(); + } while (xas_retry(, entry)); + + if (xas.xa_index != index || xa_to_value(entry) != attrs) { + has_attrs = false; + break; + } + } + +out: + rcu_read_unlock(); + return has_attrs; +} + [...]
Re: [PATCH v5 25/31] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
Hi Christophe, On Tue, 12 Sep 2023 18:49:26 + Christophe Leroy wrote: > Le 12/09/2023 à 20:13, Conor Dooley a écrit : > > Yo, > > > > I'm not au fait enough with this to leave particularly meaningful > > comments, so just some minor ones for you. > > > > On Tue, Sep 12, 2023 at 12:14:44PM +0200, Herve Codina wrote: > >> The Lantiq PEF2256 is a framer and line interface component designed to > >> fulfill all required interfacing between an analog E1/T1/J1 line and the > >> digital PCM system highway/H.100 bus. > >> > >> Signed-off-by: Herve Codina > >> Signed-off-by: Christophe Leroy > > > > Missing a co-developed-by? > > No, I guess it's a left-over of version v4 that I sent-out while Hervé > was AFK. > > If a v6 is sent I think this line can be removed. May I move to reviewed-by ? > > Christophe -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v5 08/31] dt-bindings: soc: fsl: cpm_qe: cpm1-scc-qmc: Add support for QMC HDLC
Hi Conor, On Wed, 13 Sep 2023 15:59:41 +0100 Conor Dooley wrote: > On Wed, Sep 13, 2023 at 03:56:16PM +0100, Conor Dooley wrote: > > On Wed, Sep 13, 2023 at 04:52:50PM +0200, Herve Codina wrote: > > > On Wed, 13 Sep 2023 15:42:45 +0100 > > > Conor Dooley wrote: > > > > > > > On Wed, Sep 13, 2023 at 09:26:40AM +0200, Herve Codina wrote: > > > > > Hi Conor, > > > > > > > > > > On Tue, 12 Sep 2023 18:21:58 +0100 > > > > > Conor Dooley wrote: > > > > > > > > > > > On Tue, Sep 12, 2023 at 12:10:18PM +0200, Herve Codina wrote: > > > > > > > The QMC (QUICC mutichannel controller) is a controller present in > > > > > > > some > > > > > > > PowerQUICC SoC such as MPC885. > > > > > > > The QMC HDLC uses the QMC controller to transfer HDLC data. > > > > > > > > > > > > > > Additionally, a framer can be connected to the QMC HDLC. > > > > > > > If present, this framer is the interface between the TDM bus used > > > > > > > by the > > > > > > > QMC HDLC and the E1/T1 line. > > > > > > > The QMC HDLC can use this framer to get information about the > > > > > > > E1/T1 line > > > > > > > and configure the E1/T1 line. > > > > > > > > > > > > > > Signed-off-by: Herve Codina > > > > > > > --- > > > > > > > .../bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml | 13 > > > > > > > + > > > > > > > 1 file changed, 13 insertions(+) > > > > > > > > > > > > > > diff --git > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > > > > > > > > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > > > > > > > index 82d9beb48e00..b5073531f3f1 100644 > > > > > > > --- > > > > > > > a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > > > > > > > +++ > > > > > > > b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,cpm1-scc-qmc.yaml > > > > > > > @@ -101,6 +101,16 @@ patternProperties: > > > > > > >Channel assigned Rx time-slots within the Rx > > > > > > > time-slots routed by the > > > > > > >TSA to this cell. > > > > > > > > > > > > > > + compatible: > > > > > > > +const: fsl,qmc-hdlc > > > > > > > + > > > > > > > + fsl,framer: > > > > > > > +$ref: /schemas/types.yaml#/definitions/phandle > > > > > > > +description: > > > > > > > + phandle to the framer node. The framer is in charge of > > > > > > > an E1/T1 line > > > > > > > + interface connected to the TDM bus. It can be used to > > > > > > > get the E1/T1 line > > > > > > > + status such as link up/down. > > > > > > > > > > > > Sounds like this fsl,framer property should depend on the compatible > > > > > > being present, no? > > > > > > > > > > Well from the implementation point of view, only the QMC HDLC driver > > > > > uses this > > > > > property. > > > > > > > > > > From the hardware description point of view, this property means that > > > > > the time slots > > > > > handled by this channel are connected to the framer. So I think it > > > > > makes sense for > > > > > any channel no matter the compatible (even if compatible is not > > > > > present). > > > > > > > > > > Should I change and constraint the fsl,framer property to the > > > > > compatible presence ? > > > > > If so, is the following correct for this contraint ? > > > > >--- 8< --- > > > > >dependencies: > > > > > - fsl,framer: [ compatible ]; > > > > >--- 8< --- > > > > > > > > The regular sort of > > > > if: > > > > compatible: > > > > contains: > > > > const: foo > > > > then: > > > > required: > > > > - fsl,framer > > > > would fit the bill, no? > > > > > > Not sure. > > > "fsl,framer" is an optional property (depending on the hardware we can > > > have > > > a framer or not). > > > > Ah apologies, I had it backwards! Your suggestion seems fair in that > > case. > > Or actually, > if: > compatible: > not: > contains: > const: foo > then: > properties: > fsl,framer: false > ? That should do the trick in a more conventional way. Thanks for this proposal. I will use it in the next iteration. Regards, Hervé
Re: [PATCH v4 0/5] ppc, fbdev: Clean up fbdev mmap helper
Ping for a review. I'd like to get at least the first two patches into the DRM git tree. The PPC patches could later be merged through another tree. Best regards Thomas Am 12.09.23 um 15:48 schrieb Thomas Zimmermann: Clean up and rename fb_pgprotect() to work without struct file. Then refactor the implementation for PowerPC. This change has been discussed at [1] in the context of refactoring fbdev's mmap code. The first two patches update fbdev and replace fbdev's fb_pgprotect() with pgprot_framebuffer() on all architectures. The new helper's stream- lined interface enables more refactoring within fbdev's mmap implementation. Patches 3 to 5 adapt PowerPC's internal interfaces to provide phys_mem_access_prot() that works without struct file. Neither the architecture code or fbdev helpers need the parameter. v4: * fix commit message (Christophe) v3: * rename fb_pgrotect() to pgprot_framebuffer() (Arnd) v2: * reorder patches to simplify merging (Michael) [1] https://lore.kernel.org/linuxppc-dev/5501ba80-bdb0-6344-16b0-0466a950f...@suse.com/ Thomas Zimmermann (5): fbdev: Avoid file argument in fb_pgprotect() fbdev: Replace fb_pgprotect() with pgprot_framebuffer() arch/powerpc: Remove trailing whitespaces arch/powerpc: Remove file parameter from phys_mem_access_prot code arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code arch/ia64/include/asm/fb.h| 15 +++ arch/m68k/include/asm/fb.h| 19 ++- arch/mips/include/asm/fb.h| 11 +-- arch/powerpc/include/asm/book3s/pgtable.h | 10 -- arch/powerpc/include/asm/fb.h | 13 + arch/powerpc/include/asm/machdep.h| 13 ++--- arch/powerpc/include/asm/nohash/pgtable.h | 10 -- arch/powerpc/include/asm/pci.h| 4 +--- arch/powerpc/kernel/pci-common.c | 3 +-- arch/powerpc/mm/mem.c | 8 arch/sparc/include/asm/fb.h | 15 +-- arch/x86/include/asm/fb.h | 10 ++ arch/x86/video/fbdev.c| 15 --- drivers/video/fbdev/core/fb_chrdev.c | 3 ++- include/asm-generic/fb.h | 12 ++-- 15 files changed, 86 insertions(+), 75 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH v3 13/13] bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of
From: "Mike Rapoport (IBM)" BPF just-in-time compiler depended on CONFIG_MODULES because it used module_alloc() to allocate memory for the generated code. Since code allocations are now implemented with execmem, drop dependency of CONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECMEM. Suggested-by: Björn Töpel Signed-off-by: Mike Rapoport (IBM) --- kernel/bpf/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig index 6a906ff93006..5be11c906f93 100644 --- a/kernel/bpf/Kconfig +++ b/kernel/bpf/Kconfig @@ -42,7 +42,7 @@ config BPF_JIT bool "Enable BPF Just In Time compiler" depends on BPF depends on HAVE_CBPF_JIT || HAVE_EBPF_JIT - depends on MODULES + select EXECMEM help BPF programs are normally handled by a BPF interpreter. This option allows the kernel to generate native code when a program is loaded -- 2.39.2
[PATCH v3 12/13] kprobes: remove dependency 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, make CONFIG_KPROBES select CONFIG_EXECMEM and drop the dependency of CONFIG_KPROBES on CONFIG_MODULES. Signed-off-by: Mike Rapoport (IBM) --- arch/Kconfig| 2 +- kernel/kprobes.c| 43 + kernel/trace/trace_kprobe.c | 11 ++ 3 files changed, 37 insertions(+), 19 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 12d51495caec..c52a600b63ca 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -52,9 +52,9 @@ config GENERIC_ENTRY config KPROBES bool "Kprobes" - depends on MODULES depends on HAVE_KPROBES select KALLSYMS + select EXECMEM select TASKS_RCU if PREEMPTION help Kprobes allows you to trap at almost any kernel address and diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 0ccb4d2ec9a2..c95d0088f966 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1580,6 +1580,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } +#ifdef CONFIG_MODULES /* Check if 'p' is probing a module. */ *probed_mod = __module_text_address((unsigned long) p->addr); if (*probed_mod) { @@ -1603,6 +1604,8 @@ static int check_kprobe_address_safe(struct kprobe *p, ret = -ENOENT; } } +#endif + out: preempt_enable(); jump_label_unlock(); @@ -2495,24 +2498,6 @@ int kprobe_add_area_blacklist(unsigned long start, unsigned long end) return 0; } -/* Remove all symbols in given area from kprobe blacklist */ -static void kprobe_remove_area_blacklist(unsigned long start, unsigned long end) -{ - struct kprobe_blacklist_entry *ent, *n; - - list_for_each_entry_safe(ent, n, _blacklist, list) { - if (ent->start_addr < start || ent->start_addr >= end) - continue; - list_del(>list); - kfree(ent); - } -} - -static void kprobe_remove_ksym_blacklist(unsigned long entry) -{ - kprobe_remove_area_blacklist(entry, entry + 1); -} - int __weak arch_kprobe_get_kallsym(unsigned int *symnum, unsigned long *value, char *type, char *sym) { @@ -2577,6 +2562,25 @@ static int __init populate_kprobe_blacklist(unsigned long *start, return ret ? : arch_populate_kprobe_blacklist(); } +#ifdef CONFIG_MODULES +/* Remove all symbols in given area from kprobe blacklist */ +static void kprobe_remove_area_blacklist(unsigned long start, unsigned long end) +{ + struct kprobe_blacklist_entry *ent, *n; + + list_for_each_entry_safe(ent, n, _blacklist, list) { + if (ent->start_addr < start || ent->start_addr >= end) + continue; + list_del(>list); + kfree(ent); + } +} + +static void kprobe_remove_ksym_blacklist(unsigned long entry) +{ + kprobe_remove_area_blacklist(entry, entry + 1); +} + static void add_module_kprobe_blacklist(struct module *mod) { unsigned long start, end; @@ -2678,6 +2682,7 @@ static struct notifier_block kprobe_module_nb = { .notifier_call = kprobes_module_callback, .priority = 0 }; +#endif void kprobe_free_init_mem(void) { @@ -2737,8 +2742,10 @@ static int __init init_kprobes(void) err = arch_init_kprobes(); if (!err) err = register_die_notifier(_exceptions_nb); +#ifdef CONFIG_MODULES if (!err) err = register_module_notifier(_module_nb); +#endif kprobes_initialized = (err == 0); kprobe_sysctls_init(); diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index 3d7a180a8427..25a5293a80c0 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -111,6 +111,7 @@ static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk, return strncmp(module_name(mod), name, len) == 0 && name[len] == ':'; } +#ifdef CONFIG_MODULES static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk) { char *p; @@ -129,6 +130,12 @@ static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk) return ret; } +#else +static inline bool trace_kprobe_module_exist(struct trace_kprobe *tk) +{ + return false; +} +#endif static bool trace_kprobe_is_busy(struct dyn_event *ev) { @@ -670,6 +677,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk) return ret; } +#ifdef CONFIG_MODULES /* Module notifier call back, checking event on the module */ static int trace_kprobe_module_callback(struct notifier_block *nb,
[PATCH v3 11/13] 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 CONFIG_DYNAMIC_FTRACE select CONFIG_EXECMEM in Kconfig. Signed-off-by: Mike Rapoport (IBM) --- arch/x86/Kconfig | 1 + arch/x86/kernel/ftrace.c | 10 -- 2 files changed, 1 insertion(+), 10 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 982b777eadc7..cc7c4a0a8c16 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -35,6 +35,7 @@ config X86_64 select SWIOTLB select ARCH_HAS_ELFCORE_COMPAT select ZONE_DMA32 + select EXECMEM if DYNAMIC_FTRACE config FORCE_DYNAMIC_FTRACE def_bool y diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index ae56d79a6a74..7ed7e8297ba3 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -261,8 +261,6 @@ void arch_ftrace_update_code(int command) /* Currently only x86_64 supports dynamic trampolines */ #ifdef CONFIG_X86_64 -#ifdef CONFIG_MODULES -/* Module allocation simplifies allocating memory for code */ static inline void *alloc_tramp(unsigned long size) { return execmem_text_alloc(EXECMEM_FTRACE, size); @@ -271,14 +269,6 @@ static inline void tramp_free(void *tramp) { execmem_free(tramp); } -#else -/* Trampolines can only be created if modules are supported */ -static inline void *alloc_tramp(unsigned long size) -{ - return NULL; -} -static inline void tramp_free(void *tramp) { } -#endif /* Defined as markers to the end of the ftrace default trampolines */ extern void ftrace_regs_caller_end(void); -- 2.39.2
[PATCH v3 10/13] 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: Mike Rapoport (IBM) --- arch/arm/kernel/module.c | 38 -- arch/arm/mm/init.c | 38 ++ arch/arm64/kernel/module.c | 130 arch/arm64/mm/init.c | 132 + arch/loongarch/kernel/module.c | 18 - arch/loongarch/mm/init.c | 20 + arch/mips/kernel/module.c | 19 - arch/mips/mm/init.c| 20 + arch/parisc/kernel/module.c| 17 - arch/parisc/mm/init.c | 22 +- arch/powerpc/kernel/module.c | 60 --- arch/powerpc/mm/mem.c | 62 arch/riscv/kernel/module.c | 39 -- arch/riscv/mm/init.c | 39 ++ arch/s390/kernel/module.c | 25 --- arch/s390/mm/init.c| 28 +++ arch/sparc/kernel/module.c | 23 -- arch/sparc/mm/Makefile | 2 + arch/sparc/mm/execmem.c| 25 +++ arch/x86/kernel/module.c | 27 --- arch/x86/mm/init.c | 29 21 files changed, 416 insertions(+), 397 deletions(-) create mode 100644 arch/sparc/mm/execmem.c diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c index 2c7651a2d84c..3282f304f6b1 100644 --- a/arch/arm/kernel/module.c +++ b/arch/arm/kernel/module.c @@ -16,50 +16,12 @@ #include #include #include -#include #include #include #include #include -#ifdef CONFIG_XIP_KERNEL -/* - * The XIP kernel text is mapped in the module area for modules and - * some other stuff to work without any indirect relocations. - * MODULES_VADDR is redefined here and not in asm/memory.h to avoid - * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off. - */ -#undef MODULES_VADDR -#define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK) -#endif - -#ifdef CONFIG_MMU -static struct execmem_params execmem_params __ro_after_init = { - .ranges = { - [EXECMEM_DEFAULT] = { - .start = MODULES_VADDR, - .end = MODULES_END, - .alignment = 1, - }, - }, -}; - -struct execmem_params __init *execmem_arch_params(void) -{ - struct execmem_range *r = _params.ranges[EXECMEM_DEFAULT]; - - r->pgprot = PAGE_KERNEL_EXEC; - - if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS)) { - r->fallback_start = VMALLOC_START; - r->fallback_end = VMALLOC_END; - } - - return _params; -} -#endif - bool module_init_section(const char *name) { return strstarts(name, ".init") || diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index a42e4cd11db2..c0b536e398b4 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include @@ -486,3 +487,40 @@ void free_initrd_mem(unsigned long start, unsigned long end) free_reserved_area((void *)start, (void *)end, -1, "initrd"); } #endif + +#ifdef CONFIG_XIP_KERNEL +/* + * The XIP kernel text is mapped in the module area for modules and + * some other stuff to work without any indirect relocations. + * MODULES_VADDR is redefined here and not in asm/memory.h to avoid + * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off. + */ +#undef MODULES_VADDR +#define MODULES_VADDR (((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK) +#endif + +#if defined(CONFIG_MMU) && defined(CONFIG_EXECMEM) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .start = MODULES_VADDR, + .end = MODULES_END, + .alignment = 1, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) +{ + struct execmem_range *r = _params.ranges[EXECMEM_DEFAULT]; + + r->pgprot = PAGE_KERNEL_EXEC; + + if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS)) { + r->fallback_start = VMALLOC_START; + r->fallback_end = VMALLOC_END; + } + + return _params; +} +#endif diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index d27db168d2a2..eb1505128b75 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -20,142 +20,12 @@ #include #include #include -#include #include #include #include #include -static u64 module_direct_base __ro_after_init = 0; -static u64 module_plt_base __ro_after_init = 0; - -/* - * Choose a random page-aligned base address for a window of 'size' bytes which - * entirely contains the interval [start, end - 1]. - */ -static u64 __init
[PATCH v3 09/13] 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 EXECMEM_KRPOBES to execmem_params to allow using the generic kprobes::alloc_insn_page() with the desired permissions. As powerpc uses breakpoint instructions to inject kprobes, it does not need to constrain kprobe allocations to the modules area and can use the entire vmalloc address space. Signed-off-by: Mike Rapoport (IBM) --- arch/powerpc/kernel/kprobes.c | 14 -- arch/powerpc/kernel/module.c | 11 +++ 2 files changed, 11 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c index 62228c7072a2..14c5ddec3056 100644 --- a/arch/powerpc/kernel/kprobes.c +++ b/arch/powerpc/kernel/kprobes.c @@ -126,20 +126,6 @@ kprobe_opcode_t *arch_adjust_kprobe_addr(unsigned long addr, unsigned long offse return (kprobe_opcode_t *)(addr + offset); } -void *alloc_insn_page(void) -{ - void *page; - - page = execmem_text_alloc(EXECMEM_KPROBES, PAGE_SIZE); - if (!page) - return NULL; - - if (strict_module_rwx_enabled()) - set_memory_rox((unsigned long)page, 1); - - return page; -} - int arch_prepare_kprobe(struct kprobe *p) { int ret = 0; diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c index 824d9541a310..bf2c62aef628 100644 --- a/arch/powerpc/kernel/module.c +++ b/arch/powerpc/kernel/module.c @@ -95,6 +95,9 @@ static struct execmem_params execmem_params __ro_after_init = { [EXECMEM_DEFAULT] = { .alignment = 1, }, + [EXECMEM_KPROBES] = { + .alignment = 1, + }, [EXECMEM_MODULE_DATA] = { .alignment = 1, }, @@ -135,5 +138,13 @@ struct execmem_params __init *execmem_arch_params(void) range->pgprot = prot; + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START; + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_END; + + if (strict_module_rwx_enabled()) + execmem_params.ranges[EXECMEM_KPROBES].pgprot = PAGE_KERNEL_ROX; + else + execmem_params.ranges[EXECMEM_KPROBES].pgprot = PAGE_KERNEL_EXEC; + return _params; } -- 2.39.2
[PATCH v3 08/13] riscv: extend execmem_params for generated code allocations
From: "Mike Rapoport (IBM)" The memory allocations for kprobes and BPF on RISC-V are not placed in the modules area and these custom allocations are implemented with overrides of alloc_insn_page() and bpf_jit_alloc_exec(). Slightly reorder execmem_params initialization to support both 32 and 64 bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in riscv::execmem_params and drop overrides of alloc_insn_page() and bpf_jit_alloc_exec(). Signed-off-by: Mike Rapoport (IBM) --- arch/riscv/kernel/module.c | 21 - arch/riscv/kernel/probes/kprobes.c | 10 -- arch/riscv/net/bpf_jit_core.c | 13 - 3 files changed, 20 insertions(+), 24 deletions(-) diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c index 343a0edfb6dd..31505ecb5c72 100644 --- a/arch/riscv/kernel/module.c +++ b/arch/riscv/kernel/module.c @@ -436,20 +436,39 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab, return 0; } -#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) +#ifdef CONFIG_MMU static struct execmem_params execmem_params __ro_after_init = { .ranges = { [EXECMEM_DEFAULT] = { .pgprot = PAGE_KERNEL, .alignment = 1, }, + [EXECMEM_KPROBES] = { + .pgprot = PAGE_KERNEL_READ_EXEC, + .alignment = 1, + }, + [EXECMEM_BPF] = { + .pgprot = PAGE_KERNEL, + .alignment = 1, + }, }, }; struct execmem_params __init *execmem_arch_params(void) { +#ifdef CONFIG_64BIT execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR; execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END; +#else + execmem_params.ranges[EXECMEM_DEFAULT].start = VMALLOC_START; + execmem_params.ranges[EXECMEM_DEFAULT].end = VMALLOC_END; +#endif + + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START; + execmem_params.ranges[EXECMEM_KPROBES].end = VMALLOC_END; + + execmem_params.ranges[EXECMEM_BPF].start = BPF_JIT_REGION_START; + execmem_params.ranges[EXECMEM_BPF].end = BPF_JIT_REGION_END; return _params; } diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c index 2f08c14a933d..e64f2f3064eb 100644 --- a/arch/riscv/kernel/probes/kprobes.c +++ b/arch/riscv/kernel/probes/kprobes.c @@ -104,16 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p) return 0; } -#ifdef CONFIG_MMU -void *alloc_insn_page(void) -{ - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END, -GFP_KERNEL, PAGE_KERNEL_READ_EXEC, -VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, -__builtin_return_address(0)); -} -#endif - /* install breakpoint in text */ void __kprobes arch_arm_kprobe(struct kprobe *p) { diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c index 7b70ccb7fec3..c8a758f0882b 100644 --- a/arch/riscv/net/bpf_jit_core.c +++ b/arch/riscv/net/bpf_jit_core.c @@ -218,19 +218,6 @@ u64 bpf_jit_alloc_exec_limit(void) return BPF_JIT_REGION_SIZE; } -void *bpf_jit_alloc_exec(unsigned long size) -{ - return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START, - BPF_JIT_REGION_END, GFP_KERNEL, - PAGE_KERNEL, 0, NUMA_NO_NODE, - __builtin_return_address(0)); -} - -void bpf_jit_free_exec(void *addr) -{ - return vfree(addr); -} - void *bpf_arch_text_copy(void *dst, void *src, size_t len) { int ret; -- 2.39.2
[PATCH v3 07/13] arm64, execmem: extend execmem_params for generated code allocations
From: "Mike Rapoport (IBM)" The memory allocations for kprobes and BPF on arm64 can be placed anywhere in vmalloc address space and currently this is implemented with overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64. Define EXECMEM_KPROBES and EXECMEM_BPF ranges in arm64::execmem_params and drop overrides of alloc_insn_page() and bpf_jit_alloc_exec(). Signed-off-by: Mike Rapoport (IBM) --- arch/arm64/kernel/module.c | 13 + arch/arm64/kernel/probes/kprobes.c | 7 --- arch/arm64/net/bpf_jit_comp.c | 11 --- 3 files changed, 13 insertions(+), 18 deletions(-) diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index cd6320de1c54..d27db168d2a2 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -116,6 +116,16 @@ static struct execmem_params execmem_params __ro_after_init = { .flags = EXECMEM_KASAN_SHADOW, .alignment = MODULE_ALIGN, }, + [EXECMEM_KPROBES] = { + .start = VMALLOC_START, + .end = VMALLOC_END, + .alignment = 1, + }, + [EXECMEM_BPF] = { + .start = VMALLOC_START, + .end = VMALLOC_END, + .alignment = 1, + }, }, }; @@ -140,6 +150,9 @@ struct execmem_params __init *execmem_arch_params(void) r->end = module_plt_base + SZ_2G; } + execmem_params.ranges[EXECMEM_KPROBES].pgprot = PAGE_KERNEL_ROX; + execmem_params.ranges[EXECMEM_BPF].pgprot = PAGE_KERNEL; + return _params; } diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c index 70b91a8c6bb3..6fccedd02b2a 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -129,13 +129,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p) return 0; } -void *alloc_insn_page(void) -{ - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END, - GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS, - NUMA_NO_NODE, __builtin_return_address(0)); -} - /* arm kprobe: install breakpoint in text */ void __kprobes arch_arm_kprobe(struct kprobe *p) { diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c index 150d1c6543f7..3a7590f828d1 100644 --- a/arch/arm64/net/bpf_jit_comp.c +++ b/arch/arm64/net/bpf_jit_comp.c @@ -1687,17 +1687,6 @@ u64 bpf_jit_alloc_exec_limit(void) return VMALLOC_END - VMALLOC_START; } -void *bpf_jit_alloc_exec(unsigned long size) -{ - /* Memory is intended to be executable, reset the pointer tag. */ - return kasan_reset_tag(vmalloc(size)); -} - -void bpf_jit_free_exec(void *addr) -{ - return vfree(addr); -} - /* Indicate the JIT backend supports mixing bpf2bpf and tailcalls. */ bool bpf_jit_supports_subprog_tailcalls(void) { -- 2.39.2
[PATCH v3 06/13] 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 allow architectures to define address ranges for data allocations. Since currently this is only relevant for powerpc variants that use the VMALLOC address space for module data allocations, automatically reuse address ranges defined for text unless address range for data is explicitly defined by an architecture. With separation of code and data allocations, data sections of the modules are now mapped as PAGE_KERNEL rather than PAGE_KERNEL_EXEC which was a default on many architectures. Signed-off-by: Mike Rapoport (IBM) --- arch/powerpc/kernel/module.c | 12 include/linux/execmem.h | 19 +++ kernel/module/main.c | 15 +++ mm/execmem.c | 17 - 4 files changed, 50 insertions(+), 13 deletions(-) diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c index f4dd26f693a3..824d9541a310 100644 --- a/arch/powerpc/kernel/module.c +++ b/arch/powerpc/kernel/module.c @@ -95,6 +95,9 @@ static struct execmem_params execmem_params __ro_after_init = { [EXECMEM_DEFAULT] = { .alignment = 1, }, + [EXECMEM_MODULE_DATA] = { + .alignment = 1, + }, }, }; @@ -103,7 +106,12 @@ struct execmem_params __init *execmem_arch_params(void) pgprot_t prot = strict_module_rwx_enabled() ? PAGE_KERNEL : PAGE_KERNEL_EXEC; struct execmem_range *range = _params.ranges[EXECMEM_DEFAULT]; + /* +* BOOK3S_32 and 8xx define MODULES_VADDR for text allocations and +* allow allocating data in the entire vmalloc space +*/ #ifdef MODULES_VADDR + struct execmem_range *data = _params.ranges[EXECMEM_MODULE_DATA]; unsigned long limit = (unsigned long)_etext - SZ_32M; /* First try within 32M limit from _etext to avoid branch trampolines */ @@ -116,6 +124,10 @@ struct execmem_params __init *execmem_arch_params(void) range->start = MODULES_VADDR; range->end = MODULES_END; } + data->start = VMALLOC_START; + data->end = VMALLOC_END; + data->pgprot = PAGE_KERNEL; + data->alignment = 1; #else range->start = VMALLOC_START; range->end = VMALLOC_END; diff --git a/include/linux/execmem.h b/include/linux/execmem.h index 519bdfdca595..09d45ac786e9 100644 --- a/include/linux/execmem.h +++ b/include/linux/execmem.h @@ -29,6 +29,7 @@ * @EXECMEM_KPROBES: parameters for kprobes * @EXECMEM_FTRACE: parameters for ftrace * @EXECMEM_BPF: parameters for BPF + * @EXECMEM_MODULE_DATA: parameters for module data sections * @EXECMEM_TYPE_MAX: */ enum execmem_type { @@ -37,6 +38,7 @@ enum execmem_type { EXECMEM_KPROBES, EXECMEM_FTRACE, EXECMEM_BPF, + EXECMEM_MODULE_DATA, EXECMEM_TYPE_MAX, }; @@ -107,6 +109,23 @@ struct execmem_params *execmem_arch_params(void); */ void *execmem_text_alloc(enum execmem_type type, size_t size); +/** + * execmem_data_alloc - allocate memory for data coupled to code + * @type: type of the allocation + * @size: how many bytes of memory are required + * + * Allocates memory that will contain data coupled with executable code, + * like data sections in kernel modules. + * + * The memory will have protections defined by architecture. + * + * The allocated memory will reside in an area that does not impose + * restrictions on the addressing modes. + * + * Return: a pointer to the allocated memory or %NULL + */ +void *execmem_data_alloc(enum execmem_type type, size_t size); + /** * execmem_free - free executable memory * @ptr: pointer to the memory that should be freed diff --git a/kernel/module/main.c b/kernel/module/main.c index c4146bfcd0a7..2ae83a6abf66 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -1188,25 +1188,16 @@ void __weak module_arch_freeing_init(struct module *mod) { } -static bool mod_mem_use_vmalloc(enum mod_mem_type type) -{ - return IS_ENABLED(CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC) && - mod_mem_type_is_core_data(type); -} - static void *module_memory_alloc(unsigned int size, enum mod_mem_type type) { - if (mod_mem_use_vmalloc(type)) - return vzalloc(size); + if (mod_mem_type_is_data(type)) + return execmem_data_alloc(EXECMEM_MODULE_DATA, size); return execmem_text_alloc(EXECMEM_MODULE_TEXT, size); } static void module_memory_free(void *ptr, enum mod_mem_type type) { - if (mod_mem_use_vmalloc(type)) - vfree(ptr); - else - execmem_free(ptr); + execmem_free(ptr); } static
[PATCH v3 05/13] 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 architecture does not supply its specific parameters. With this, execmem_text_alloc() implements memory allocation in a way compatible with module_alloc() and can be used as a replacement for module_alloc(). Signed-off-by: Mike Rapoport (IBM) --- include/linux/execmem.h | 8 include/linux/moduleloader.h | 12 kernel/module/main.c | 7 --- mm/execmem.c | 12 4 files changed, 16 insertions(+), 23 deletions(-) diff --git a/include/linux/execmem.h b/include/linux/execmem.h index 806ad1a0088d..519bdfdca595 100644 --- a/include/linux/execmem.h +++ b/include/linux/execmem.h @@ -4,6 +4,14 @@ #include +#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ + !defined(CONFIG_KASAN_VMALLOC) +#include +#define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) +#else +#define MODULE_ALIGN PAGE_SIZE +#endif + /** * enum execmem_type - types of executable memory ranges * diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h index a23718aa2f4d..8c81f389117d 100644 --- a/include/linux/moduleloader.h +++ b/include/linux/moduleloader.h @@ -25,10 +25,6 @@ int module_frob_arch_sections(Elf_Ehdr *hdr, /* Additional bytes needed by arch in front of individual sections */ unsigned int arch_mod_section_prepend(struct module *mod, unsigned int section); -/* Allocator used for allocating struct module, core sections and init - sections. Returns NULL on failure. */ -void *module_alloc(unsigned long size); - /* Determines if the section name is an init section (that is only used during * module loading). */ @@ -118,12 +114,4 @@ void module_arch_cleanup(struct module *mod); /* Any cleanup before freeing mod->module_init */ void module_arch_freeing_init(struct module *mod); -#if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ - !defined(CONFIG_KASAN_VMALLOC) -#include -#define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT) -#else -#define MODULE_ALIGN PAGE_SIZE -#endif - #endif diff --git a/kernel/module/main.c b/kernel/module/main.c index 4ec982cc943c..c4146bfcd0a7 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -1601,13 +1601,6 @@ static void free_modinfo(struct module *mod) } } -void * __weak module_alloc(unsigned long size) -{ - return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, - GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, - NUMA_NO_NODE, __builtin_return_address(0)); -} - bool __weak module_init_section(const char *name) { return strstarts(name, ".init"); diff --git a/mm/execmem.c b/mm/execmem.c index a8c2f44d0133..abcbd07e05ac 100644 --- a/mm/execmem.c +++ b/mm/execmem.c @@ -55,9 +55,6 @@ static void *execmem_alloc(size_t size, struct execmem_range *range) void *execmem_text_alloc(enum execmem_type type, size_t size) { - if (!execmem_params.ranges[type].start) - return module_alloc(size); - return execmem_alloc(size, _params.ranges[type]); } @@ -111,8 +108,15 @@ void __init execmem_init(void) { struct execmem_params *p = execmem_arch_params(); - if (!p) + if (!p) { + p = _params; + p->ranges[EXECMEM_DEFAULT].start = VMALLOC_START; + p->ranges[EXECMEM_DEFAULT].end = VMALLOC_END; + p->ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL_EXEC; + p->ranges[EXECMEM_DEFAULT].alignment = 1; + return; + } if (!execmem_validate_params(p)) return; -- 2.39.2
[PATCH v3 04/13] 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 implementation of execmem_alloc() takes care of suppressing warnings when the initial allocation fails but there is a fallback range defined. Signed-off-by: Mike Rapoport (IBM) --- arch/arm/kernel/module.c | 38 - arch/arm64/kernel/module.c | 57 ++-- arch/powerpc/kernel/module.c | 52 ++--- arch/s390/kernel/module.c| 52 +++-- arch/x86/kernel/module.c | 64 +++- include/linux/execmem.h | 14 mm/execmem.c | 43 ++-- 7 files changed, 167 insertions(+), 153 deletions(-) diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c index e74d84f58b77..2c7651a2d84c 100644 --- a/arch/arm/kernel/module.c +++ b/arch/arm/kernel/module.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -34,23 +35,28 @@ #endif #ifdef CONFIG_MMU -void *module_alloc(unsigned long size) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .start = MODULES_VADDR, + .end = MODULES_END, + .alignment = 1, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) { - gfp_t gfp_mask = GFP_KERNEL; - void *p; - - /* Silence the initial allocation */ - if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS)) - gfp_mask |= __GFP_NOWARN; - - p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, - gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE, - __builtin_return_address(0)); - if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p) - return p; - return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, - GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE, - __builtin_return_address(0)); + struct execmem_range *r = _params.ranges[EXECMEM_DEFAULT]; + + r->pgprot = PAGE_KERNEL_EXEC; + + if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS)) { + r->fallback_start = VMALLOC_START; + r->fallback_end = VMALLOC_END; + } + + return _params; } #endif diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index dd851297596e..cd6320de1c54 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -108,46 +109,38 @@ static int __init module_init_limits(void) return 0; } -subsys_initcall(module_init_limits); -void *module_alloc(unsigned long size) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .flags = EXECMEM_KASAN_SHADOW, + .alignment = MODULE_ALIGN, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) { - void *p = NULL; + struct execmem_range *r = _params.ranges[EXECMEM_DEFAULT]; - /* -* Where possible, prefer to allocate within direct branch range of the -* kernel such that no PLTs are necessary. -*/ - if (module_direct_base) { - p = __vmalloc_node_range(size, MODULE_ALIGN, -module_direct_base, -module_direct_base + SZ_128M, -GFP_KERNEL | __GFP_NOWARN, -PAGE_KERNEL, 0, NUMA_NO_NODE, -__builtin_return_address(0)); - } + module_init_limits(); - if (!p && module_plt_base) { - p = __vmalloc_node_range(size, MODULE_ALIGN, -module_plt_base, -module_plt_base + SZ_2G, -GFP_KERNEL | __GFP_NOWARN, -PAGE_KERNEL, 0, NUMA_NO_NODE, -__builtin_return_address(0)); - } + r->pgprot = PAGE_KERNEL; - if (!p) { - pr_warn_ratelimited("%s: unable to allocate memory\n", - __func__); - } + if (module_direct_base) { + r->start = module_direct_base; + r->end = module_direct_base + SZ_128M; - if (p && (kasan_alloc_module_shadow(p, size, GFP_KERNEL) < 0)) { -
[PATCH v3 03/13] 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 provided by architectures. The architectures must fill execmem_params structure and implement execmem_arch_params() that returns a pointer to that structure. This way the execmem initialization won't be called from every architecture, but rather from a central place, namely initialization of the core memory management. The execmem provides execmem_text_alloc() API that wraps __vmalloc_node_range() with the parameters defined by the architectures. If an architecture does not implement execmem_arch_params(), execmem_text_alloc() will fall back to module_alloc(). The name execmem_text_alloc() emphasizes that the allocated memory is for executable code, the allocations of the associated data, like data sections of a module will use execmem_data_alloc() interface that will be added later. Signed-off-by: Mike Rapoport (IBM) --- arch/loongarch/kernel/module.c | 18 -- arch/mips/kernel/module.c | 19 +++--- arch/nios2/kernel/module.c | 19 +++--- arch/parisc/kernel/module.c| 23 +++- arch/riscv/kernel/module.c | 20 --- arch/sparc/kernel/module.c | 44 +++ include/linux/execmem.h| 44 +++ mm/execmem.c | 66 -- mm/mm_init.c | 2 ++ 9 files changed, 203 insertions(+), 52 deletions(-) diff --git a/arch/loongarch/kernel/module.c b/arch/loongarch/kernel/module.c index b8b86088b2dd..a1d8fe9796fa 100644 --- a/arch/loongarch/kernel/module.c +++ b/arch/loongarch/kernel/module.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include @@ -469,10 +470,21 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab, return 0; } -void *module_alloc(unsigned long size) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .pgprot = PAGE_KERNEL, + .alignment = 1, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) { - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, - GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE, __builtin_return_address(0)); + execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR; + execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END; + + return _params; } static void module_init_ftrace_plt(const Elf_Ehdr *hdr, diff --git a/arch/mips/kernel/module.c b/arch/mips/kernel/module.c index 0c936cbf20c5..1c959074b35f 100644 --- a/arch/mips/kernel/module.c +++ b/arch/mips/kernel/module.c @@ -20,6 +20,7 @@ #include #include #include +#include extern void jump_label_apply_nops(struct module *mod); @@ -33,11 +34,21 @@ static LIST_HEAD(dbe_list); static DEFINE_SPINLOCK(dbe_lock); #ifdef MODULE_START -void *module_alloc(unsigned long size) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .start = MODULE_START, + .end = MODULE_END, + .alignment = 1, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) { - return __vmalloc_node_range(size, 1, MODULE_START, MODULE_END, - GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE, - __builtin_return_address(0)); + execmem_params.ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL; + + return _params; } #endif diff --git a/arch/nios2/kernel/module.c b/arch/nios2/kernel/module.c index 9c97b7513853..5a8df4f9c04e 100644 --- a/arch/nios2/kernel/module.c +++ b/arch/nios2/kernel/module.c @@ -18,15 +18,24 @@ #include #include #include +#include #include -void *module_alloc(unsigned long size) +static struct execmem_params execmem_params __ro_after_init = { + .ranges = { + [EXECMEM_DEFAULT] = { + .start = MODULES_VADDR, + .end = MODULES_END, + .pgprot = PAGE_KERNEL_EXEC, + .alignment = 1, + }, + }, +}; + +struct execmem_params __init *execmem_arch_params(void) { - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, - GFP_KERNEL, PAGE_KERNEL_EXEC, - VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, - __builtin_return_address(0)); + return _params; } int apply_relocate_add(Elf32_Shdr *sechdrs, const char *strtab, diff --git
[PATCH v3 02/13] mm: introduce execmem_text_alloc() and execmem_free()
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 modules code. Several architectures override module_alloc() because of various constraints where the executable memory can be located and this causes additional obstacles for improvements of code allocation. Start splitting code allocation from modules by introducing execmem_text_alloc() and execmem_free() APIs. Initially, execmem_text_alloc() is a wrapper for module_alloc() and execmem_free() is a replacement of module_memfree() to allow updating all call sites to use the new APIs. Since architectures define different restrictions on placement, permissions, alignment and other parameters for memory that can be used by different subsystems that allocate executable memory, execmem_text_alloc() takes a type argument, that will be used to identify the calling subsystem and to allow architectures define parameters for ranges suitable for that subsystem. The name execmem_text_alloc() emphasizes that the allocated memory is for executable code, the allocations of the associated data, like data sections of a module will use execmem_data_alloc() interface that will be added later. Signed-off-by: Mike Rapoport (IBM) --- arch/powerpc/kernel/kprobes.c| 4 +-- arch/s390/kernel/ftrace.c| 4 +-- arch/s390/kernel/kprobes.c | 4 +-- arch/s390/kernel/module.c| 5 +-- arch/sparc/net/bpf_jit_comp_32.c | 8 ++--- arch/x86/kernel/ftrace.c | 6 ++-- arch/x86/kernel/kprobes/core.c | 4 +-- include/linux/execmem.h | 56 include/linux/moduleloader.h | 3 -- kernel/bpf/core.c| 6 ++-- kernel/kprobes.c | 8 ++--- kernel/module/Kconfig| 1 + kernel/module/main.c | 25 +- mm/Kconfig | 3 ++ mm/Makefile | 1 + mm/execmem.c | 26 +++ 16 files changed, 120 insertions(+), 44 deletions(-) create mode 100644 include/linux/execmem.h create mode 100644 mm/execmem.c diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c index b20ee72e873a..62228c7072a2 100644 --- a/arch/powerpc/kernel/kprobes.c +++ b/arch/powerpc/kernel/kprobes.c @@ -19,8 +19,8 @@ #include #include #include -#include #include +#include #include #include #include @@ -130,7 +130,7 @@ void *alloc_insn_page(void) { void *page; - page = module_alloc(PAGE_SIZE); + page = execmem_text_alloc(EXECMEM_KPROBES, PAGE_SIZE); if (!page) return NULL; diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c index c46381ea04ec..4052e10eb6a4 100644 --- a/arch/s390/kernel/ftrace.c +++ b/arch/s390/kernel/ftrace.c @@ -7,13 +7,13 @@ * Author(s): Martin Schwidefsky */ -#include #include #include #include #include #include #include +#include #include #include #include @@ -220,7 +220,7 @@ static int __init ftrace_plt_init(void) { const char *start, *end; - ftrace_plt = module_alloc(PAGE_SIZE); + ftrace_plt = execmem_text_alloc(EXECMEM_FTRACE, PAGE_SIZE); if (!ftrace_plt) panic("cannot allocate ftrace plt\n"); diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c index d4b863ed0aa7..48928460dcb9 100644 --- a/arch/s390/kernel/kprobes.c +++ b/arch/s390/kernel/kprobes.c @@ -9,7 +9,6 @@ #define pr_fmt(fmt) "kprobes: " fmt -#include #include #include #include @@ -21,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -38,7 +38,7 @@ void *alloc_insn_page(void) { void *page; - page = module_alloc(PAGE_SIZE); + page = execmem_text_alloc(EXECMEM_KPROBES, PAGE_SIZE); if (!page) return NULL; set_memory_rox((unsigned long)page, 1); diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c index 42215f9404af..db5561d0c233 100644 --- a/arch/s390/kernel/module.c +++ b/arch/s390/kernel/module.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include #include @@ -76,7 +77,7 @@ void *module_alloc(unsigned long size) #ifdef CONFIG_FUNCTION_TRACER void module_arch_cleanup(struct module *mod) { - module_memfree(mod->arch.trampolines_start); + execmem_free(mod->arch.trampolines_start); } #endif @@ -510,7 +511,7 @@ static int module_alloc_ftrace_hotpatch_trampolines(struct module *me, size = FTRACE_HOTPATCH_TRAMPOLINES_SIZE(s->sh_size); numpages = DIV_ROUND_UP(size, PAGE_SIZE); - start = module_alloc(numpages * PAGE_SIZE); + start = execmem_text_alloc(EXECMEM_FTRACE, numpages * PAGE_SIZE); if (!start)
[PATCH v3 01/13] 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 Acked-by: Dinh Nguyen Acked-by: Song Liu Signed-off-by: Mike Rapoport (IBM) --- arch/nios2/include/asm/pgtable.h | 5 - arch/nios2/kernel/module.c | 19 --- 2 files changed, 8 insertions(+), 16 deletions(-) diff --git a/arch/nios2/include/asm/pgtable.h b/arch/nios2/include/asm/pgtable.h index 5144506dfa69..d2fb42fb6db8 100644 --- a/arch/nios2/include/asm/pgtable.h +++ b/arch/nios2/include/asm/pgtable.h @@ -25,7 +25,10 @@ #include #define VMALLOC_START CONFIG_NIOS2_KERNEL_MMU_REGION_BASE -#define VMALLOC_END(CONFIG_NIOS2_KERNEL_REGION_BASE - 1) +#define VMALLOC_END(CONFIG_NIOS2_KERNEL_REGION_BASE - SZ_32M - 1) + +#define MODULES_VADDR (CONFIG_NIOS2_KERNEL_REGION_BASE - SZ_32M) +#define MODULES_END(CONFIG_NIOS2_KERNEL_REGION_BASE - 1) struct mm_struct; diff --git a/arch/nios2/kernel/module.c b/arch/nios2/kernel/module.c index 76e0a42d6e36..9c97b7513853 100644 --- a/arch/nios2/kernel/module.c +++ b/arch/nios2/kernel/module.c @@ -21,23 +21,12 @@ #include -/* - * Modules should NOT be allocated with kmalloc for (obvious) reasons. - * But we do it for now to avoid relocation issues. CALL26/PCREL26 cannot reach - * from 0x8000 (vmalloc area) to 0xc (kernel) (kmalloc returns - * addresses in 0xc000) - */ 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_region) -{ - kfree(module_region); + return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, + GFP_KERNEL, PAGE_KERNEL_EXEC, + VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, + __builtin_return_address(0)); } int apply_relocate_add(Elf32_Shdr *sechdrs, const char *strtab, -- 2.39.2
[PATCH v3 00/13] 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 modules code. Several architectures override module_alloc() because of various constraints where the executable memory can be located and this causes additional obstacles for improvements of code allocation. A centralized infrastructure for code allocation allows allocations of executable memory as ROX, and future optimizations such as caching large pages for better iTLB performance and providing sub-page allocations for users that only need small jit code snippets. Rick Edgecombe proposed perm_alloc extension to vmalloc [1] and Song Liu proposed execmem_alloc [2], but both these approaches were targeting BPF allocations and lacked the ground work to abstract executable allocations and split them from the modules core. Thomas Gleixner suggested to express module allocation restrictions and requirements as struct mod_alloc_type_params [3] that would define ranges, protections and other parameters for different types of allocations used by modules and following that suggestion Song separated allocations of different types in modules (commit ac3b43283923 ("module: replace module_layout with module_memory")) and posted "Type aware module allocator" set [4]. I liked the idea of parametrising code allocation requirements as a structure, but I believe the original proposal and Song's module allocator was too module centric, so I came up with these patches. This set splits code allocation from modules by introducing execmem_text_alloc(), execmem_data_alloc() and execmem_free(), APIs, replaces call sites of module_alloc() and module_memfree() with the new APIs and implements core text and related allocations in a central place. Instead of architecture specific overrides for module_alloc(), the architectures that require non-default behaviour for text allocation must fill execmem_alloc_params structure and implement execmem_arch_params() that returns a pointer to that structure. If an architecture does not implement execmem_arch_params(), the defaults compatible with the current modules::module_alloc() are used. Since architectures define different restrictions on placement, permissions, alignment and other parameters for memory that can be used by different subsystems that allocate executable memory, execmem APIs take a type argument, that will be used to identify the calling subsystem and to allow architectures to define parameters for ranges suitable for that subsystem. The new infrastructure allows decoupling of BPF, kprobes and ftrace from modules, and most importantly it paves the way for ROX allocations for executable memory. [1] https://lore.kernel.org/lkml/20201120202426.18009-1-rick.p.edgeco...@intel.com/ [2] https://lore.kernel.org/all/20221107223921.3451913-1-s...@kernel.org/ [3] https://lore.kernel.org/all/87v8mndy3y.ffs@tglx/ [4] https://lore.kernel.org/all/20230526051529.3387103-1-s...@kernel.org v3 changes: * add type parameter to execmem allocation APIs * remove BPF dependency on modules v2: https://lore.kernel.org/all/20230616085038.4121892-1-r...@kernel.org * Separate "module" and "others" allocations with execmem_text_alloc() and jit_text_alloc() * Drop ROX entablement on x86 * Add ack for nios2 changes, thanks Dinh Nguyen v1: https://lore.kernel.org/all/20230601101257.530867-1-r...@kernel.org Mike Rapoport (IBM) (13): nios2: define virtual address space for modules mm: introduce execmem_text_alloc() and execmem_free() mm/execmem, arch: convert simple overrides of module_alloc to execmem mm/execmem, arch: convert remaining overrides of module_alloc to execmem modules, execmem: drop module_alloc mm/execmem: introduce execmem_data_alloc() arm64, execmem: extend execmem_params for generated code allocations riscv: extend execmem_params for generated code allocations powerpc: extend execmem_params for kprobes allocations arch: make execmem setup available regardless of CONFIG_MODULES x86/ftrace: enable dynamic ftrace without CONFIG_MODULES kprobes: remove dependency on CONFIG_MODULES bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of arch/Kconfig | 2 +- arch/arm/kernel/module.c | 32 --- arch/arm/mm/init.c | 38 arch/arm64/kernel/module.c | 124 - arch/arm64/kernel/probes/kprobes.c | 7 -- arch/arm64/mm/init.c | 132 +++ arch/arm64/net/bpf_jit_comp.c | 11 --- arch/loongarch/kernel/module.c | 6 -- arch/loongarch/mm/init.c | 20 arch/mips/kernel/module.c | 10 +- arch/mips/mm/init.c| 20 arch/nios2/include/asm/pgtable.h | 5 +- arch/nios2/kernel/module.c
Re: [PATCH 18/26] KVM: s390: Stop adding virt/kvm to the arch include path
On 16/09/2023 02.31, Sean Christopherson wrote: Don't add virt/kvm to KVM s390's include path, the headers in virt/kvm are intended to be used only by other code in virt/kvm, i.e. are "private" to the core KVM code. It's not clear that s390 *ever* included a header from virt/kvm, i.e. odds are good the "-Ivirt/kvm" was copied from a x86's Makefile when s390 support was first added. The only headers in virt/kvm at the time were the x86 specific ioapic.h, and iodev.h, neither of which shows up as an #include in the diff for the commit range 37817f2982d0f..e976a2b997fc4. Signed-off-by: Sean Christopherson --- arch/s390/kvm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile index 02217fb4ae10..f17249ab2a72 100644 --- a/arch/s390/kvm/Makefile +++ b/arch/s390/kvm/Makefile @@ -5,7 +5,7 @@ include $(srctree)/virt/kvm/Makefile.kvm -ccflags-y := -Ivirt/kvm -Iarch/s390/kvm +ccflags-y := -Iarch/s390/kvm kvm-y += kvm-s390.o intercept.o interrupt.o priv.o sigp.o kvm-y += diag.o gaccess.o guestdbg.o vsie.o pv.o Reviewed-by: Thomas Huth