1. 27 Jan, 2023 1 commit
    • Mark Rutland's avatar
      arm64: avoid executing padding bytes during kexec / hibernation · dc4824fa
      Mark Rutland authored
      Currently we rely on the HIBERNATE_TEXT section starting with the entry
      point to swsusp_arch_suspend_exit, and the KEXEC_TEXT section starting
      with the entry point to arm64_relocate_new_kernel. In both cases we copy
      the entire section into a dynamically-allocated page, and then later
      branch to the start of this page.
      
      SYM_FUNC_START() will align the function entry points to
      CONFIG_FUNCTION_ALIGNMENT, and when the linker later processes the
      assembled code it will place padding bytes before the function entry
      point if the location counter was not already sufficiently aligned. The
      linker happens to use the value zero for these padding bytes.
      
      This padding may end up being applied whenever CONFIG_FUNCTION_ALIGNMENT
      is greater than 4, which can be the case with
      CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y or
      CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS=y.
      
      When such padding is applied, attempting to kexec or resume from
      hibernate will result ina crash: the kernel will branch to the padding
      bytes as the start of the dynamically-allocated page, and as those bytes
      are zero they will decode as UDF #0, which reliably triggers an
      UNDEFINED exception. For example:
      
      | # ./kexec --reuse-cmdline -f Image
      | [   46.965800] kexec_core: Starting new kernel
      | [   47.143641] psci: CPU1 killed (polled 0 ms)
      | [   47.233653] psci: CPU2 killed (polled 0 ms)
      | [   47.323465] psci: CPU3 killed (polled 0 ms)
      | [   47.324776] Bye!
      | [   47.327072] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
      | [   47.328510] Modules linked in:
      | [   47.329086] CPU: 0 PID: 259 Comm: kexec Not tainted 6.2.0-rc5+ #3
      | [   47.330223] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      | [   47.331497] pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      | [   47.332782] pc : 0x43a95000
      | [   47.333338] lr : machine_kexec+0x190/0x1e0
      | [   47.334169] sp : ffff80000d293b70
      | [   47.334845] x29: ffff80000d293b70 x28: ffff000002cc0000 x27: 0000000000000000
      | [   47.336292] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
      | [   47.337744] x23: ffff80000a837858 x22: 0000000048ec9000 x21: 0000000000000010
      | [   47.339192] x20: 00000000adc83000 x19: ffff000000827000 x18: 0000000000000006
      | [   47.340638] x17: ffff800075a61000 x16: ffff800008000000 x15: ffff80000d293658
      | [   47.342085] x14: 0000000000000000 x13: ffff80000d2937f7 x12: ffff80000a7ff6e0
      | [   47.343530] x11: 00000000ffffdfff x10: ffff80000a8ef8e0 x9 : ffff80000813ef00
      | [   47.344976] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 00000000000affa8
      | [   47.346431] x5 : 0000000000001fff x4 : 0000000000000001 x3 : ffff80000a0a3008
      | [   47.347877] x2 : ffff80000a8220f8 x1 : 0000000043a95000 x0 : ffff000000827000
      | [   47.349334] Call trace:
      | [   47.349834]  0x43a95000
      | [   47.350338]  kernel_kexec+0x88/0x100
      | [   47.351070]  __do_sys_reboot+0x108/0x268
      | [   47.351873]  __arm64_sys_reboot+0x2c/0x40
      | [   47.352689]  invoke_syscall+0x78/0x108
      | [   47.353458]  el0_svc_common.constprop.0+0x4c/0x100
      | [   47.354426]  do_el0_svc+0x34/0x50
      | [   47.355102]  el0_svc+0x34/0x108
      | [   47.355747]  el0t_64_sync_handler+0xf4/0x120
      | [   47.356617]  el0t_64_sync+0x194/0x198
      | [   47.357374] Code: bad PC value
      | [   47.357999] ---[ end trace 0000000000000000 ]---
      | [   47.358937] Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception
      | [   47.360515] Kernel Offset: disabled
      | [   47.361230] CPU features: 0x002000,00050108,c8004203
      | [   47.362232] Memory Limit: none
      
      Note: Unfortunately the code dump reports "bad PC value" as it attempts
      to dump some instructions prior to the UDF (i.e. before the start of the
      page), and terminates early upon a fault, obscuring the problem.
      
      This patch fixes this issue by aligning the section starter markes to
      CONFIG_FUNCTION_ALIGNMENT using the ALIGN_FUNCTION() helper, which
      ensures that the linker never needs to place padding bytes within the
      section. Assertions are added to verify each section begins with the
      function we expect, making our implicit requirement explicit.
      
      In future it might be nice to rework the kexec and hibernation code to
      decouple the section start from the entry point, but that involves much
      more significant changes that come with a higher risk of error, so I've
      tried to keep this fix as simple as possible for now.
      
      Fixes: 47a15aa5 ("arm64: Extend support for CONFIG_FUNCTION_ALIGNMENT")
      Reported-by: default avatarCKI Project <cki-project@redhat.com>
      Link: https://lore.kernel.org/linux-arm-kernel/29992.123012504212600261@us-mta-139.us.mimecast.lan/Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      dc4824fa
  2. 24 Jan, 2023 8 commits
    • Mark Rutland's avatar
      arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS · baaf553d
      Mark Rutland authored
      This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on arm64.
      This allows each ftrace callsite to provide an ftrace_ops to the common
      ftrace trampoline, allowing each callsite to invoke distinct tracer
      functions without the need to fall back to list processing or to
      allocate custom trampolines for each callsite. This significantly speeds
      up cases where multiple distinct trace functions are used and callsites
      are mostly traced by a single tracer.
      
      The main idea is to place a pointer to the ftrace_ops as a literal at a
      fixed offset from the function entry point, which can be recovered by
      the common ftrace trampoline. Using a 64-bit literal avoids branch range
      limitations, and permits the ops to be swapped atomically without
      special considerations that apply to code-patching. In future this will
      also allow for the implementation of DYNAMIC_FTRACE_WITH_DIRECT_CALLS
      without branch range limitations by using additional fields in struct
      ftrace_ops.
      
      As noted in the core patch adding support for
      DYNAMIC_FTRACE_WITH_CALL_OPS, this approach allows for directly invoking
      ftrace_ops::func even for ftrace_ops which are dynamically-allocated (or
      part of a module), without going via ftrace_ops_list_func.
      
      Currently, this approach is not compatible with CLANG_CFI, as the
      presence/absence of pre-function NOPs changes the offset of the
      pre-function type hash, and there's no existing mechanism to ensure a
      consistent offset for instrumented and uninstrumented functions. When
      CLANG_CFI is enabled, the existing scheme with a global ops->func
      pointer is used, and there should be no functional change. I am
      currently working with others to allow the two to work together in
      future (though this will liekly require updated compiler support).
      
      I've benchamrked this with the ftrace_ops sample module [1], which is
      not currently upstream, but available at:
      
        https://lore.kernel.org/lkml/20230103124912.2948963-1-mark.rutland@arm.com
        git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git ftrace-ops-sample-20230109
      
      Using that module I measured the total time taken for 100,000 calls to a
      trivial instrumented function, with a number of tracers enabled with
      relevant filters (which would apply to the instrumented function) and a
      number of tracers enabled with irrelevant filters (which would not apply
      to the instrumented function). I tested on an M1 MacBook Pro, running
      under a HVF-accelerated QEMU VM (i.e. on real hardware).
      
      Before this patch:
      
        Number of tracers     || Total time  | Per-call average time (ns)
        Relevant | Irrelevant || (ns)        | Total        | Overhead
        =========+============++=============+==============+============
               0 |          0 ||      94,583 |         0.95 |           -
               0 |          1 ||      93,709 |         0.94 |           -
               0 |          2 ||      93,666 |         0.94 |           -
               0 |         10 ||      93,709 |         0.94 |           -
               0 |        100 ||      93,792 |         0.94 |           -
        ---------+------------++-------------+--------------+------------
               1 |          1 ||   6,467,833 |        64.68 |       63.73
               1 |          2 ||   7,509,708 |        75.10 |       74.15
               1 |         10 ||  23,786,792 |       237.87 |      236.92
               1 |        100 || 106,432,500 |     1,064.43 |     1063.38
        ---------+------------++-------------+--------------+------------
               1 |          0 ||   1,431,875 |        14.32 |       13.37
               2 |          0 ||   6,456,334 |        64.56 |       63.62
              10 |          0 ||  22,717,000 |       227.17 |      226.22
             100 |          0 || 103,293,667 |      1032.94 |     1031.99
        ---------+------------++-------------+--------------+--------------
      
        Note: per-call overhead is estimated relative to the baseline case
        with 0 relevant tracers and 0 irrelevant tracers.
      
      After this patch
      
        Number of tracers     || Total time  | Per-call average time (ns)
        Relevant | Irrelevant || (ns)        | Total        | Overhead
        =========+============++=============+==============+============
               0 |          0 ||      94,541 |         0.95 |           -
               0 |          1 ||      93,666 |         0.94 |           -
               0 |          2 ||      93,709 |         0.94 |           -
               0 |         10 ||      93,667 |         0.94 |           -
               0 |        100 ||      93,792 |         0.94 |           -
        ---------+------------++-------------+--------------+------------
               1 |          1 ||     281,000 |         2.81 |        1.86
               1 |          2 ||     281,042 |         2.81 |        1.87
               1 |         10 ||     280,958 |         2.81 |        1.86
               1 |        100 ||     281,250 |         2.81 |        1.87
        ---------+------------++-------------+--------------+------------
               1 |          0 ||     280,959 |         2.81 |        1.86
               2 |          0 ||   6,502,708 |        65.03 |       64.08
              10 |          0 ||  18,681,209 |       186.81 |      185.87
             100 |          0 || 103,550,458 |     1,035.50 |     1034.56
        ---------+------------++-------------+--------------+------------
      
        Note: per-call overhead is estimated relative to the baseline case
        with 0 relevant tracers and 0 irrelevant tracers.
      
      As can be seen from the above:
      
      a) Whenever there is a single relevant tracer function associated with a
         tracee, the overhead of invoking the tracer is constant, and does not
         scale with the number of tracers which are *not* associated with that
         tracee.
      
      b) The overhead for a single relevant tracer has dropped to ~1/7 of the
         overhead prior to this series (from 13.37ns to 1.86ns). This is
         largely due to permitting calls to dynamically-allocated ftrace_ops
         without going through ftrace_ops_list_func.
      
      I've run the ftrace selftests from v6.2-rc3, which reports:
      
      | # of passed:  110
      | # of failed:  0
      | # of unresolved:  3
      | # of untested:  0
      | # of unsupported:  0
      | # of xfailed:  1
      | # of undefined(test bug):  0
      
      ... where the unresolved entries were the tests for DIRECT functions
      (which are not supported), and the checkbashisms selftest (which is
      irrelevant here):
      
      | [8] Test ftrace direct functions against tracers        [UNRESOLVED]
      | [9] Test ftrace direct functions against kprobes        [UNRESOLVED]
      | [62] Meta-selftest: Checkbashisms       [UNRESOLVED]
      
      ... with all other tests passing (or failing as expected).
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-9-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      baaf553d
    • Mark Rutland's avatar
      arm64: ftrace: Update stale comment · 90955d77
      Mark Rutland authored
      In commit:
      
        26299b3f ("ftrace: arm64: move from REGS to ARGS")
      
      ... we folded ftrace_regs_entry into ftrace_caller, and
      ftrace_regs_entry no longer exists.
      
      Update the comment accordingly.
      
      There should be no functional change as a result of this patch.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-8-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      90955d77
    • Mark Rutland's avatar
      arm64: patching: Add aarch64_insn_write_literal_u64() · e4ecbe83
      Mark Rutland authored
      In subsequent patches we'll need to atomically write to a
      naturally-aligned 64-bit literal embedded within the kernel text.
      
      Add a helper for this. For consistency with other text patching code we
      use copy_to_kernel_nofault(), which is atomic for naturally-aligned
      accesses up to 64-bits.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-7-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      e4ecbe83
    • Mark Rutland's avatar
      arm64: insn: Add helpers for BTI · 2bbbb401
      Mark Rutland authored
      In subsequent patches we'd like to check whether an instruction is a
      BTI. In preparation for this, add basic instruction helpers for BTI
      instructions.
      
      Per ARM DDI 0487H.a section C6.2.41, BTI is encoded in binary as
      follows, MSB to LSB:
      
        1101 0101 000 0011 0010 0100 xx01 1111
      
      Where the `xx` bits encode J/C/JC:
      
        00 : (omitted)
        01 : C
        10 : J
        11 : JC
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-6-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      2bbbb401
    • Mark Rutland's avatar
      arm64: Extend support for CONFIG_FUNCTION_ALIGNMENT · 47a15aa5
      Mark Rutland authored
      On arm64 we don't align assembly function in the same way as C
      functions. This somewhat limits the utility of
      CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B for testing, and adds noise when
      testing that we're correctly aligning functions as will be necessary for
      ftrace in subsequent patches.
      
      Follow the example of x86, and align assembly functions in the same way
      as C functions. Selecting FUNCTION_ALIGNMENT_4B ensures
      CONFIG_FUCTION_ALIGNMENT will be a minimum of 4 bytes, matching the
      minimum alignment that __ALIGN and __ALIGN_STR provide prior to this
      patch.
      
      I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
      building and booting a kernel, and looking for misaligned text symbols:
      
      Before, v6.2-rc3:
        # uname -rm
        6.2.0-rc3 aarch64
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
        5009
      
      Before, v6.2-rc3 + fixed __cold:
        # uname -rm
        6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
        919
      
      Before, v6.2-rc3 + fixed __cold + fixed ACPICA:
        # uname -rm
        6.2.0-rc3-00002-g267bddc38572 aarch64
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
        323
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
        0
      
      After:
        # uname -rm
        6.2.0-rc3-00003-g71db61ee3ea1 aarch64
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
        112
      
      Considering the remaining 112 unaligned text symbols:
      
      * 20 are non-function KVM NVHE assembly symbols, which are never
        instrumented by ftrace:
      
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep __kvm_nvhe | wc -l
        20
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep __kvm_nvhe
        ffffbe6483f73784 t __kvm_nvhe___invalid
        ffffbe6483f73788 t __kvm_nvhe___do_hyp_init
        ffffbe6483f73ab0 t __kvm_nvhe_reset
        ffffbe6483f73b8c T __kvm_nvhe___hyp_idmap_text_end
        ffffbe6483f73b8c T __kvm_nvhe___hyp_text_start
        ffffbe6483f77864 t __kvm_nvhe___host_enter_restore_full
        ffffbe6483f77874 t __kvm_nvhe___host_enter_for_panic
        ffffbe6483f778a4 t __kvm_nvhe___host_enter_without_restoring
        ffffbe6483f81178 T __kvm_nvhe___guest_exit_panic
        ffffbe6483f811c8 T __kvm_nvhe___guest_exit
        ffffbe6483f81354 t __kvm_nvhe_abort_guest_exit_start
        ffffbe6483f81358 t __kvm_nvhe_abort_guest_exit_end
        ffffbe6483f81830 t __kvm_nvhe_wa_epilogue
        ffffbe6483f81844 t __kvm_nvhe_el1_trap
        ffffbe6483f81864 t __kvm_nvhe_el1_fiq
        ffffbe6483f81864 t __kvm_nvhe_el1_irq
        ffffbe6483f81884 t __kvm_nvhe_el1_error
        ffffbe6483f818a4 t __kvm_nvhe_el2_sync
        ffffbe6483f81920 t __kvm_nvhe_el2_error
        ffffbe6483f865c8 T __kvm_nvhe___start___kvm_ex_table
      
      * 53 are position-independent functions only used during early boot, which are
        built with '-Os', but are never instrumented by ftrace:
      
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep __pi | wc -l
        53
      
        We *could* drop '-Os' when building these for consistency, but that is
        not necessary to ensure that ftrace works correctly.
      
      * The remaining 39 are non-function symbols, and 3 runtime BPF
        functions, which are never instrumented by ftrace:
      
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep -v __kvm_nvhe | grep -v __pi | wc -l
        39
        # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep -v __kvm_nvhe | grep -v __pi
        ffffbe6482e1009c T __irqentry_text_end
        ffffbe6482e10358 T __softirqentry_text_end
        ffffbe6482e1435c T __entry_text_end
        ffffbe6482e825f8 T __guest_exit_panic
        ffffbe6482e82648 T __guest_exit
        ffffbe6482e827d4 t abort_guest_exit_start
        ffffbe6482e827d8 t abort_guest_exit_end
        ffffbe6482e83030 t wa_epilogue
        ffffbe6482e83044 t el1_trap
        ffffbe6482e83064 t el1_fiq
        ffffbe6482e83064 t el1_irq
        ffffbe6482e83084 t el1_error
        ffffbe6482e830a4 t el2_sync
        ffffbe6482e83120 t el2_error
        ffffbe6482e93550 T sha256_block_neon
        ffffbe64830f3ae0 t e843419@01cc_00002a0c_3104
        ffffbe648378bd90 t e843419@09b3_0000d7cb_bc4
        ffffbe6483bdab20 t e843419@0c66_000116e2_34c8
        ffffbe6483f62c94 T __noinstr_text_end
        ffffbe6483f70a18 T __sched_text_end
        ffffbe6483f70b2c T __cpuidle_text_end
        ffffbe6483f722d4 T __lock_text_end
        ffffbe6483f73b8c T __hyp_idmap_text_end
        ffffbe6483f73b8c T __hyp_text_start
        ffffbe6483f865c8 T __start___kvm_ex_table
        ffffbe6483f870d0 t init_el1
        ffffbe6483f870f8 t init_el2
        ffffbe6483f87324 t pen
        ffffbe6483f87b48 T __idmap_text_end
        ffffbe64848eb010 T __hibernate_exit_text_start
        ffffbe64848eb124 T __hibernate_exit_text_end
        ffffbe64848eb124 T __relocate_new_kernel_start
        ffffbe64848eb260 T __relocate_new_kernel_end
        ffffbe648498a8e8 T _einittext
        ffffbe648498a8e8 T __exittext_begin
        ffffbe6484999d84 T __exittext_end
        ffff8000080756b4 t bpf_prog_6deef7357e7b4530    [bpf]
        ffff80000808dd78 t bpf_prog_6deef7357e7b4530    [bpf]
        ffff80000809d684 t bpf_prog_6deef7357e7b4530    [bpf]
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-5-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      47a15aa5
    • Mark Rutland's avatar
      ACPI: Don't build ACPICA with '-Os' · 8f9e0a52
      Mark Rutland authored
      The ACPICA code has been built with '-Os' since the beginning of git
      history, though there's no explanatory comment as to why.
      
      This is unfortunate as GCC drops the alignment specificed by
      '-falign-functions=N' when '-Os' is used, as reported in GCC bug 88345:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
      
      This prevents CONFIG_FUNCTION_ALIGNMENT and
      CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B from having their expected effect
      on the ACPICA code. This is doubly unfortunate as in subsequent patches
      arm64 will depend upon CONFIG_FUNCTION_ALIGNMENT for its ftrace
      implementation.
      
      Drop the '-Os' flag when building the ACPICA code. With this removed,
      the code builds cleanly and works correctly in testing so far.
      
      I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
      building and booting a kernel using ACPI, and looking for misaligned
      text symbols:
      
      * arm64:
      
        Before, v6.2-rc3:
          # uname -rm
          6.2.0-rc3 aarch64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          5009
      
        Before, v6.2-rc3 + fixed __cold:
          # uname -rm
          6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          919
      
        After:
          # uname -rm
          6.2.0-rc3-00002-g267bddc38572 aarch64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          323
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
          0
      
      * x86_64:
      
        Before, v6.2-rc3:
          # uname -rm
          6.2.0-rc3 x86_64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          11537
      
        Before, v6.2-rc3 + fixed __cold:
          # uname -rm
          6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          2805
      
        After:
          # uname -rm
          6.2.0-rc3-00002-g267bddc38572 x86_64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          1357
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
          0
      
      With the patch applied, the remaining unaligned text labels are a
      combination of static call trampolines and labels in assembly, which can
      be dealt with in subsequent patches.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Moore <robert.moore@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: linux-acpi@vger.kernel.org
      Link: https://lore.kernel.org/r/20230123134603.1064407-4-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      8f9e0a52
    • Mark Rutland's avatar
      Compiler attributes: GCC cold function alignment workarounds · c27cd083
      Mark Rutland authored
      Contemporary versions of GCC (e.g. GCC 12.2.0) drop the alignment
      specified by '-falign-functions=N' for functions marked with the
      __cold__ attribute, and potentially for callees of __cold__ functions as
      these may be implicitly marked as __cold__ by the compiler. LLVM appears
      to respect '-falign-functions=N' in such cases.
      
      This has been reported to GCC in bug 88345:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
      
      ... which also covers alignment being dropped when '-Os' is used, which
      will be addressed in a separate patch.
      
      Currently, use of '-falign-functions=N' is limited to
      CONFIG_FUNCTION_ALIGNMENT, which is largely used for performance and/or
      analysis reasons (e.g. with CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B), but
      isn't necessary for correct functionality. However, this dropped
      alignment isn't great for the performance and/or analysis cases.
      
      Subsequent patches will use CONFIG_FUNCTION_ALIGNMENT as part of arm64's
      ftrace implementation, which will require all instrumented functions to
      be aligned to at least 8-bytes.
      
      This patch works around the dropped alignment by avoiding the use of the
      __cold__ attribute when CONFIG_FUNCTION_ALIGNMENT is non-zero, and by
      specifically aligning abort(), which GCC implicitly marks as __cold__.
      As the __cold macro is now dependent upon config options (which is
      against the policy described at the top of compiler_attributes.h), it is
      moved into compiler_types.h.
      
      I've tested this by building and booting a kernel configured with
      defconfig + CONFIG_EXPERT=y + CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
      and looking for misaligned text symbols in /proc/kallsyms:
      
      * arm64:
      
        Before:
          # uname -rm
          6.2.0-rc3 aarch64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          5009
      
        After:
          # uname -rm
          6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          919
      
      * x86_64:
      
        Before:
          # uname -rm
          6.2.0-rc3 x86_64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          11537
      
        After:
          # uname -rm
          6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64
          # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
          2805
      
      There's clearly a substantial reduction in the number of misaligned
      symbols. From manual inspection, the remaining unaligned text labels are
      a combination of ACPICA functions (due to the use of '-Os'), static call
      trampolines, and non-function labels in assembly, which will be dealt
      with in subsequent patches.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Will Deacon <will@kernel.org>
      Cc: Miguel Ojeda <ojeda@kernel.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Link: https://lore.kernel.org/r/20230123134603.1064407-3-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      c27cd083
    • Mark Rutland's avatar
      ftrace: Add DYNAMIC_FTRACE_WITH_CALL_OPS · cbad0fb2
      Mark Rutland authored
      Architectures without dynamic ftrace trampolines incur an overhead when
      multiple ftrace_ops are enabled with distinct filters. in these cases,
      each call site calls a common trampoline which uses
      ftrace_ops_list_func() to iterate over all enabled ftrace functions, and
      so incurs an overhead relative to the size of this list (including RCU
      protection overhead).
      
      Architectures with dynamic ftrace trampolines avoid this overhead for
      call sites which have a single associated ftrace_ops. In these cases,
      the dynamic trampoline is customized to branch directly to the relevant
      ftrace function, avoiding the list overhead.
      
      On some architectures it's impractical and/or undesirable to implement
      dynamic ftrace trampolines. For example, arm64 has limited branch ranges
      and cannot always directly branch from a call site to an arbitrary
      address (e.g. from a kernel text address to an arbitrary module
      address). Calls from modules to core kernel text can be indirected via
      PLTs (allocated at module load time) to address this, but the same is
      not possible from calls from core kernel text.
      
      Using an indirect branch from a call site to an arbitrary trampoline is
      possible, but requires several more instructions in the function
      prologue (or immediately before it), and/or comes with far more complex
      requirements for patching.
      
      Instead, this patch adds a new option, where an architecture can
      associate each call site with a pointer to an ftrace_ops, placed at a
      fixed offset from the call site. A shared trampoline can recover this
      pointer and call ftrace_ops::func() without needing to go via
      ftrace_ops_list_func(), avoiding the associated overhead.
      
      This avoids issues with branch range limitations, and avoids the need to
      allocate and manipulate dynamic trampolines, making it far simpler to
      implement and maintain, while having similar performance
      characteristics.
      
      Note that this allows for dynamic ftrace_ops to be invoked directly from
      an architecture's ftrace_caller trampoline, whereas existing code forces
      the use of ftrace_ops_get_list_func(), which is in part necessary to
      permit the ftrace_ops to be freed once unregistered *and* to avoid
      branch/address-generation range limitation on some architectures (e.g.
      where ops->func is a module address, and may be outside of the direct
      branch range for callsites within the main kernel image).
      
      The CALL_OPS approach avoids this problems and is safe as:
      
      * The existing synchronization in ftrace_shutdown() using
        ftrace_shutdown() using synchronize_rcu_tasks_rude() (and
        synchronize_rcu_tasks()) ensures that no tasks hold a stale reference
        to an ftrace_ops (e.g. in the middle of the ftrace_caller trampoline,
        or while invoking ftrace_ops::func), when that ftrace_ops is
        unregistered.
      
        Arguably this could also be relied upon for the existing scheme,
        permitting dynamic ftrace_ops to be invoked directly when ops->func is
        in range, but this will require additional logic to handle branch
        range limitations, and is not handled by this patch.
      
      * Each callsite's ftrace_ops pointer literal can hold any valid kernel
        address, and is updated atomically. As an architecture's ftrace_caller
        trampoline will atomically load the ops pointer then dereference
        ops->func, there is no risk of invoking ops->func with a mismatches
        ops pointer, and updates to the ops pointer do not require special
        care.
      
      A subsequent patch will implement architectures support for arm64. There
      should be no functional change as a result of this patch alone.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Cc: Florent Revest <revest@chromium.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20230123134603.1064407-2-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      cbad0fb2
  3. 08 Jan, 2023 3 commits
  4. 07 Jan, 2023 6 commits
  5. 06 Jan, 2023 19 commits
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-2023-01-06' of git://anongit.freedesktop.org/drm/drm · 0a715535
      Linus Torvalds authored
      Pull drm fixes from Daniel Vetter:
       "Still not much, but more than last week. Dave should be back next week
        from the beaching.
      
        drivers:
         - i915-gvt fixes
         - amdgpu/kfd fixes
         - panfrost bo refcounting fix
         - meson afbc corruption fix
         - imx plane width fix
      
        core:
         - drm/sched fixes
         - drm/mm kunit test fix
         - dma-buf export error handling fixes"
      
      * tag 'drm-fixes-2023-01-06' of git://anongit.freedesktop.org/drm/drm:
        Revert "drm/amd/display: Enable Freesync Video Mode by default"
        drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
        drm/i915/gvt: use atomic operations to change the vGPU status
        drm/i915/gvt: fix vgpu debugfs clean in remove
        drm/i915/gvt: fix gvt debugfs destroy
        drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()
        drm/amd/display: Uninitialized variables causing 4k60 UCLK to stay at DPM1 and not DPM0
        drm/amdkfd: Fix kernel warning during topology setup
        drm/scheduler: Fix lockup in drm_sched_entity_kill()
        drm/imx: ipuv3-plane: Fix overlay plane width
        drm/scheduler: Fix lockup in drm_sched_entity_kill()
        drm/virtio: Fix memory leak in virtio_gpu_object_create()
        drm/meson: Reduce the FIFO lines held when AFBC is not used
        drm/tests: reduce drm_mm_test stack usage
        drm/panfrost: Fix GEM handle creation ref-counting
        drm/plane-helper: Add the missing declaration of drm_atomic_state
        dma-buf: fix dma_buf_export init order v2
      0a715535
    • Jason A. Donenfeld's avatar
      tpm: Allow system suspend to continue when TPM suspend fails · 1382999a
      Jason A. Donenfeld authored
      TPM 1 is sometimes broken across system suspends, due to races or
      locking issues or something else that haven't been diagnosed or fixed
      yet, most likely having to do with concurrent reads from the TPM's
      hardware random number generator driver. These issues prevent the system
      from actually suspending, with errors like:
      
        tpm tpm0: A TPM error (28) occurred continue selftest
        ...
        tpm tpm0: A TPM error (28) occurred attempting get random
        ...
        tpm tpm0: Error (28) sending savestate before suspend
        tpm_tis 00:08: PM: __pnp_bus_suspend(): tpm_pm_suspend+0x0/0x80 returns 28
        tpm_tis 00:08: PM: dpm_run_callback(): pnp_bus_suspend+0x0/0x10 returns 28
        tpm_tis 00:08: PM: failed to suspend: error 28
        PM: Some devices failed to suspend, or early wake event detected
      
      This issue was partially fixed by 23393c64 ("char: tpm: Protect
      tpm_pm_suspend with locks"), in a last minute 6.1 commit that Linus took
      directly because the TPM maintainers weren't available. However, it
      seems like this just addresses the most common cases of the bug, rather
      than addressing it entirely. So there are more things to fix still,
      apparently.
      
      In lieu of actually fixing the underlying bug, just allow system suspend
      to continue, so that laptops still go to sleep fine. Later, this can be
      reverted when the real bug is fixed.
      
      Link: https://lore.kernel.org/lkml/7cbe96cf-e0b5-ba63-d1b4-f63d2e826efa@suse.cz/
      Cc: stable@vger.kernel.org # 6.1+
      Reported-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarLuigi Semenzato <semenzato@chromium.org>
      Cc: Peter Huewe <peterhuewe@gmx.de>
      Cc: Jarkko Sakkinen <jarkko@kernel.org>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Johannes Altmanninger <aclopte@gmail.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1382999a
    • Linus Torvalds's avatar
      hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling · cb7a95af
      Linus Torvalds authored
      Commit 55d1cbbb ("hfs/hfsplus: use WARN_ON for sanity check") fixed
      a build warning by turning a comment into a WARN_ON(), but it turns out
      that syzbot then complains because it can trigger said warning with a
      corrupted hfs image.
      
      The warning actually does warn about a bad situation, but we are much
      better off just handling it as the error it is.  So rather than warn
      about us doing bad things, stop doing the bad things and return -EIO.
      
      While at it, also fix a memory leak that was introduced by an earlier
      fix for a similar syzbot warning situation, and add a check for one case
      that historically wasn't handled at all (ie neither comment nor
      subsequent WARN_ON).
      
      Reported-by: syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com
      Fixes: 55d1cbbb ("hfs/hfsplus: use WARN_ON for sanity check")
      Fixes: 8d824e69 ("hfs: fix OOB Read in __hfs_brec_find")
      Link: https://lore.kernel.org/lkml/000000000000dbce4e05f170f289@google.com/Tested-by: default avatarMichael Schmitz <schmitzmic@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Viacheslav Dubeyko <slava@dubeyko.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cb7a95af
    • Linus Torvalds's avatar
      Merge tag 'block-2023-01-06' of git://git.kernel.dk/linux · a689b938
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "The big change here is obviously the revert of the pktcdvd driver
        removal. Outside of that, just minor tweaks. In detail:
      
         - Re-instate the pktcdvd driver, which necessitates adding back
           bio_copy_data_iter() and the fops->devnode() hook for now (me)
      
         - Fix for splitting of a bio marked as NOWAIT, causing either nowait
           reads or writes to error with EAGAIN even if parts of the IO
           completed (me)
      
         - Fix for ublk, punting management commands to io-wq as they can all
           easily block for extended periods of time (Ming)
      
         - Removal of SRCU dependency for the block layer (Paul)"
      
      * tag 'block-2023-01-06' of git://git.kernel.dk/linux:
        block: Remove "select SRCU"
        Revert "pktcdvd: remove driver."
        Revert "block: remove devnode callback from struct block_device_operations"
        Revert "block: bio_copy_data_iter"
        ublk: honor IO_URING_F_NONBLOCK for handling control command
        block: don't allow splitting of a REQ_NOWAIT bio
        block: handle bio_split_to_limits() NULL return
      a689b938
    • Linus Torvalds's avatar
      Merge tag 'io_uring-2023-01-06' of git://git.kernel.dk/linux · ef1a4a77
      Linus Torvalds authored
      Pull io_uring fixes from Jens Axboe:
       "A few minor fixes that should go into the 6.2 release:
      
         - Fix for a memory leak in io-wq worker creation, if we ultimately
           end up canceling the worker creation before it gets created (me)
      
         - lockdep annotations for the CQ locking (Pavel)
      
         - A regression fix for CQ timeout handling (Pavel)
      
         - Ring pinning around deferred task_work fix (Pavel)
      
         - A trivial member move in struct io_ring_ctx, saving us some memory
           (me)"
      
      * tag 'io_uring-2023-01-06' of git://git.kernel.dk/linux:
        io_uring: fix CQ waiting timeout handling
        io_uring: move 'poll_multi_queue' bool in io_ring_ctx
        io_uring: lockdep annotate CQ locking
        io_uring: pin context while queueing deferred tw
        io_uring/io-wq: free worker if task_work creation is canceled
      ef1a4a77
    • Linus Torvalds's avatar
      Merge tag 'tif-notify-signal-2023-01-06' of git://git.kernel.dk/linux · 93387d49
      Linus Torvalds authored
      Pull arm TIF_NOTIFY_SIGNAL fixup from Jens Axboe:
       "Hui Tang reported a performance regressions with _TIF_WORK_MASK in
        newer kernels, which he tracked to a change that went into 5.11. After
        this change, we'll call do_work_pending() more often than we need to,
        because we're now testing bits 0..15 rather than just 0..7.
      
        Shuffle the bits around to avoid this"
      
      * tag 'tif-notify-signal-2023-01-06' of git://git.kernel.dk/linux:
        ARM: renumber bits related to _TIF_WORK_MASK
      93387d49
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-6.2-rc3' of https://github.com/ceph/ceph-client · 5c1a712f
      Linus Torvalds authored
      Pull ceph fixes from Ilya Dryomov:
       "Two file locking fixes from Xiubo"
      
      * tag 'ceph-for-6.2-rc3' of https://github.com/ceph/ceph-client:
        ceph: avoid use-after-free in ceph_fl_release_lock()
        ceph: switch to vfs_inode_has_locks() to fix file lock bug
      5c1a712f
    • Linus Torvalds's avatar
      Merge tag 'fixes_for_v6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs · 7b8c854c
      Linus Torvalds authored
      Pull UDF fixes from Jan Kara:
       "Two fixups of the UDF changes that went into 6.2-rc1"
      
      * tag 'fixes_for_v6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
        udf: initialize newblock to 0
        udf: Fix extension of the last extent in the file
      7b8c854c
    • Linus Torvalds's avatar
      Merge tag 'for-6.2-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux · fc7b76c4
      Linus Torvalds authored
      Pull btrfs fixes from David Sterba:
       "A few more regression and regular fixes:
      
         - regressions:
             - fix assertion condition using = instead of ==
             - fix false alert on bad tree level check
             - fix off-by-one error in delalloc search during lseek
      
         - fix compat ro feature check at read-write remount
      
         - handle case when read-repair happens with ongoing device replace
      
         - updated error messages"
      
      * tag 'for-6.2-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
        btrfs: fix compat_ro checks against remount
        btrfs: always report error in run_one_delayed_ref()
        btrfs: handle case when repair happens with dev-replace
        btrfs: fix off-by-one in delalloc search during lseek
        btrfs: fix false alert on bad tree level check
        btrfs: add error message for metadata level mismatch
        btrfs: fix ASSERT em->len condition in btrfs_get_extent
      fc7b76c4
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · a389e546
      Linus Torvalds authored
      Pull RISC-V fixes from Palmer Dabbelt:
      
       - use the correct mask for c.jr/c.jalr when decoding instructions
      
       - build fix for get_user() to avoid a sparse warning
      
      * tag 'riscv-for-linus-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        riscv: uaccess: fix type of 0 variable on error in get_user()
        riscv, kprobes: Stricter c.jr/c.jalr decoding
      a389e546
    • Linus Torvalds's avatar
      Merge tag 'perf-tools-fixes-for-v6.2-1-2023-01-06' of... · 56f81458
      Linus Torvalds authored
      Merge tag 'perf-tools-fixes-for-v6.2-1-2023-01-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
      
      Pull perf tools fixes from Arnaldo Carvalho de Melo:
      
       - Fix segfault when trying to process tracepoints present in a
         perf.data file and not linked with libtraceevent.
      
       - Fix build on uClibc systems by adding missing sys/types.h include,
         that was being obtained indirectly which stopped being the case when
         tools/lib/traceevent was removed.
      
       - Don't show commands in 'perf help' that depend on linking with
         libtraceevent when not building with that library, which is now a
         possibility since we no longer ship a copy in tools/lib/traceevent.
      
       - Fix failure in 'perf test' entry testing the combination of 'perf
         probe' user space function + 'perf record' + 'perf script' where it
         expects a backtrace leading to glibc's inet_pton() from 'ping' that
         now happens more than once with glibc 2.35 for IPv6 addreses.
      
       - Fix for the inet_pton perf test on s/390 where
         'text_to_binary_address' now appears on the backtrace.
      
       - Fix build error on riscv due to missing header for 'struct
         perf_sample'.
      
       - Fix 'make -C tools perf_install' install variant by not propagating
         the 'subdir' to submakes for the 'install_headers' targets.
      
       - Fix handling of unsupported cgroup events when using BPF counters in
         'perf stat'.
      
       - Count all cgroups, not just the last one when using 'perf stat' and
         combining --for-each-cgroup with --bpf-counters.
      
         This makes the output using BPF counters match the output without
         using it, which was the intention all along, the output should be the
         same using --bpf-counters or not.
      
       - Fix 'perf lock contention' core dump related to not finding the
         "__sched_text_end" symbol on s/390.
      
       - Fix build failure when HEAD is signed: exclude the signature from the
         version string.
      
       - Add missing closedir() calls to in perf_data__open_dir(), plugging a
         fd leak.
      
      * tag 'perf-tools-fixes-for-v6.2-1-2023-01-06' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
        perf tools: Fix build on uClibc systems by adding missing sys/types.h include
        perf stat: Fix handling of --for-each-cgroup with --bpf-counters to match non BPF mode
        perf stat: Fix handling of unsupported cgroup events when using BPF counters
        perf test record_probe_libc_inet_pton: Fix test on s/390 where 'text_to_binary_address' now appears on the backtrace
        perf lock contention: Fix core dump related to not finding the "__sched_text_end" symbol on s/390
        perf build: Don't propagate subdir to submakes for install_headers
        perf test record_probe_libc_inet_pton: Fix failure due to extra inet_pton() backtrace in glibc >= 2.35
        perf tools: Fix segfault when trying to process tracepoints in perf.data and not linked with libtraceevent
        perf tools: Don't include signature in version strings
        perf help: Use HAVE_LIBTRACEEVENT to filter out unsupported commands
        perf tools riscv: Fix build error on riscv due to missing header for 'struct perf_sample'
        perf tools: Fix resources leak in perf_data__open_dir()
      56f81458
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2023-01-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d7a0853d
      Linus Torvalds authored
      Pull perf fix from Ingo Molnar:
       "Intel RAPL updates for new model IDs"
      
      * tag 'perf-urgent-2023-01-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/x86/rapl: Add support for Intel Emerald Rapids
        perf/x86/rapl: Add support for Intel Meteor Lake
        perf/x86/rapl: Treat Tigerlake like Icelake
      d7a0853d
    • Linus Torvalds's avatar
      Merge tag 'v6.2-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 90bc52c5
      Linus Torvalds authored
      Pull crypto fixes from Herbert Xu:
       "This fixes a CFI crash in arm64/sm4 as well as a regression in the
        caam driver"
      
      * tag 'v6.2-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: arm64/sm4 - fix possible crash with CFI enabled
        crypto: caam - fix CAAM io mem access in blob_gen
      90bc52c5
    • Thinh Nguyen's avatar
      usb: dwc3: gadget: Ignore End Transfer delay on teardown · c4e3ef56
      Thinh Nguyen authored
      If we delay sending End Transfer for Setup TRB to be prepared, we need
      to check if the End Transfer was in preparation for a driver
      teardown/soft-disconnect. In those cases, just send the End Transfer
      command without delay.
      
      In the case of soft-disconnect, there's a very small chance the command
      may not go through immediately. But should it happen, the Setup TRB will
      be prepared during the polling of the controller halted state, allowing
      the command to go through then.
      
      In the case of disabling endpoint due to reconfiguration (e.g.
      set_interface(alt-setting) or usb reset), then it's driven by the host.
      Typically the host wouldn't immediately cancel the control request and
      send another control transfer to trigger the End Transfer command
      timeout.
      
      Fixes: 4db0fbb6 ("usb: dwc3: gadget: Don't delay End Transfer on delayed_status")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThinh Nguyen <Thinh.Nguyen@synopsys.com>
      Link: https://lore.kernel.org/r/f1617a323e190b9cc408fb8b65456e32b5814113.1670546756.git.Thinh.Nguyen@synopsys.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4e3ef56
    • Arnd Bergmann's avatar
      usb: dwc3: xilinx: include linux/gpio/consumer.h · e498a044
      Arnd Bergmann authored
      The newly added gpio consumer calls cause a build failure in configurations
      that fail to include the right header implicitly:
      
      drivers/usb/dwc3/dwc3-xilinx.c: In function 'dwc3_xlnx_init_zynqmp':
      drivers/usb/dwc3/dwc3-xilinx.c:207:22: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_clk_get_optional'? [-Werror=implicit-function-declaration]
        207 |         reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
            |                      ^~~~~~~~~~~~~~~~~~~~~~~
            |                      devm_clk_get_optional
      
      Fixes: ca05b382 ("usb: dwc3: xilinx: Add gpio-reset support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20230103121755.956027-1-arnd@kernel.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e498a044
    • Tom Rix's avatar
      udf: initialize newblock to 0 · 23970a1c
      Tom Rix authored
      The clang build reports this error
      fs/udf/inode.c:805:6: error: variable 'newblock' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
              if (*err < 0)
                  ^~~~~~~~
      newblock is never set before error handling jump.
      Initialize newblock to 0 and remove redundant settings.
      
      Fixes: d8b39db5fab8 ("udf: Handle error when adding extent to a file")
      Reported-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarTom Rix <trix@redhat.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Message-Id: <20221230175341.1629734-1-trix@redhat.com>
      23970a1c
    • Jan Kara's avatar
      udf: Fix extension of the last extent in the file · 83c7423d
      Jan Kara authored
      When extending the last extent in the file within the last block, we
      wrongly computed the length of the last extent. This is mostly a
      cosmetical problem since the extent does not contain any data and the
      length will be fixed up by following operations but still.
      
      Fixes: 1f3868f0 ("udf: Fix extending file within last block")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      83c7423d
    • Daniel Vetter's avatar
      Merge tag 'drm-intel-fixes-2023-01-05' of... · 5193326c
      Daniel Vetter authored
      Merge tag 'drm-intel-fixes-2023-01-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      Only gvt-fixes:
           - debugfs fixes (Zhenyu)
           - fix up for vgpu status (Zhi)
           - double free fix in split_2MB_gtt_entry (Zheng)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      From: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/Y7cszBkLRvAy6uao@intel.com
      5193326c
    • Yang Yingliang's avatar
      usb: fotg210-udc: fix error return code in fotg210_udc_probe() · 1a5a23b9
      Yang Yingliang authored
      After commit  5f217ccd ("fotg210-udc: Support optional external PHY"),
      the error code is re-assigned to 0 in fotg210_udc_probe(), if allocate or
      map memory fails after the assignment, it can't return an error code. Set
      the error code to -ENOMEM to fix this problem.
      
      Fixes: 5f217ccd ("fotg210-udc: Support optional external PHY")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20221230065427.944586-1-yangyingliang@huawei.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a5a23b9
  6. 05 Jan, 2023 3 commits
    • Linus Torvalds's avatar
      Merge tag 'thermal-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 1f5abbd7
      Linus Torvalds authored
      Pull thermal control fix from Rafael Wysocki:
       "Add a missing sysfs attribute to the int340x thermal driver (Srinivas
        Pandruvada)"
      
      * tag 'thermal-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        thermal: int340x: Add missing attribute for data rate base
      1f5abbd7
    • Linus Torvalds's avatar
      Merge tag 'net-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 50011c32
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from bpf, wifi, and netfilter.
      
        Current release - regressions:
      
         - bpf: fix nullness propagation for reg to reg comparisons, avoid
           null-deref
      
         - inet: control sockets should not use current thread task_frag
      
         - bpf: always use maximal size for copy_array()
      
         - eth: bnxt_en: don't link netdev to a devlink port for VFs
      
        Current release - new code bugs:
      
         - rxrpc: fix a couple of potential use-after-frees
      
         - netfilter: conntrack: fix IPv6 exthdr error check
      
         - wifi: iwlwifi: fw: skip PPAG for JF, avoid FW crashes
      
         - eth: dsa: qca8k: various fixes for the in-band register access
      
         - eth: nfp: fix schedule in atomic context when sync mc address
      
         - eth: renesas: rswitch: fix getting mac address from device tree
      
         - mobile: ipa: use proper endpoint mask for suspend
      
        Previous releases - regressions:
      
         - tcp: add TIME_WAIT sockets in bhash2, fix regression caught by
           Jiri / python tests
      
         - net: tc: don't intepret cls results when asked to drop, fix
           oob-access
      
         - vrf: determine the dst using the original ifindex for multicast
      
         - eth: bnxt_en:
            - fix XDP RX path if BPF adjusted packet length
            - fix HDS (header placement) and jumbo thresholds for RX packets
      
         - eth: ice: xsk: do not use xdp_return_frame() on tx_buf->raw_buf,
           avoid memory corruptions
      
        Previous releases - always broken:
      
         - ulp: prevent ULP without clone op from entering the LISTEN status
      
         - veth: fix race with AF_XDP exposing old or uninitialized
           descriptors
      
         - bpf:
            - pull before calling skb_postpull_rcsum() (fix checksum support
              and avoid a WARN())
            - fix panic due to wrong pageattr of im->image (when livepatch and
              kretfunc coexist)
            - keep a reference to the mm, in case the task is dead
      
         - mptcp: fix deadlock in fastopen error path
      
         - netfilter:
            - nf_tables: perform type checking for existing sets
            - nf_tables: honor set timeout and garbage collection updates
            - ipset: fix hash:net,port,net hang with /0 subnet
            - ipset: avoid hung task warning when adding/deleting entries
      
         - selftests: net:
            - fix cmsg_so_mark.sh test hang on non-x86 systems
            - fix the arp_ndisc_evict_nocarrier test for IPv6
      
         - usb: rndis_host: secure rndis_query check against int overflow
      
         - eth: r8169: fix dmar pte write access during suspend/resume with
           WOL
      
         - eth: lan966x: fix configuration of the PCS
      
         - eth: sparx5: fix reading of the MAC address
      
         - eth: qed: allow sleep in qed_mcp_trace_dump()
      
         - eth: hns3:
            - fix interrupts re-initialization after VF FLR
            - fix handling of promisc when MAC addr table gets full
            - refine the handling for VF heartbeat
      
         - eth: mlx5:
            - properly handle ingress QinQ-tagged packets on VST
            - fix io_eq_size and event_eq_size params validation on big endian
            - fix RoCE setting at HCA level if not supported at all
            - don't turn CQE compression on by default for IPoIB
      
         - eth: ena:
            - fix toeplitz initial hash key value
            - account for the number of XDP-processed bytes in interface stats
            - fix rx_copybreak value update
      
        Misc:
      
         - ethtool: harden phy stat handling against buggy drivers
      
         - docs: netdev: convert maintainer's doc from FAQ to a normal
           document"
      
      * tag 'net-6.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (112 commits)
        caif: fix memory leak in cfctrl_linkup_request()
        inet: control sockets should not use current thread task_frag
        net/ulp: prevent ULP without clone op from entering the LISTEN status
        qed: allow sleep in qed_mcp_trace_dump()
        MAINTAINERS: Update maintainers for ptp_vmw driver
        usb: rndis_host: Secure rndis_query check against int overflow
        net: dpaa: Fix dtsec check for PCS availability
        octeontx2-pf: Fix lmtst ID used in aura free
        drivers/net/bonding/bond_3ad: return when there's no aggregator
        netfilter: ipset: Rework long task execution when adding/deleting entries
        netfilter: ipset: fix hash:net,port,net hang with /0 subnet
        net: sparx5: Fix reading of the MAC address
        vxlan: Fix memory leaks in error path
        net: sched: htb: fix htb_classify() kernel-doc
        net: sched: cbq: dont intepret cls results when asked to drop
        net: sched: atm: dont intepret cls results when asked to drop
        dt-bindings: net: marvell,orion-mdio: Fix examples
        dt-bindings: net: sun8i-emac: Add phy-supply property
        net: ipa: use proper endpoint mask for suspend
        selftests: net: return non-zero for failures reported in arp_ndisc_evict_nocarrier
        ...
      50011c32
    • Ben Dooks's avatar
      riscv: uaccess: fix type of 0 variable on error in get_user() · b9b916ae
      Ben Dooks authored
      If the get_user(x, ptr) has x as a pointer, then the setting
      of (x) = 0 is going to produce the following sparse warning,
      so fix this by forcing the type of 'x' when access_ok() fails.
      
      fs/aio.c:2073:21: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Reviewed-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Link: https://lore.kernel.org/r/20221229170545.718264-1-ben-linux@fluff.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      b9b916ae