Skip to content
  1. Oct 24, 2022
    • Linus Torvalds's avatar
      Merge tag 'perf_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a7038524
      Linus Torvalds authored
      Pull perf fixes from Borislav Petkov:
      
       - Fix raw data handling when perf events are used in bpf
      
       - Rework how SIGTRAPs get delivered to events to address a bunch of
         problems with it. Add a selftest for that too
      
      * tag 'perf_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        bpf: Fix sample_flags for bpf_perf_event_output
        selftests/perf_events: Add a SIGTRAP stress test with disables
        perf: Fix missing SIGTRAPs
      a7038524
    • Linus Torvalds's avatar
      Merge tag 'sched_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · c70055d8
      Linus Torvalds authored
      Pull scheduler fixes from Borislav Petkov:
      
       - Adjust code to not trip up CFI
      
       - Fix sched group cookie matching
      
      * tag 'sched_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched: Introduce struct balance_callback to avoid CFI mismatches
        sched/core: Fix comparison in sched_group_cookie_match()
      c70055d8
    • Linus Torvalds's avatar
      Merge tag 'objtool_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 6204a81a
      Linus Torvalds authored
      Pull objtool fix from Borislav Petkov:
      
       - Fix ORC stack unwinding when GCOV is enabled
      
      * tag 'objtool_urgent_for_v6.1_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/unwind/orc: Fix unreliable stack dump with gcov
      6204a81a
    • Linus Torvalds's avatar
      Merge tag 'x86_urgent_for_v6.0_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 295dad10
      Linus Torvalds authored
      Pull x86 fixes from Borislav Petkov:
       "As usually the case, right after a major release, the tip urgent
        branches accumulate a couple more fixes than normal. And here is the
        x86, a bit bigger, urgent pile.
      
         - Use the correct CPU capability clearing function on the error path
           in Intel perf LBR
      
         - A CFI fix to ftrace along with a simplification
      
         - Adjust handling of zero capacity bit mask for resctrl cache
           allocation on AMD
      
         - A fix to the AMD microcode loader to attempt patch application on
           every logical thread
      
         - A couple of topology fixes to handle CPUID leaf 0x1f enumeration
           info properly
      
         - Drop a -mabi=ms compiler option check as both compilers support it
           now anyway
      
         - A couple of fixes to how the initial, statically allocated FPU
           buffer state is setup and its interaction with dynamic states at
           runtime"
      
      * tag 'x86_urgent_for_v6.0_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly
        perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap()
        ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()
        x86/ftrace: Remove ftrace_epilogue()
        x86/resctrl: Fix min_cbm_bits for AMD
        x86/microcode/AMD: Apply the patch early on every logical thread
        x86/topology: Fix duplicated core ID within a package
        x86/topology: Fix multiple packages shown on a single-package system
        hwmon/coretemp: Handle large core ID value
        x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB
        x86/fpu: Exclude dynamic states from init_fpstate
        x86/fpu: Fix the init_fpstate size check with the actual size
        x86/fpu: Configure init_fpstate attributes orderly
      295dad10
    • Linus Torvalds's avatar
      Merge tag 'io_uring-6.1-2022-10-22' of git://git.kernel.dk/linux · 942e01ab
      Linus Torvalds authored
      Pull io_uring follow-up from Jens Axboe:
       "Currently the zero-copy has automatic fallback to normal transmit, and
        it was decided that it'd be cleaner to return an error instead if the
        socket type doesn't support it.
      
        Zero-copy does work with UDP and TCP, it's more of a future proofing
        kind of thing (eg for samba)"
      
      * tag 'io_uring-6.1-2022-10-22' of git://git.kernel.dk/linux:
        io_uring/net: fail zc sendmsg when unsupported by socket
        io_uring/net: fail zc send when unsupported by socket
        net: flag sockets supporting msghdr originated zerocopy
      942e01ab
  2. Oct 23, 2022
    • Linus Torvalds's avatar
      Merge tag 'hwmon-for-v6.1-rc2' of... · d47136c2
      Linus Torvalds authored
      Merge tag 'hwmon-for-v6.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
      
      Pull hwmon fixes from Guenter Roeck:
      
       - corsair-psu: Fix typo in USB id description, and add USB ID for new
         PSU
      
       - pwm-fan: Fix fan power handling when disabling fan control
      
      * tag 'hwmon-for-v6.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: (corsair-psu) Add USB id of the new HX1500i psu
        hwmon: (pwm-fan) Explicitly switch off fan power when setting pwm1_enable to 0
        hwmon: (corsair-psu) fix typo in USB id description
      d47136c2
    • Linus Torvalds's avatar
      Merge tag 'i2c-for-6.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · cda5d920
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "RPM fix for qcom-cci, platform module alias for xiic, build warning
        fix for mlxbf, typo fixes in comments"
      
      * tag 'i2c-for-6.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: mlxbf: depend on ACPI; clean away ifdeffage
        i2c: fix spelling typos in comments
        i2c: qcom-cci: Fix ordering of pm_runtime_xx and i2c_add_adapter
        i2c: xiic: Add platform module alias
      cda5d920
    • Linus Torvalds's avatar
      Merge tag 'pci-v6.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · fd79882f
      Linus Torvalds authored
      Pull pci fixes from Bjorn Helgaas:
      
       - Revert a simplification that broke pci-tegra due to a masking error
      
       - Update MAINTAINERS for Kishon's email address change and TI
         DRA7XX/J721E maintainer change
      
      * tag 'pci-v6.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        MAINTAINERS: Update Kishon's email address in PCI endpoint subsystem
        MAINTAINERS: Add Vignesh Raghavendra as maintainer of TI DRA7XX/J721E PCI driver
        Revert "PCI: tegra: Use PCI_CONF1_EXT_ADDRESS() macro"
      fd79882f
    • Linus Torvalds's avatar
      Merge tag 'media/v6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 3272eb1a
      Linus Torvalds authored
      Pull missed media updates from Mauro Carvalho Chehab:
       "It seems I screwed-up my previous pull request: it ends up that only
        half of the media patches that were in linux-next got merged in -rc1.
      
        The script which creates the signed tags silently failed due to
        5.19->6.0 so it ended generating a tag with incomplete stuff.
      
        So here are the missing parts:
      
         - a DVB core security fix
      
         - lots of fixes and cleanups for atomisp staging driver
      
         - old drivers that are VB1 are being moved to staging to be
           deprecated
      
         - several driver updates - mostly for embedded systems, but there are
           also some things addressing issues with some PC webcams, in the UVC
           video driver"
      
      * tag 'media/v6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (163 commits)
        media: sun6i-csi: Move csi buffer definition to main header file
        media: sun6i-csi: Introduce and use video helper functions
        media: sun6i-csi: Add media ops with link notify callback
        media: sun6i-csi: Remove controls handler from the driver
        media: sun6i-csi: Register the media device after creation
        media: sun6i-csi: Pass and store csi device directly in video code
        media: sun6i-csi: Tidy up video code
        media: sun6i-csi: Tidy up v4l2 code
        media: sun6i-csi: Tidy up Kconfig
        media: sun6i-csi: Use runtime pm for clocks and reset
        media: sun6i-csi: Define and use variant to get module clock rate
        media: sun6i-csi: Always set exclusive module clock rate
        media: sun6i-csi: Tidy up platform code
        media: sun6i-csi: Refactor main driver data structures
        media: sun6i-csi: Define and use driver name and (reworked) description
        media: cedrus: Add a Kconfig dependency on RESET_CONTROLLER
        media: sun8i-rotate: Add a Kconfig dependency on RESET_CONTROLLER
        media: sun8i-di: Add a Kconfig dependency on RESET_CONTROLLER
        media: sun4i-csi: Add a Kconfig dependency on RESET_CONTROLLER
        media: sun6i-csi: Add a Kconfig dependency on RESET_CONTROLLER
        ...
      3272eb1a
  3. Oct 22, 2022
  4. Oct 21, 2022
    • Chen Zhongjin's avatar
      x86/unwind/orc: Fix unreliable stack dump with gcov · 230db824
      Chen Zhongjin authored
      
      
      When a console stack dump is initiated with CONFIG_GCOV_PROFILE_ALL
      enabled, show_trace_log_lvl() gets out of sync with the ORC unwinder,
      causing the stack trace to show all text addresses as unreliable:
      
        # echo l > /proc/sysrq-trigger
        [  477.521031] sysrq: Show backtrace of all active CPUs
        [  477.523813] NMI backtrace for cpu 0
        [  477.524492] CPU: 0 PID: 1021 Comm: bash Not tainted 6.0.0 #65
        [  477.525295] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014
        [  477.526439] Call Trace:
        [  477.526854]  <TASK>
        [  477.527216]  ? dump_stack_lvl+0xc7/0x114
        [  477.527801]  ? dump_stack+0x13/0x1f
        [  477.528331]  ? nmi_cpu_backtrace.cold+0xb5/0x10d
        [  477.528998]  ? lapic_can_unplug_cpu+0xa0/0xa0
        [  477.529641]  ? nmi_trigger_cpumask_backtrace+0x16a/0x1f0
        [  477.530393]  ? arch_trigger_cpumask_backtrace+0x1d/0x30
        [  477.531136]  ? sysrq_handle_showallcpus+0x1b/0x30
        [  477.531818]  ? __handle_sysrq.cold+0x4e/0x1ae
        [  477.532451]  ? write_sysrq_trigger+0x63/0x80
        [  477.533080]  ? proc_reg_write+0x92/0x110
        [  477.533663]  ? vfs_write+0x174/0x530
        [  477.534265]  ? handle_mm_fault+0x16f/0x500
        [  477.534940]  ? ksys_write+0x7b/0x170
        [  477.535543]  ? __x64_sys_write+0x1d/0x30
        [  477.536191]  ? do_syscall_64+0x6b/0x100
        [  477.536809]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
        [  477.537609]  </TASK>
      
      This happens when the compiled code for show_stack() has a single word
      on the stack, and doesn't use a tail call to show_stack_log_lvl().
      (CONFIG_GCOV_PROFILE_ALL=y is the only known case of this.)  Then the
      __unwind_start() skip logic hits an off-by-one bug and fails to unwind
      all the way to the intended starting frame.
      
      Fix it by reverting the following commit:
      
        f1d9a2ab ("x86/unwind/orc: Don't skip the first frame for inactive tasks")
      
      The original justification for that commit no longer exists.  That
      original issue was later fixed in a different way, with the following
      commit:
      
        f2ac57a4 ("x86/unwind/orc: Fix inactive tasks with stack pointer in %sp on GCC 10 compiled kernels")
      
      Fixes: f1d9a2ab ("x86/unwind/orc: Don't skip the first frame for inactive tasks")
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      [jpoimboe: rewrite commit log]
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@kernel.org>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      230db824
    • Ard Biesheuvel's avatar
      efi: runtime: Don't assume virtual mappings are missing if VA == PA == 0 · 37926f96
      Ard Biesheuvel authored
      
      
      The generic EFI stub can be instructed to avoid SetVirtualAddressMap(),
      and simply run with the firmware's 1:1 mapping. In this case, it
      populates the virtual address fields of the runtime regions in the
      memory map with the physical address of each region, so that the mapping
      code has to be none the wiser. Only if SetVirtualAddressMap() fails, the
      virtual addresses are wiped and the kernel code knows that the regions
      cannot be mapped.
      
      However, wiping amounts to setting it to zero, and if a runtime region
      happens to live at physical address 0, its valid 1:1 mapped virtual
      address could be mistaken for a wiped field, resulting on loss of access
      to the EFI services at runtime.
      
      So let's only assume that VA == 0 means 'no runtime services' if the
      region in question does not live at PA 0x0.
      
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      37926f96
    • Ard Biesheuvel's avatar
      efi: libstub: Fix incorrect payload size in zboot header · 53a7ea28
      Ard Biesheuvel authored
      
      
      The linker script symbol definition that captures the size of the
      compressed payload inside the zboot decompressor (which is exposed via
      the image header) refers to '.' for the end of the region, which does
      not give the correct result as the expression is not placed at the end
      of the payload. So use the symbol name explicitly.
      
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      53a7ea28
    • Ard Biesheuvel's avatar
      efi: libstub: Give efi_main() asmlinkage qualification · db14655a
      Ard Biesheuvel authored
      
      
      To stop the bots from sending sparse warnings to me and the list about
      efi_main() not having a prototype, decorate it with asmlinkage so that
      it is clear that it is called from assembly, and therefore needs to
      remain external, even if it is never declared in a header file.
      
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      db14655a
    • Ard Biesheuvel's avatar
      efi: efivars: Fix variable writes without query_variable_store() · 8a254d90
      Ard Biesheuvel authored
      
      
      Commit bbc6d2c6 ("efi: vars: Switch to new wrapper layer")
      refactored the efivars layer so that the 'business logic' related to
      which UEFI variables affect the boot flow in which way could be moved
      out of it, and into the efivarfs driver.
      
      This inadvertently broke setting variables on firmware implementations
      that lack the QueryVariableInfo() boot service, because we no longer
      tolerate a EFI_UNSUPPORTED result from check_var_size() when calling
      efivar_entry_set_get_size(), which now ends up calling check_var_size()
      a second time inadvertently.
      
      If QueryVariableInfo() is missing, we support writes of up to 64k -
      let's move that logic into check_var_size(), and drop the redundant
      call.
      
      Cc: <stable@vger.kernel.org> # v6.0
      Fixes: bbc6d2c6 ("efi: vars: Switch to new wrapper layer")
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      8a254d90
    • Ard Biesheuvel's avatar
      efi: ssdt: Don't free memory if ACPI table was loaded successfully · 4b017e59
      Ard Biesheuvel authored
      Amadeusz reports KASAN use-after-free errors introduced by commit
      3881ee0b ("efi: avoid efivars layer when loading SSDTs from
      variables"). The problem appears to be that the memory that holds the
      new ACPI table is now freed unconditionally, instead of only when the
      ACPI core reported a failure to load the table.
      
      So let's fix this, by omitting the kfree() on success.
      
      Cc: <stable@vger.kernel.org> # v6.0
      Link: https://lore.kernel.org/all/a101a10a-4fbb-5fae-2e3c-76cf96ed8fbd@linux.intel.com/
      
      
      Fixes: 3881ee0b ("efi: avoid efivars layer when loading SSDTs from variables")
      Reported-by: default avatarAmadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      4b017e59
    • Ard Biesheuvel's avatar
      efi: libstub: Remove zboot signing from build options · f57fb375
      Ard Biesheuvel authored
      
      
      The zboot decompressor series introduced a feature to sign the PE/COFF
      kernel image for secure boot as part of the kernel build. This was
      necessary because there are actually two images that need to be signed:
      the kernel with the EFI stub attached, and the decompressor application.
      
      This is a bit of a burden, because it means that the images must be
      signed on the the same system that performs the build, and this is not
      realistic for distros.
      
      During the next cycle, we will introduce changes to the zboot code so
      that the inner image no longer needs to be signed. This means that the
      outer PE/COFF image can be handled as usual, and be signed later in the
      release process.
      
      Let's remove the associated Kconfig options now so that they don't end
      up in a LTS release while already being deprecated.
      
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      f57fb375
    • Jerry Snitselaar's avatar
      iommu/vt-d: Clean up si_domain in the init_dmars() error path · 620bf9f9
      Jerry Snitselaar authored
      
      
      A splat from kmem_cache_destroy() was seen with a kernel prior to
      commit ee2653bb ("iommu/vt-d: Remove domain and devinfo mempool")
      when there was a failure in init_dmars(), because the iommu_domain
      cache still had objects. While the mempool code is now gone, there
      still is a leak of the si_domain memory if init_dmars() fails. So
      clean up si_domain in the init_dmars() error path.
      
      Cc: Lu Baolu <baolu.lu@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Fixes: 86080ccc ("iommu/vt-d: Allocate si_domain in init_dmars()")
      Signed-off-by: default avatarJerry Snitselaar <jsnitsel@redhat.com>
      Link: https://lore.kernel.org/r/20221010144842.308890-1-jsnitsel@redhat.com
      
      
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      620bf9f9
    • Charlotte Tan's avatar
      iommu/vt-d: Allow NVS regions in arch_rmrr_sanity_check() · 5566e68d
      Charlotte Tan authored
      arch_rmrr_sanity_check() warns if the RMRR is not covered by an ACPI
      Reserved region, but it seems like it should accept an NVS region as
      well. The ACPI spec
      https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html
      uses similar wording for "Reserved" and "NVS" region types; for NVS
      regions it says "This range of addresses is in use or reserved by the
      system and must not be used by the operating system."
      
      There is an old comment on this mailing list that also suggests NVS
      regions should pass the arch_rmrr_sanity_check() test:
      
       The warnings come from arch_rmrr_sanity_check() since it checks whether
       the region is E820_TYPE_RESERVED. However, if the purpose of the check
       is to detect RMRR has regions that may be used by OS as free memory,
       isn't  E820_TYPE_NVS safe, too?
      
      This patch overlaps with another proposed patch that would add the region
      type to the log since sometimes the bug reporter sees this log on the
      console but doesn't know to include the kernel log:
      
      https://lore.kernel.org/lkml/20220611204859.234975-3-atomlin@redhat.com/
      
      Here's an example of the "Firmware Bug" apparent false positive (wrapped
      for line length):
      
       DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR
             [0x000000006f760000-0x000000006f762fff], contact BIOS vendor for
             fixes
       DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR
             [0x000000006f760000-0x000000006f762fff]
      
      This is the snippet from the e820 table:
      
       BIOS-e820: [mem 0x0000000068bff000-0x000000006ebfefff] reserved
       BIOS-e820: [mem 0x000000006ebff000-0x000000006f9fefff] ACPI NVS
       BIOS-e820: [mem 0x000000006f9ff000-0x000000006fffefff] ACPI data
      
      Fixes: f036c7fa ("iommu/vt-d: Check VT-d RMRR region in BIOS is reported as reserved")
      Cc: Will Mortensen <will@extrahop.com>
      Link: https://lore.kernel.org/linux-iommu/64a5843d-850d-e58c-4fc2-0a0eeeb656dc@nec.com/
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216443
      
      
      Signed-off-by: default avatarCharlotte Tan <charlotte@extrahop.com>
      Reviewed-by: default avatarAaron Tomlin <atomlin@redhat.com>
      Link: https://lore.kernel.org/r/20220929044449.32515-1-charlotte@extrahop.com
      
      
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      5566e68d