1. 14 Aug, 2024 2 commits
  2. 12 Aug, 2024 7 commits
  3. 10 Aug, 2024 1 commit
  4. 05 Aug, 2024 17 commits
  5. 02 Aug, 2024 4 commits
  6. 01 Aug, 2024 1 commit
  7. 29 Jul, 2024 3 commits
  8. 04 Aug, 2024 5 commits
    • Linus Torvalds's avatar
      Linux 6.11-rc2 · de9c2c66
      Linus Torvalds authored
      de9c2c66
    • Tetsuo Handa's avatar
      profiling: remove profile=sleep support · b88f5538
      Tetsuo Handa authored
      The kernel sleep profile is no longer working due to a recursive locking
      bug introduced by commit 42a20f86 ("sched: Add wrapper for get_wchan()
      to keep task blocked")
      
      Booting with the 'profile=sleep' kernel command line option added or
      executing
      
        # echo -n sleep > /sys/kernel/profiling
      
      after boot causes the system to lock up.
      
      Lockdep reports
      
        kthreadd/3 is trying to acquire lock:
        ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: get_wchan+0x32/0x70
      
        but task is already holding lock:
        ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370
      
      with the call trace being
      
         lock_acquire+0xc8/0x2f0
         get_wchan+0x32/0x70
         __update_stats_enqueue_sleeper+0x151/0x430
         enqueue_entity+0x4b0/0x520
         enqueue_task_fair+0x92/0x6b0
         ttwu_do_activate+0x73/0x140
         try_to_wake_up+0x213/0x370
         swake_up_locked+0x20/0x50
         complete+0x2f/0x40
         kthread+0xfb/0x180
      
      However, since nobody noticed this regression for more than two years,
      let's remove 'profile=sleep' support based on the assumption that nobody
      needs this functionality.
      
      Fixes: 42a20f86 ("sched: Add wrapper for get_wchan() to keep task blocked")
      Cc: stable@vger.kernel.org # v5.16+
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b88f5538
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a5dbd76a
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
      
       - Prevent a deadlock on cpu_hotplug_lock in the aperf/mperf driver.
      
         A recent change in the ACPI code which consolidated code pathes moved
         the invocation of init_freq_invariance_cppc() to be moved to a CPU
         hotplug handler. The first invocation on AMD CPUs ends up enabling a
         static branch which dead locks because the static branch enable tries
         to acquire cpu_hotplug_lock but that lock is already held write by
         the hotplug machinery.
      
         Use static_branch_enable_cpuslocked() instead and take the hotplug
         lock read for the Intel code path which is invoked from the
         architecture code outside of the CPU hotplug operations.
      
       - Fix the number of reserved bits in the sev_config structure bit field
         so that the bitfield does not exceed 64 bit.
      
       - Add missing Zen5 model numbers
      
       - Fix the alignment assumptions of pti_clone_pgtable() and
         clone_entry_text() on 32-bit:
      
         The code assumes PMD aligned code sections, but on 32-bit the kernel
         entry text is not PMD aligned. So depending on the code size and
         location, which is configuration and compiler dependent, entry text
         can cross a PMD boundary. As the start is not PMD aligned adding PMD
         size to the start address is larger than the end address which
         results in partially mapped entry code for user space. That causes
         endless recursion on the first entry from userspace (usually #PF).
      
         Cure this by aligning the start address in the addition so it ends up
         at the next PMD start address.
      
         clone_entry_text() enforces PMD mapping, but on 32-bit the tail might
         eventually be PTE mapped, which causes a map fail because the PMD for
         the tail is not a large page mapping. Use PTI_LEVEL_KERNEL_IMAGE for
         the clone() invocation which resolves to PTE on 32-bit and PMD on
         64-bit.
      
       - Zero the 8-byte case for get_user() on range check failure on 32-bit
      
         The recend consolidation of the 8-byte get_user() case broke the
         zeroing in the failure case again. Establish it by clearing ECX
         before the range check and not afterwards as that obvioulsy can't be
         reached when the range check fails
      
      * tag 'x86-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/uaccess: Zero the 8-byte get_range case on failure on 32-bit
        x86/mm: Fix pti_clone_entry_text() for i386
        x86/mm: Fix pti_clone_pgtable() alignment assumption
        x86/setup: Parse the builtin command line before merging
        x86/CPU/AMD: Add models 0x60-0x6f to the Zen5 range
        x86/sev: Fix __reserved field in sev_config
        x86/aperfmperf: Fix deadlock on cpu_hotplug_lock
      a5dbd76a
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 61ca6c78
      Linus Torvalds authored
      Pull timer fixes from Thomas Gleixner:
       "Two fixes for the timer/clocksource code:
      
         - The recent fix to make the take over of the broadcast timer more
           reliable retrieves a per CPU pointer in preemptible context.
      
           This went unnoticed in testing as some compilers hoist the access
           into the non-preemotible section where the pointer is actually
           used, but obviously compilers can rightfully invoke it where the
           code put it.
      
           Move it into the non-preemptible section right to the actual usage
           side to cure it.
      
         - The clocksource watchdog is supposed to emit a warning when the
           retry count is greater than one and the number of retries reaches
           the limit.
      
           The condition is backwards and warns always when the count is
           greater than one. Fixup the condition to prevent spamming dmesg"
      
      * tag 'timers-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource: Fix brown-bag boolean thinko in cs_watchdog_read()
        tick/broadcast: Move per CPU pointer access into the atomic section
      61ca6c78
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 6cc82dc2
      Linus Torvalds authored
      Pull scheduler fixes from Thomas Gleixner:
      
       - When stime is larger than rtime due to accounting imprecision, then
         utime = rtime - stime becomes negative. As this is unsigned math, the
         result becomes a huge positive number.
      
         Cure it by resetting stime to rtime in that case, so utime becomes 0.
      
       - Restore consistent state when sched_cpu_deactivate() fails.
      
         When offlining a CPU fails in sched_cpu_deactivate() after the SMT
         present counter has been decremented, then the function aborts but
         fails to increment the SMT present counter and leaves it imbalanced.
         Consecutive operations cause it to underflow. Add the missing fixup
         for the error path.
      
         For SMT accounting the runqueue needs to marked online again in the
         error exit path to restore consistent state.
      
      * tag 'sched-urgent-2024-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/core: Fix unbalance set_rq_online/offline() in sched_cpu_deactivate()
        sched/core: Introduce sched_set_rq_on/offline() helper
        sched/smt: Fix unbalance sched_smt_present dec/inc
        sched/smt: Introduce sched_smt_present_inc/dec() helper
        sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime
      6cc82dc2