qiurui/Centos-kernel-stream-9
1
0
Fork 0
mirror of https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git synced 2026-09-09 00:08:12 +08:00
Code Issues Packages Projects Releases Wiki Activity
1,198,313 Commits 5 Branches 2,299 Tags
main
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Herton R. Krzesinski 9239f8e4e4 sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting 
JIRA: https://issues.redhat.com/browse/RHEL-157267

Conflicts: rhel-9 does not have the change "sched: Employ sched_change
           guards". As such, I changed __setscheduler_dl_pi to use
           queue_flags instead of *scope. This was not suggested or
           implemented by patchpal/AI, I did it manually.

commit d658686a1331db3bb108ca079d76deb3208ed949
Author: Juri Lelli <juri.lelli@redhat.com>
Date:   Mon Mar 2 16:45:40 2026 +0100

    sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting

    Running stress-ng --schedpolicy 0 on an RT kernel on a big machine
    might lead to the following WARNINGs (edited).

     sched: DL de-boosted task PID 22725: REPLENISH flag missing

     WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8
     ... (running_bw underflow)
     Call trace:
      dequeue_task_dl+0x15c/0x1f8 (P)
      dequeue_task+0x80/0x168
      deactivate_task+0x24/0x50
      push_dl_task+0x264/0x2e0
      dl_task_timer+0x1b0/0x228
      __hrtimer_run_queues+0x188/0x378
      hrtimer_interrupt+0xfc/0x260
      ...

    The problem is that when a SCHED_DEADLINE task (lock holder) is
    changed to a lower priority class via sched_setscheduler(), it may
    fail to properly inherit the parameters of potential DEADLINE donors
    if it didn't already inherit them in the past (shorter deadline than
    donor's at that time). This might lead to bandwidth accounting
    corruption, as enqueue_task_dl() won't recognize the lock holder as
    boosted.

    The scenario occurs when:
    1. A DEADLINE task (donor) blocks on a PI mutex held by another
       DEADLINE task (holder), but the holder doesn't inherit parameters
       (e.g., it already has a shorter deadline)
    2. sched_setscheduler() changes the holder from DEADLINE to a lower
       class while still holding the mutex
    3. The holder should now inherit DEADLINE parameters from the donor
       and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen

    Fix the issue by introducing __setscheduler_dl_pi(), which detects when
    a DEADLINE (proper or boosted) task gets setscheduled to a lower
    priority class. In case, the function makes the task inherit DEADLINE
    parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to
    ensure proper bandwidth accounting during the next enqueue operation.

    Fixes: 2279f540ea ("sched/deadline: Fix priority inheritance with multiple scheduling classes")
    Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
    Signed-off-by: Juri Lelli <juri.lelli@redhat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://patch.msgid.link/20260302-upstream-fix-deadline-piboost-b4-v3-1-6ba32184a9e0@redhat.com

(cherry picked from commit d658686a1331db3bb108ca079d76deb3208ed949)
Assisted-by: Patchpal AI
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-24 17:06:57 -03:00
Herton R. Krzesinski 1a850ff839 sched/rt: Skip currently executing CPU in rto_next_cpu() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 94894c9c477e53bcea052e075c53f89df3d2a33e
Author: Chen Jinghuang <chenjinghuang2@huawei.com>
Date:   Thu Jan 22 01:25:33 2026 +0000

    sched/rt: Skip currently executing CPU in rto_next_cpu()

    CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound
    RT task, and a CFS task stuck in kernel space. When other CPUs switch from
    RT to non-RT tasks, RT load balancing (LB) is triggered; with
    HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution
    of rto_push_irq_work_func. During push_rt_task on CPU0,
    if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED
    and after the push operation completes, CPU0 calls rto_next_cpu().
    Since only CPU0 is overloaded in this scenario, rto_next_cpu() should
    ideally return -1 (no further IPI needed).

    However, multiple CPUs invoking tell_cpu_to_push() during LB increments
    rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between
    rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its
    search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory
    && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to
    itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and
    other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,
    which triggers a CPU hardlockup due to continuous self-interrupts.

    The trigging scenario is as follows:

             cpu0                      cpu1                    cpu2
                                    pull_rt_task
                                  tell_cpu_to_push
                     <------------irq_work_queue_on
    rto_push_irq_work_func
           push_rt_task
        resched_curr(rq)                                   pull_rt_task
        rto_next_cpu                                     tell_cpu_to_push
                          <-------------------------- atomic_inc(rto_loop_next)
    rd->rto_loop != next
         rto_next_cpu
       irq_work_queue_on
    rto_push_irq_work_func

    Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().
    This solution has been verified to effectively eliminate spurious self-IPIs
    and prevent CPU hardlockup scenarios.

    Fixes: 4bdced5c9a ("sched/rt: Simplify the IPI based RT balancing logic")
    Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Chen Jinghuang <chenjinghuang2@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com

(cherry picked from commit 94894c9c477e53bcea052e075c53f89df3d2a33e)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:08 -03:00
Herton R. Krzesinski 96488e9133 sched/clock: Avoid false sharing for sched_clock_irqtime 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 505da6689305b1103e9a8ab6636c6a7cf74cd5b1
Author: Wangyang Guo <wangyang.guo@intel.com>
Date:   Tue Jan 27 15:25:09 2026 +0800

    sched/clock: Avoid false sharing for sched_clock_irqtime

    Read-mostly sched_clock_irqtime may share the same cacheline with
    frequently updated nohz struct. Make it as static_key to avoid
    false sharing issue.

    The only user of disable_sched_clock_irqtime()
    is tsc_.*mark_unstable() which may be invoked under atomic context
    and require a workqueue to disable static_key. But both of them
    calls clear_sched_clock_stable() just before doing
    disable_sched_clock_irqtime(). We can reuse
    "sched_clock_work" to also disable sched_clock_irqtime().

    One additional case need to handle is if the tsc is marked unstable
    before late_initcall() phase, sched_clock_work will not be invoked
    and sched_clock_irqtime will stay enabled although clock is unstable:
      tsc_init()
        enable_sched_clock_irqtime() # irqtime accounting is enabled here
        ...
        if (unsynchronized_tsc()) # true
          mark_tsc_unstable()
            clear_sched_clock_stable()
              __sched_clock_stable_early = 0;
              ...
              if (static_key_count(&sched_clock_running.key) == 2)
                # Only happens at sched_clock_init_late()
                __clear_sched_clock_stable(); # Never executed
      ...

      # late_initcall() phase
      sched_clock_init_late()
        if (__sched_clock_stable_early) # Already false
          __set_sched_clock_stable(); # sched_clock is never marked stable
      # TSC unstable, but sched_clock_work won't run to disable irqtime

    So we need to disable_sched_clock_irqtime() in sched_clock_init_late()
    if clock is unstable.

    Reported-by: Benjamin Lei <benjamin.lei@intel.com>
    Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Suggested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Wangyang Guo <wangyang.guo@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
    Reviewed-by: Tianyou Li <tianyou.li@intel.com>
    Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Link: https://patch.msgid.link/20260127072509.2627346-1-wangyang.guo@intel.com

(cherry picked from commit 505da6689305b1103e9a8ab6636c6a7cf74cd5b1)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:08 -03:00
Herton R. Krzesinski 11e0f9c0e0 sched: Update rq->avg_idle when a task is moved to an idle CPU 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: context differences, at ttwu_do_activate() and at
           put_prev_task_idle()

commit 4b603f1551a73e2868b9e7a14b3938c23275cefb
Author: Shubhang Kaushik <shubhang@os.amperecomputing.com>
Date:   Wed Jan 21 01:31:53 2026 -0800

    sched: Update rq->avg_idle when a task is moved to an idle CPU

    Currently, rq->idle_stamp is only used to calculate avg_idle during
    wakeups. This means other paths that move a task to an idle CPU such as
    fork/clone, execve, or migrations, do not end the CPU's idle status in
    the scheduler's eyes, leading to an inaccurate avg_idle.

    This patch introduces update_rq_avg_idle() to provide a more accurate
    measurement of CPU idle duration. By invoking this helper in
    put_prev_task_idle(), we ensure avg_idle is updated whenever a CPU
    stops being idle, regardless of how the new task arrived.

    Testing on an 80-core Ampere Altra (ARMv8) with 6.19-rc5 baseline:
     - Hackbench : +7.2% performance gain at 16 threads.
     - Schbench: Reduced p99.9 tail latencies at high concurrency.

    Signed-off-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Tested-by: Shubhang Kaushik <shubhang@os.amperecomputing.com>
    Link: https://patch.msgid.link/20260121-v8-patch-series-v8-1-b7f1cbee5055@os.amperecomputing.com

(cherry picked from commit 4b603f1551a73e2868b9e7a14b3938c23275cefb)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:08 -03:00
Herton R. Krzesinski f6458df457 sched/debug: Convert copy_from_user() + kstrtouint() to kstrtouint_from_user() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 4fe82cf3024a4bdd2571d584efc25598533d5c96
Author: Fushuai Wang <wangfushuai@baidu.com>
Date:   Sat Jan 17 22:56:14 2026 +0800

    sched/debug: Convert copy_from_user() + kstrtouint() to kstrtouint_from_user()

    Using kstrtouint_from_user() instead of copy_from_user() + kstrtouint()
    makes the code simpler and less error-prone.

    Suggested-by: Yury Norov <ynorov@nvidia.com>
    Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Yury Norov <ynorov@nvidia.com>
    Link: https://patch.msgid.link/20260117145615.53455-2-fushuai.wang@linux.dev

(cherry picked from commit 4fe82cf3024a4bdd2571d584efc25598533d5c96)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:08 -03:00
Herton R. Krzesinski bd41290534 sched/fair: Fix pelt clock sync when entering idle 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: had to manually apply the hunk at set_next_task_idle(),
           since rhel-9 did not have some updates in the function
           as in upstream code

commit 98c88dc8a1ace642d9021b103b28cba7b51e3abc
Author: Vincent Guittot <vincent.guittot@linaro.org>
Date:   Wed Jan 21 17:33:17 2026 +0100

    sched/fair: Fix pelt clock sync when entering idle

    Samuel and Alex reported regressions of the util_avg of RT rq with
    commit 17e3e88ed0b6 ("sched/fair: Fix pelt lost idle time detection").
    It happens that fair is updating and syncing the pelt clock with task one
    when pick_next_task_fair() fails to pick a task but before the prev
    scheduling class got a chance to update its pelt signals.

    Move update_idle_rq_clock_pelt() in set_next_task_idle() which is called
    after prev class has been called.

    Fixes: 17e3e88ed0b6 ("sched/fair: Fix pelt lost idle time detection")
    Closes: https://lore.kernel.org/all/CAG2KctpO6VKS6GN4QWDji0t92_gNBJ7HjjXrE+6H+RwRXt=iLg@mail.gmail.com/
    Closes: https://lore.kernel.org/all/8cf19bf0e0054dcfed70e9935029201694f1bb5a.camel@mediatek.com/
    Reported-by: Samuel Wu <wusamuel@google.com>
    Reported-by: Alex Hoh <Alex.Hoh@mediatek.com>
    Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Samuel Wu <wusamuel@google.com>
    Tested-by: Alex Hoh <Alex.Hoh@mediatek.com>
    Link: https://patch.msgid.link/20260121163317.505635-1-vincent.guittot@linaro.org

(cherry picked from commit 98c88dc8a1ace642d9021b103b28cba7b51e3abc)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:08 -03:00
Herton R. Krzesinski 6cf70d7ff1 sched/fair: Remove nohz.nr_cpus and use weight of cpumask instead 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 5d86d542f68fda7ef6d543ac631b741db734101a
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Thu Jan 15 13:05:24 2026 +0530

    sched/fair: Remove nohz.nr_cpus and use weight of cpumask instead

    nohz.nr_cpus was observed as contended cacheline when running
    enterprise workload on large systems.

    Fundamental scalability challenge with nohz.idle_cpus_mask
    and nohz.nr_cpus is the following:

     (1) nohz_balancer_kick() observes (reads) nohz.nr_cpus
         (or nohz.idle_cpu_mask) and nohz.has_blocked to  see whether there's
         any nohz balancing work to do, in every scheduler tick.

     (2) nohz_balance_enter_idle() and nohz_balance_exit_idle()
         (through nohz_balancer_kick() via sched_tick()) modify (write)
         nohz.nr_cpus (and/or nohz.idle_cpu_mask) and nohz.has_blocked.

    The characteristic frequencies are the following:

     (1) nohz_balancer_kick() happens at scheduler (busy)tick frequency
         on CPU(which has not gone idle). This is a relatively constant
         frequency  in the ~1 kHz range or lower.

     (2) happens at idle enter/exit frequency on every CPU that goes to idle.
         This is workload dependent, but can easily be hundreds of kHz for
         IO-bound loads and high CPU counts. Ie. can be orders of magnitude
         higher than (1), in which case a cachemiss at every invocation of (1)
         is almost inevitable. idle exit will trigger (1) on the CPU
         which is coming out of idle.

    There's two types of costs from these functions:

     (A) scheduler tick cost via (1): this happens on busy CPUs too, and is
         thus a primary scalability cost. But the rate here is constant and
         typically much lower than (B), hence the absolute benefit to workload
         scalability will be lower as well.

     (B) idle cost via (2): going-to-idle and coming-from-idle costs are
         secondary concerns, because they impact power efficiency more than
         they impact scalability. But in terms of absolute cost this scales
         up with nr_cpus as well, and a much faster rate, and thus may also
         approach and negatively impact system limits like
         memory bus/fabric bandwidth.

    Note that nohz.idle_cpus_mask and nohz.nr_cpus may appear to reside in the
    same cacheline, however under CONFIG_CPUMASK_OFFSTACK=y the backing storage
    for nohz.idle_cpus_mask will be elsewhere. With CPUMASK_OFFSTACK=n,
    the nohz.idle_cpus_mask and rest of nohz fields are in different cachelines
    under typical NR_CPUS=512/2048. This implies two separate cachelines
    being dirtied upon idle entry / exit.

    nohz.nr_cpus can be derived from the mask itself. Its usage doesn't warrant
    a functionally correct value. This means one less cacheline being dirtied in
    idle entry/exit path which helps to save some bus bandwidth w.r.t to those
    nohz functions(approx 50%). This in turn helps to improve enterprise
    workload throughput.

    On system with 480 CPUs, running "hackbench 40 process 10000 loops"
    (Avg of 3 runs)
    baseline:
         0.81%  hackbench          [k] nohz_balance_exit_idle
         0.21%  hackbench          [k] nohz_balancer_kick
         0.09%  swapper            [k] nohz_run_idle_balance

    With patch:
         0.35%  hackbench          [k] nohz_balance_exit_idle
         0.09%  hackbench          [k] nohz_balancer_kick
         0.07%  swapper            [k] nohz_run_idle_balance

    [Ingo Molnar: scalability analysis changlog]

    Reviewed-and-tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20260115073524.376643-4-sshegde@linux.ibm.com

(cherry picked from commit 5d86d542f68fda7ef6d543ac631b741db734101a)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski c68975e3cc sched/fair: Change likelyhood of nohz.nr_cpus 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 94e70734b4d034b9df795bd1ad3452ea96e742ca
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Thu Jan 15 13:05:23 2026 +0530

    sched/fair: Change likelyhood of nohz.nr_cpus

    These days most of the system have multi cores. The likelyhood of
    at least one or more CPUs in nohz (idle state) is higher.

    Give accurate hint to the branch predictor.

    Reviewed-and-tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20260115073524.376643-3-sshegde@linux.ibm.com

(cherry picked from commit 94e70734b4d034b9df795bd1ad3452ea96e742ca)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski b2d6b1322d sched/fair: Move checking for nohz cpus after time check 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 6b67c8a72e56041f91f70ae5995bdb769761869a
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Thu Jan 15 13:05:22 2026 +0530

    sched/fair: Move checking for nohz cpus after time check

    Current code does.
    - Read nohz.nr_cpus
    - Check if the time has passed to do NOHZ idle balance

    Instead do this.
    - Check if the time has passed to do NOHZ idle balance
    - Read nohz.nr_cpus

    This will skip the read most of the time in normal system usage.
    i.e when there are nohz.nr_cpus (system is not 100% busy).

    Note that when there are no idle CPUs(100% busy), even if the flag gets
    set to NOHZ_STATS_KICK | NOHZ_NEXT_KICK, find_new_ilb will fail and
    there will be no NOHZ idle balance. In such cases there will be a very
    narrow window where, kick_ilb will be called un-necessarily.
    However current functionality is still retained.

    Note: This patch doesn't solve any cacheline overheads. No improvement
    in performance apart from saving a few cycles of reading nohz.nr_cpus

    Reviewed-and-tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20260115073524.376643-2-sshegde@linux.ibm.com

(cherry picked from commit 6b67c8a72e56041f91f70ae5995bdb769761869a)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski 63db77544d sched: Deadline has dynamic priority 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit e008ec6c7904ed99d3b2cb634b6545b008a99288
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Jan 15 09:25:37 2026 +0100

    sched: Deadline has dynamic priority

    While FIFO/RR have static priority, DEADLINE is a dynamic priority
    scheme. Notably it has static priority -1. Do not assume the priority
    doesn't change for deadline tasks just because the static priority
    doesn't change.

    This ensures DL always sees {DE,EN}QUEUE_MOVE where appropriate.

    Fixes: ff77e46853 ("sched/rt: Fix PI handling vs. sched_setscheduler()")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Pierre Gondois <pierre.gondois@arm.com>
    Tested-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://patch.msgid.link/20260114130528.GB831285@noisy.programming.kicks-ass.net

(cherry picked from commit e008ec6c7904ed99d3b2cb634b6545b008a99288)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski 81be38faf1 sched/fair: Use cpumask_weight_and() in sched_balance_find_dst_group() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 55b39b0cf183b9c682717a55a2fba06da69bba6b
Author: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Date:   Sat Dec 6 22:42:47 2025 -0500

    sched/fair: Use cpumask_weight_and() in sched_balance_find_dst_group()

    In the group_has_spare case, the function creates a temporary cpumask
    to just calculate weight of (p->cpus_ptr & sched_group_span(local)).

    We've got a dedicated helper for it.

    Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Fernand Sieber <sieberf@amazon.com>
    Link: https://patch.msgid.link/20251207034247.402926-1-yury.norov@gmail.com

(cherry picked from commit 55b39b0cf183b9c682717a55a2fba06da69bba6b)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski 95059eacb2 sched/fair: Simplify task_numa_find_cpu() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 0ab25ea2a3b3a973fb914d0e47dc9c3c26049e8b
Author: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Date:   Sat Dec 6 22:30:36 2025 -0500

    sched/fair: Simplify task_numa_find_cpu()

    Use for_each_cpu_and() and drop some housekeeping code.

    Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Phil Auld <pauld@redhat.com>
    Link: https://patch.msgid.link/20251207033037.399608-1-yury.norov@gmail.com

(cherry picked from commit 0ab25ea2a3b3a973fb914d0e47dc9c3c26049e8b)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski 7c0006d6ea sched/fair: Drop useless cpumask_empty() in find_energy_efficient_cpu() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit ff1de90dd7a69ef43586683535ad87ab899a1214
Author: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Date:   Sat Dec 6 23:05:42 2025 -0500

    sched/fair: Drop useless cpumask_empty() in find_energy_efficient_cpu()

    cpumask_empty() call is O(N) and useless because the previous
    cpumask_and() returns false for empty 'cpus'. Drop it.

    Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20251207040543.407695-1-yury.norov@gmail.com

(cherry picked from commit ff1de90dd7a69ef43586683535ad87ab899a1214)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski 3096ec9da9 sched/fair: Fix sched_avg fold 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: minor context differences at *_load_avg definitions
           since rhel-9 still has CONFIG_SMP

commit 6ab7973f254071faf20fe5fcc502a3fe9ca14a47
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Dec 19 09:04:45 2025 +0100

    sched/fair: Fix sched_avg fold

    After the robot reported a regression wrt commit: 089d84203ad4 ("sched/fair:
    Fold the sched_avg update"), Shrikanth noted that two spots missed a factor
    se_weight().

    Fixes: 089d84203ad4 ("sched/fair: Fold the sched_avg update")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202512181208.753b9f6e-lkp@intel.com
    Debugged-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://patch.msgid.link/20251218102020.GO3707891@noisy.programming.kicks-ass.net

(cherry picked from commit 6ab7973f254071faf20fe5fcc502a3fe9ca14a47)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:07 -03:00
Herton R. Krzesinski c7b305fe71 sched/fair: Sort out 'blocked_load*' namespace noise 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 527a521029c3edd38fb9fc96cd58e3fd7393d28e
Author: Ingo Molnar <mingo@kernel.org>
Date:   Tue Dec 2 10:35:06 2025 +0100

    sched/fair: Sort out 'blocked_load*' namespace noise

    There's three layers of logic in the scheduler that
    deal with 'has_blocked' (load) handling of the NOHZ code:

      (1) nohz.has_blocked,
      (2) rq->has_blocked_load, deal with NOHZ idle balancing,
      (3) and cfs_rq_has_blocked(), which is part of the layer
          that is passing the SMP load-balancing signal to the
          NOHZ layers.

    The 'has_blocked' and 'has_blocked_load' names are used
    in a mixed fashion, sometimes within the same function.

    Standardize on 'has_blocked_load' to make it all easy
    to read and easy to grep.

    No change in functionality.

    Suggested-by: Vincent Guittot <vincent.guittot@linaro.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Frederic Weisbecker <frederic@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Link: https://patch.msgid.link/aS6yvxyc3JfMxxQW@gmail.com

(cherry picked from commit 527a521029c3edd38fb9fc96cd58e3fd7393d28e)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski 7607a31fa0 sched/fair: Avoid rq->lock bouncing in sched_balance_newidle() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: context differences, the notable one being at
           sched_balance_newidle() since we do not have the
           commit "sched: Detect per-class runqueue changes",
           which we don't apply as it's also related to sched_ext
           (we do not have sched_ext in rhel 9)

commit 45e09225085f70b856b7b9f26a18ea767a7e1563
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Nov 12 16:08:23 2025 +0100

    sched/fair: Avoid rq->lock bouncing in sched_balance_newidle()

    While poking at this code recently I noted we do a pointless
    unlock+lock cycle in sched_balance_newidle(). We drop the rq->lock (so
    we can balance) but then instantly grab the same rq->lock again in
    sched_balance_update_blocked_averages().

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://patch.msgid.link/20251127154725.532469061@infradead.org

(cherry picked from commit 45e09225085f70b856b7b9f26a18ea767a7e1563)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski 2f0bba81e9 sched/fair: Fold the sched_avg update 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: minor context differences at *_load_avg definitions
           since rhel-9 still has CONFIG_SMP

commit 089d84203ad42bc8fd6dbf41683e162ac6e848cd
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Nov 27 16:39:44 2025 +0100

    sched/fair: Fold the sched_avg update

    Nine (and a half) instances of the same pattern is just silly, fold the lot.

    Notably, the half instance in enqueue_load_avg() is right after setting
    cfs_rq->avg.load_sum to cfs_rq->avg.load_avg * get_pelt_divider(&cfs_rq->avg).
    Since get_pelt_divisor() >= PELT_MIN_DIVIDER, this ends up being a no-op
    change.

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Cc: Valentin Schneider <vschneid@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20251127154725.413564507@infradead.org

(cherry picked from commit 089d84203ad42bc8fd6dbf41683e162ac6e848cd)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski 1850bbb08a <linux/compiler_types.h>: Add the __signed_scalar_typeof() helper 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 38a68b982dd0b10e3da943f100e034598326eafe
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Nov 27 16:39:44 2025 +0100

    <linux/compiler_types.h>: Add the __signed_scalar_typeof() helper

    Define __signed_scalar_typeof() to declare a signed scalar type, leaving
    non-scalar types unchanged.

    To be used to clean up the scheduler load-balancing code a bit.

    [ mingo: Split off this patch from the scheduler patch. ]

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Cc: Juri Lelli <juri.lelli@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Cc: Valentin Schneider <vschneid@redhat.com>
    Cc: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://patch.msgid.link/20251127154725.413564507@infradead.org

(cherry picked from commit 38a68b982dd0b10e3da943f100e034598326eafe)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski fbe16192ea sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when the last task migrates out 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit ca125231dd29fc0678dd3622e9cdea80a51dffe4
Author: xupengbo <xupengbo@oppo.com>
Date:   Wed Aug 27 10:22:07 2025 +0800

    sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when the last task migrates out

    When a task is migrated out, there is a probability that the tg->load_avg
    value will become abnormal. The reason is as follows:

    1. Due to the 1ms update period limitation in update_tg_load_avg(), there
       is a possibility that the reduced load_avg is not updated to tg->load_avg
       when a task migrates out.

    2. Even though __update_blocked_fair() traverses the leaf_cfs_rq_list and
       calls update_tg_load_avg() for cfs_rqs that are not fully decayed, the key
       function cfs_rq_is_decayed() does not check whether
       cfs->tg_load_avg_contrib is null. Consequently, in some cases,
       __update_blocked_fair() removes cfs_rqs whose avg.load_avg has not been
       updated to tg->load_avg.

    Add a check of cfs_rq->tg_load_avg_contrib in cfs_rq_is_decayed(),
    which fixes the case (2.) mentioned above.

    Fixes: 1528c661c24b ("sched/fair: Ratelimit update to tg->load_avg")
    Signed-off-by: xupengbo <xupengbo@oppo.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Aaron Lu <ziqianlu@bytedance.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Tested-by: Aaron Lu <ziqianlu@bytedance.com>
    Link: https://patch.msgid.link/20250827022208.14487-1-xupengbo@oppo.com

(cherry picked from commit ca125231dd29fc0678dd3622e9cdea80a51dffe4)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski 724405c807 sched/headers: Remove whitespace noise from kernel/sched/sched.h 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: minor context difference

commit dde3763365d80398d1465214458d0c38cc32de9c
Author: Ingo Molnar <mingo@kernel.org>
Date:   Wed Dec 3 18:19:14 2025 +0000

    sched/headers: Remove whitespace noise from kernel/sched/sched.h

    A single case of space-Tab noise snuck in recently.

    Fixes: 36569780b0d6 ("sched: Change nr_uninterruptible type to unsigned long")
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://patch.msgid.link/176478595428.498.13816176784792752599.tip-bot2@tip-bot2

(cherry picked from commit dde3763365d80398d1465214458d0c38cc32de9c)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski bdc7d6d1fc sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 185bccc79797d71477e672a1b2a2b7d0325044e7
Author: Gabriele Monaco <gmonaco@redhat.com>
Date:   Thu Nov 20 15:56:51 2025 +0100

    sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any

    Currently the user can set up isolcpus and nohz_full in such a way that
    leaves no housekeeping CPU (i.e. no CPU that is neither domain isolated
    nor nohz full). This can be a problem for other subsystems (e.g. the
    timer wheel imgration).

    Prevent this configuration by invalidating the last setting in case the
    union of isolcpus (domain) and nohz_full covers all CPUs.

    Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Link: https://patch.msgid.link/20251120145653.296659-6-gmonaco@redhat.com

(cherry picked from commit 185bccc79797d71477e672a1b2a2b7d0325044e7)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-11 10:34:06 -03:00
Herton R. Krzesinski 5d520c4331 sched/fair: Proportional newidle balance 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: minor context fuzz at kernel/sched/core.c and
           at kernel/sched/features.h

commit 33cf66d88306663d16e4759e9d24766b0aaa2e17
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Nov 7 17:01:31 2025 +0100

    sched/fair: Proportional newidle balance

    Add a randomized algorithm that runs newidle balancing proportional to
    its success rate.

    This improves schbench significantly:

     6.18-rc4:			2.22 Mrps/s
     6.18-rc4+revert:		2.04 Mrps/s
     6.18-rc4+revert+random:	2.18 Mrps/S

    Conversely, per Adam Li this affects SpecJBB slightly, reducing it by 1%:

     6.17:			-6%
     6.17+revert:		 0%
     6.17+revert+random:	-1%

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Chris Mason <clm@meta.com>
    Link: https://lkml.kernel.org/r/6825c50d-7fa7-45d8-9b81-c6e7e25738e2@meta.com
    Link: https://patch.msgid.link/20251107161739.770122091@infradead.org

(cherry picked from commit 33cf66d88306663d16e4759e9d24766b0aaa2e17)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-10 11:56:43 -03:00
Herton R. Krzesinski 113ada785e sched/fair: Small cleanup to update_newidle_cost() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 08d473dd8718e4a4d698b1113a14a40ad64a909b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Nov 7 17:01:27 2025 +0100

    sched/fair: Small cleanup to update_newidle_cost()

    Simplify code by adding a few variables.

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Chris Mason <clm@meta.com>
    Link: https://patch.msgid.link/20251107161739.655208666@infradead.org

(cherry picked from commit 08d473dd8718e4a4d698b1113a14a40ad64a909b)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-10 11:43:35 -03:00
Herton R. Krzesinski 30b5472709 sched/fair: Small cleanup to sched_balance_newidle() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit e78e70dbf603c1425f15f32b455ca148c932f6c1
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Nov 7 17:01:24 2025 +0100

    sched/fair: Small cleanup to sched_balance_newidle()

    Pull out the !sd check to simplify code.

    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Chris Mason <clm@meta.com>
    Link: https://patch.msgid.link/20251107161739.525916173@infradead.org

(cherry picked from commit e78e70dbf603c1425f15f32b455ca148c932f6c1)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-10 11:35:05 -03:00
Herton R. Krzesinski a1b0db77f8 sched/fair: Revert max_newidle_lb_cost bump 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit d206fbad9328ddb68ebabd7cf7413392acd38081
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Nov 7 17:01:20 2025 +0100

    sched/fair: Revert max_newidle_lb_cost bump

    Many people reported regressions on their database workloads due to:

      155213a2aed4 ("sched/fair: Bump sd->max_newidle_lb_cost when newidle balance fails")

    For instance Adam Li reported a 6% regression on SpecJBB.

    Conversely this will regress schbench again; on my machine from 2.22
    Mrps/s down to 2.04 Mrps/s.

    Reported-by: Joseph Salisbury <joseph.salisbury@oracle.com>
    Reported-by: Adam Li <adamli@os.amperecomputing.com>
    Reported-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Reported-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Chris Mason <clm@meta.com>
    Link: https://lkml.kernel.org/r/20250626144017.1510594-2-clm@fb.com
    Link: https://lkml.kernel.org/r/006c9df2-b691-47f1-82e6-e233c3f91faf@oracle.com
    Link: https://patch.msgid.link/20251107161739.406147760@infradead.org

(cherry picked from commit d206fbad9328ddb68ebabd7cf7413392acd38081)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-10 11:30:10 -03:00
Herton R. Krzesinski 2c7cbbeb75 sched/fair: Have SD_SERIALIZE affect newidle balancing 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 522fb20fbdbe48ed98f587d628637ff38ececd2d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Nov 17 17:13:09 2025 +0100

    sched/fair: Have SD_SERIALIZE affect newidle balancing

    Also serialize the possiblty much more frequent newidle balancing for
    the 'expensive' domains that have SD_BALANCE set.

    Initial benchmarking by K Prateek and Tim showed no negative effect.

    Split out from the larger patch moving sched_balance_running around
    for ease of bisect and such.

    Suggested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Seconded-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/df068896-82f9-458d-8fff-5a2f654e8ffd@amd.com
    Link: https://patch.msgid.link/6fed119b723c71552943bfe5798c93851b30a361.1762800251.git.tim.c.chen@linux.intel.com

    # Conflicts:
    #	kernel/sched/fair.c

(cherry picked from commit 522fb20fbdbe48ed98f587d628637ff38ececd2d)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-10 11:21:37 -03:00
Herton R. Krzesinski 1ed0f38cc5 sched/fair: Skip sched_balance_running cmpxchg when balance is not due 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 3324b2180c17b21c31c16966cc85ca41a7c93703
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Mon Nov 10 10:47:35 2025 -0800

    sched/fair: Skip sched_balance_running cmpxchg when balance is not due

    The NUMA sched domain sets the SD_SERIALIZE flag by default, allowing
    only one NUMA load balancing operation to run system-wide at a time.

    Currently, each sched group leader directly under NUMA domain attempts
    to acquire the global sched_balance_running flag via cmpxchg() before
    checking whether load balancing is due or whether it is the designated
    load balancer for that NUMA domain. On systems with a large number
    of cores, this causes significant cache contention on the shared
    sched_balance_running flag.

    This patch reduces unnecessary cmpxchg() operations by first checking
    that the balancer is the designated leader for a NUMA domain from
    should_we_balance(), and the balance interval has expired before
    trying to acquire sched_balance_running to load balance a NUMA
    domain.

    On a 2-socket Granite Rapids system with sub-NUMA clustering enabled,
    running an OLTP workload, 7.8% of total CPU cycles were previously spent
    in sched_balance_domain() contending on sched_balance_running before
    this change.

             : 104              static __always_inline int arch_atomic_cmpxchg(atomic_t *v, int old, int new)
             : 105              {
             : 106              return arch_cmpxchg(&v->counter, old, new);
        0.00 :   ffffffff81326e6c:       xor    %eax,%eax
        0.00 :   ffffffff81326e6e:       mov    $0x1,%ecx
        0.00 :   ffffffff81326e73:       lock cmpxchg %ecx,0x2394195(%rip)        # ffffffff836bb010 <sched_balance_running>
             : 110              sched_balance_domains():
             : 12234            if (atomic_cmpxchg_acquire(&sched_balance_running, 0, 1))
       99.39 :   ffffffff81326e7b:       test   %eax,%eax
        0.00 :   ffffffff81326e7d:       jne    ffffffff81326e99 <sched_balance_domains+0x209>
             : 12238            if (time_after_eq(jiffies, sd->last_balance + interval)) {
        0.00 :   ffffffff81326e7f:       mov    0x14e2b3a(%rip),%rax        # ffffffff828099c0 <jiffies_64>
        0.00 :   ffffffff81326e86:       sub    0x48(%r14),%rax
        0.00 :   ffffffff81326e8a:       cmp    %rdx,%rax

    After applying this fix, sched_balance_domain() is gone from the profile
    and there is a 5% throughput improvement.

    [peterz: made it so that redo retains the 'lock' and split out the
             CPU_NEWLY_IDLE change to a separate patch]
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Chen Yu <yu.c.chen@intel.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
    Tested-by: Mohini Narkhede <mohini.narkhede@intel.com>
    Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Link: https://patch.msgid.link/6fed119b723c71552943bfe5798c93851b30a361.1762800251.git.tim.c.chen@linux.intel.com

(cherry picked from commit 3324b2180c17b21c31c16966cc85ca41a7c93703)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 19:55:43 -03:00
Herton R. Krzesinski 47b9ddc4e6 sched/deadline: Minor cleanup in select_task_rq_dl() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 65177ea9f64d7402a0b8028e0dbbd01e8a9d1b1d
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Tue Oct 14 15:33:41 2025 +0530

    sched/deadline: Minor cleanup in select_task_rq_dl()

    In select_task_rq_dl, there is only one goto statement, there is no
    need for it.

    No functional changes.

    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://patch.msgid.link/20251014100342.978936-2-sshegde@linux.ibm.com

(cherry picked from commit 65177ea9f64d7402a0b8028e0dbbd01e8a9d1b1d)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 19:53:39 -03:00
Herton R. Krzesinski 06d426e22a sched/deadline: Use cpumask_weight_and() in dl_bw_cpus 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit b4bfacd39216755c058f6d13c71c86a9bf5a1631
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Tue Oct 14 15:33:42 2025 +0530

    sched/deadline: Use cpumask_weight_and() in dl_bw_cpus

    cpumask_subset(a,b) -> cpumask_weight(a) should be same as cpumask_weight_and(a,b)
    for_each_cpu_and(a,b) to count cpus could be replaced by cpumask_weight_and(a,b)

    No Functional Change. It could save a few cycles since cpumask_weight_and
    would be more efficient. Plus one less stack variable.

    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Link: https://patch.msgid.link/20251014100342.978936-3-sshegde@linux.ibm.com

(cherry picked from commit b4bfacd39216755c058f6d13c71c86a9bf5a1631)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 19:52:56 -03:00
Herton R. Krzesinski 40b85a20ee sched/core: Optimize core cookie matching check 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 7f829bde94b1c97b1804fa5860e066ea49dbfca3
Author: Fernand Sieber <sieberf@amazon.com>
Date:   Wed Nov 5 17:25:37 2025 +0200

    sched/core: Optimize core cookie matching check

    Early return true if the core cookie matches. This avoids the SMT mask
    loop to check for an idle core, which might be more expensive on wide
    platforms.

    Signed-off-by: Fernand Sieber <sieberf@amazon.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
    Reviewed-by: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
    Link: https://patch.msgid.link/20251105152538.470586-1-sieberf@amazon.com

(cherry picked from commit 7f829bde94b1c97b1804fa5860e066ea49dbfca3)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 19:37:32 -03:00
Herton R. Krzesinski 8b37fcf2cb sched/fair: Only update stats for allowed CPUs when looking for dst group 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 82d6e01a0699800efd8b048eb584c907ccb47b7a
Author: Adam Li <adamli@os.amperecomputing.com>
Date:   Sat Oct 11 06:43:22 2025 +0000

    sched/fair: Only update stats for allowed CPUs when looking for dst group

    Load imbalance is observed when the workload frequently forks new threads.
    Due to CPU affinity, the workload can run on CPU 0-7 in the first
    group, and only on CPU 8-11 in the second group. CPU 12-15 are always idle.

    { 0 1 2 3 4 5 6 7 } {8 9 10 11 12 13 14 15}
      * * * * * * * *    * * *  *

    When looking for dst group for newly forked threads, in many times
    update_sg_wakeup_stats() reports the second group has more idle CPUs
    than the first group. The scheduler thinks the second group is less
    busy. Then it selects least busy CPUs among CPU 8-11. Therefore CPU 8-11
    can be crowded with newly forked threads, at the same time CPU 0-7
    can be idle.

    A task may not use all the CPUs in a schedule group due to CPU affinity.
    Only update schedule group statistics for allowed CPUs.

    Signed-off-by: Adam Li <adamli@os.amperecomputing.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

(cherry picked from commit 82d6e01a0699800efd8b048eb584c907ccb47b7a)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 18:53:45 -03:00
Herton R. Krzesinski 07e9446cef sched/deadline: only set free_cpus for online runqueues 
JIRA: https://issues.redhat.com/browse/RHEL-147187

Conflicts: minor contex fuzz at kernel/sched/cpudeadline.h

commit 382748c05e58a9f1935f5a653c352422375566ea
Author: Doug Berger <opendmb@gmail.com>
Date:   Thu Aug 14 18:22:36 2025 -0700

    sched/deadline: only set free_cpus for online runqueues

    Commit 16b269436b ("sched/deadline: Modify cpudl::free_cpus
    to reflect rd->online") introduced the cpudl_set/clear_freecpu
    functions to allow the cpu_dl::free_cpus mask to be manipulated
    by the deadline scheduler class rq_on/offline callbacks so the
    mask would also reflect this state.

    Commit 9659e1eeee ("sched/deadline: Remove cpu_active_mask
    from cpudl_find()") removed the check of the cpu_active_mask to
    save some processing on the premise that the cpudl::free_cpus
    mask already reflected the runqueue online state.

    Unfortunately, there are cases where it is possible for the
    cpudl_clear function to set the free_cpus bit for a CPU when the
    deadline runqueue is offline. When this occurs while a CPU is
    connected to the default root domain the flag may retain the bad
    state after the CPU has been unplugged. Later, a different CPU
    that is transitioning through the default root domain may push a
    deadline task to the powered down CPU when cpudl_find sees its
    free_cpus bit is set. If this happens the task will not have the
    opportunity to run.

    One example is outlined here:
    https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com

    Another occurs when the last deadline task is migrated from a
    CPU that has an offlined runqueue. The dequeue_task member of
    the deadline scheduler class will eventually call cpudl_clear
    and set the free_cpus bit for the CPU.

    This commit modifies the cpudl_clear function to be aware of the
    online state of the deadline runqueue so that the free_cpus mask
    can be updated appropriately.

    It is no longer necessary to manage the mask outside of the
    cpudl_set/clear functions so the cpudl_set/clear_freecpu
    functions are removed. In addition, since the free_cpus mask is
    now only updated under the cpudl lock the code was changed to
    use the non-atomic __cpumask functions.

    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

(cherry picked from commit 382748c05e58a9f1935f5a653c352422375566ea)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 18:36:05 -03:00
Herton R. Krzesinski 6d2835a357 sched/core: Avoid direct access to hrtimer clockbase 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit b68b7f3e9b50747b88ba211080d27310430c928b
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Date:   Thu Aug 21 15:28:10 2025 +0200

    sched/core: Avoid direct access to hrtimer clockbase

    The field timer->base->get_time is a private implementation detail and
    should not be accessed outside of the hrtimer core.

    Switch to the equivalent helper.

    Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/all/20250821-hrtimer-cleanup-get_time-v2-3-3ae822e5bfbd@linutronix.de

(cherry picked from commit b68b7f3e9b50747b88ba211080d27310430c928b)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 16:39:37 -03:00
Herton R. Krzesinski cf5c0ea88e sched/deadline: Fix race in push_dl_task() 
JIRA: https://issues.redhat.com/browse/RHEL-147187

commit 8fd5485fb4f3d9da3977fd783fcb8e5452463420
Author: Harshit Agarwal <harshit@nutanix.com>
Date:   Tue Apr 8 04:50:21 2025 +0000

    sched/deadline: Fix race in push_dl_task()

    When a CPU chooses to call push_dl_task and picks a task to push to
    another CPU's runqueue then it will call find_lock_later_rq method
    which would take a double lock on both CPUs' runqueues. If one of the
    locks aren't readily available, it may lead to dropping the current
    runqueue lock and reacquiring both the locks at once. During this window
    it is possible that the task is already migrated and is running on some
    other CPU. These cases are already handled. However, if the task is
    migrated and has already been executed and another CPU is now trying to
    wake it up (ttwu) such that it is queued again on the runqeue
    (on_rq is 1) and also if the task was run by the same CPU, then the
    current checks will pass even though the task was migrated out and is no
    longer in the pushable tasks list.
    Please go through the original rt change for more details on the issue.

    To fix this, after the lock is obtained inside the find_lock_later_rq,
    it ensures that the task is still at the head of pushable tasks list.
    Also removed some checks that are no longer needed with the addition of
    this new check.
    However, the new check of pushable tasks list only applies when
    find_lock_later_rq is called by push_dl_task. For the other caller i.e.
    dl_task_offline_migration, existing checks are used.

    Signed-off-by: Harshit Agarwal <harshit@nutanix.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Juri Lelli <juri.lelli@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20250408045021.3283624-1-harshit@nutanix.com

(cherry picked from commit 8fd5485fb4f3d9da3977fd783fcb8e5452463420)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-03-09 16:04:21 -03:00
Herton R. Krzesinski 9bc90f5e0f printk: Allow printk_trigger_flush() to flush all types 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

Conflicts: In RHEL 9 code:
* we call nbcon_atomic_flush_all() instead of nbcon_atomic_flush_pending()
* we call nbcon_wake_threads() instead of nbcon_kthreads_wake()
Also, since we do not have the upstream change "printk: nbcon: Flush new
records on device_release()", we dropped the change for the
nbcon_device_release() (and another detail, that function is named
nbcon_release() in RHEL 9).

commit d01ff281bd9b1bfeac9ab98ec8a9ee41da900d5e
Author: John Ogness <john.ogness@linutronix.de>
Date:   Thu Nov 13 17:09:47 2025 +0106

    printk: Allow printk_trigger_flush() to flush all types

    Currently printk_trigger_flush() only triggers legacy offloaded
    flushing, even if that may not be the appropriate method to flush
    for currently registered consoles. (The function predates the
    NBCON consoles.)

    Since commit 6690d6b52726 ("printk: Add helper for flush type
    logic") there is printk_get_console_flush_type(), which also
    considers NBCON consoles and reports all the methods of flushing
    appropriate based on the system state and consoles available.

    Update printk_trigger_flush() to use
    printk_get_console_flush_type() to appropriately flush registered
    consoles.

    Suggested-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/stable/20251113160351.113031-2-john.ogness%40linutronix.de
    Tested-by: Sherry Sun <sherry.sun@nxp.com>
    Link: https://patch.msgid.link/20251113160351.113031-2-john.ogness@linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>

(cherry picked from commit d01ff281bd9b1bfeac9ab98ec8a9ee41da900d5e)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:44:17 -05:00
Herton R. Krzesinski 75bcd04e69 printk: nbcon: Use raw_cpu_ptr() instead of open coding 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

commit d33d5e683b0d3b4f5fc6a49ce17583f8ca663944
Author: John Ogness <john.ogness@linutronix.de>
Date:   Tue Aug 27 16:25:31 2024 +0206

    printk: nbcon: Use raw_cpu_ptr() instead of open coding

    There is no need to open code a non-migration-checking
    this_cpu_ptr(). That is exactly what raw_cpu_ptr() is.

    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/87plpum4jw.fsf@jogness.linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>

(cherry picked from commit d33d5e683b0d3b4f5fc6a49ce17583f8ca663944)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:40:47 -05:00
Herton R. Krzesinski 7145395d95 backport "printk: Add helper for flush type logic" and associated changes 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: RHEL 9 only

This is mainly a backport of the upstream commit 6690d6b52726 ("printk: Add
helper for flush type logic"), however it does have significant differences,
because the code present in RHEL 9 is different from upstream, due having
an earlier version of the printk changes that later went upstream (since
the code was based on what was in 6.6-rt). As such, this backport is considered
RHEL only and not a straight backport of such upstream commit.

We first introduce the printk_get_console_flush_type(), but also fold the
addition of nbcon_offload field done in upstream commit 13189fa73afa ("printk:
nbcon: Rely on kthreads for normal operation"). This upstream commit is also not
backported entirely due the way nbcon threads support was backported, since
RHEL 9 used an earlier version (eg. upstream has nbcon_kthreads_wake() and
we have nbcon_wake_threads() backported through the change "printk: nbcon: Add
printer thread wakeups"). Because of these and other differences, we have a more
limited usage of printk_get_console_flush_type(), and also have to
still have the system_state check in vprintk_emit() (for this last case,
we don't have the same logic for checking if kthreads are running as in upstream,
and the nbcon kthreads should be running most of the time except when doing the
system shutdown/reboot where printk_kthread_shutdown() runs, thus we
must keep doing the atomic printing in vprintk_emit in this case).

RHEL 9 also had an earlier version of the nbcon emergency sections, which is
upstream commit ecb5e1aa82c8 ("printk: nbcon: Implement emergency sections").
The emergency sections code and comment is updated as is in upstream now, as
behaviour with printk_get_console_flush_type() is different not blocking
console flushing anymore in ft->legacy_direct case, thus we stop doing
printk_trigger_flush() at nbcon_cpu_emergency_exit().

Related to the printk_get_console_flush_type() introduction and changes,
printk_legacy_allow_panic_sync() also is updated as in the upstream
version to do flushing in the legacy_direct case if needed, and
console_flush_on_panic() is updated as well to effectively sync the code
doing the same as the changes in upstream commit e35a8884270b ("printk:
Coordinate direct printing in panic"). We had an earlier version
of it applied which didn't have those changes.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:40:47 -05:00
Herton R. Krzesinski 868759c6c4 printk: Remove redundant deferred check in vprintk() 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

RHEL 9 backport notes:

There are no conflicts with this change, but the RHEL 9 code
at this point is a bit different when you look at the upstream commit
changelog: we do not have the printk_get_console_flush_type() yet, but
in previous commit we also made the check in vprintk() redundant, since
in vprintk_emit() we are now using is_printk_legacy_deferred().

Previously, any call to vprintk where is_printk_legacy_deferred() was
true resulted in:
* vprintk calling vprintk_deferred()
* vprintk_deferred() purpose is to call vprintk_emit with LOGLEVEL_SCHED
* in vprintk_emit(), LOGLEVEL_SCHED made do_trylock_unlock to be
  disabled

Since now we use the is_printk_legacy_deferred() check inside vprintk_emit()
for do_trylock_unlock, we do not need to do this anymore in vprintk()
function. This also simplifies the code making it easier to understand,
and closer to the upstream code. There should be no functional change
with this patch.

commit f1c21cf470595c4561d4671fd499af94152175d5
Author: John Ogness <john.ogness@linutronix.de>
Date:   Mon Dec 9 12:23:45 2024 +0106

    printk: Remove redundant deferred check in vprintk()

    The helper printk_get_console_flush_type() is already calling
    is_printk_legacy_deferred() to determine if legacy printing is
    to be offloaded. Therefore there is no need for vprintk() to
    perform this check as well. Remove the redundant check from
    vprintk().

    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20241209111746.192559-2-john.ogness@linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>

(cherry picked from commit f1c21cf470595c4561d4671fd499af94152175d5)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:40:46 -05:00
Herton R. Krzesinski f34a575a3c printk: Introduce force_legacy_kthread() macro 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: RHEL 9 only

This commit adds the force_legacy_kthread() macro and its usage, as was
done in the upstream commit 5f53ca3ff83b ("printk: Implement legacy printer
kthread for PREEMPT_RT"). It replaces all the IS_ENABLED(CONFIG_PREEMPT_RT)
checks in the rhel 9 code.

This has to be a RHEL only commit since that specific change also added
the legacy kthreads to printk, which we already have in RHEL 9 (for RT
only) through the commit 3f11513ac3 ("printk: Add kthread for all legacy
consoles").

With it we can replace the specific RT check at vprintk_emit(), and use
the macro instead: the idea is to drop then the vprintk_deferred() call
from vprintk() function at kernel/printk/printk_safe.c, which is
redundant after this change. In the next commit I'll bring the upstream
change that removes the now redundant check from vprintk().

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:40:46 -05:00
Herton R. Krzesinski 5ef5037f55 printk: Add is_printk_legacy_deferred() 
JIRA: https://issues.redhat.com/browse/RHEL-141481
Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

commit 70411bf8d22ab3d2f794f199d81d70b62d3a85fa
Author: John Ogness <john.ogness@linutronix.de>
Date:   Tue Aug 20 08:35:49 2024 +0206

    printk: Add is_printk_legacy_deferred()

    If printk has been explicitly deferred or is called from NMI
    context, legacy console printing must be deferred to an irq_work
    context. Introduce a helper function is_printk_legacy_deferred()
    for a CPU to query if it must defer legacy console printing.

    In follow-up commits this helper will be needed at other call
    sites as well.

    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20240820063001.36405-24-john.ogness@linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>

(cherry picked from commit 70411bf8d22ab3d2f794f199d81d70b62d3a85fa)
Assisted-by: Patchpal
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2026-01-30 21:40:46 -05:00
Herton R. Krzesinski d7adf52568 mm/debug_vm_pgtable: clear page table entries at destroy_args() 
JIRA: https://issues.redhat.com/browse/RHEL-16340

commit dde30854bddfb5d69f30022b53c5955a41088b33
Author: Herton R. Krzesinski <herton@redhat.com>
Date:   Thu Jul 31 18:40:51 2025 -0300

    mm/debug_vm_pgtable: clear page table entries at destroy_args()

    The mm/debug_vm_pagetable test allocates manually page table entries for
    the tests it runs, using also its manually allocated mm_struct.  That in
    itself is ok, but when it exits, at destroy_args() it fails to clear those
    entries with the *_clear functions.

    The problem is that leaves stale entries.  If another process allocates an
    mm_struct with a pgd at the same address, it may end up running into the
    stale entry.  This is happening in practice on a debug kernel with
    CONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra
    debugging I added (it prints a warning trace if pgtables_bytes goes
    negative, in addition to the warning at check_mm() function):

    [    2.539353] debug_vm_pgtable: [get_random_vaddr         ]: random_vaddr is 0x7ea247140000
    [    2.539366] kmem_cache info
    [    2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508
    [    2.539447] debug_vm_pgtable: [init_args                ]: args->mm is 0x000000002267cc9e
    (...)
    [    2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0
    [    2.552816] Modules linked in:
    [    2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY
    [    2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries
    [    2.552872] NIP:  c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90
    [    2.552885] REGS: c0000000622e73b0 TRAP: 0700   Not tainted  (6.12.0-105.debug_vm2.el10.ppc64le+debug)
    [    2.552899] MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24002822  XER: 0000000a
    [    2.552954] CFAR: c0000000008f03f0 IRQMASK: 0
    [    2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001
    [    2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff
    [    2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000
    [    2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb
    [    2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0
    [    2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000
    [    2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001
    [    2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760
    [    2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0
    [    2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0
    [    2.553199] Call Trace:
    [    2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)
    [    2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0
    [    2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570
    [    2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650
    [    2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290
    [    2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0
    [    2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870
    [    2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150
    [    2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50
    [    2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0
    [    2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
    (...)
    [    2.558892] ---[ end trace 0000000000000000 ]---
    [    2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1
    [    2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144

    Here the modprobe process ended up with an allocated mm_struct from the
    mm_struct slab that was used before by the debug_vm_pgtable test.  That is
    not a problem, since the mm_struct is initialized again etc., however, if
    it ends up using the same pgd table, it bumps into the old stale entry
    when clearing/freeing the page table entries, so it tries to free an entry
    already gone (that one which was allocated by the debug_vm_pgtable test),
    which also explains the negative pgtables_bytes since it's accounting for
    not allocated entries in the current process.

    As far as I looked pgd_{alloc,free} etc.  does not clear entries, and
    clearing of the entries is explicitly done in the free_pgtables->
    free_pgd_range->free_p4d_range->free_pud_range->free_pmd_range->
    free_pte_range path.  However, the debug_vm_pgtable test does not call
    free_pgtables, since it allocates mm_struct and entries manually for its
    test and eg.  not goes through page faults.  So it also should clear
    manually the entries before exit at destroy_args().

    This problem was noticed on a reboot X number of times test being done on
    a powerpc host, with a debug kernel with CONFIG_DEBUG_VM_PGTABLE enabled.
    Depends on the system, but on a 100 times reboot loop the problem could
    manifest once or twice, if a process ends up getting the right mm->pgd
    entry with the stale entries used by mm/debug_vm_pagetable.  After using
    this patch, I couldn't reproduce/experience the problems anymore.  I was
    able to reproduce the problem as well on latest upstream kernel (6.16).

    I also modified destroy_args() to use mmput() instead of mmdrop(), there
    is no reason to hold mm_users reference and not release the mm_struct
    entirely, and in the output above with my debugging prints I already had
    patched it to use mmput, it did not fix the problem, but helped in the
    debugging as well.

    Link: https://lkml.kernel.org/r/20250731214051.4115182-1-herton@redhat.com
    Fixes: 3c9b84f044a9 ("mm/debug_vm_pgtable: introduce struct pgtable_debug_args")
    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: Gavin Shan <gshan@redhat.com>
    Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-09-25 14:39:58 -03:00
Herton R. Krzesinski 56ae35991f Makefile: add $(srctree) to dependency of compile_commands.json target 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 6fc9aacad49e3fbecd270c266850d50c453d52ef
Author: Alexandre Courbot <gnurou@gmail.com>
Date:   Sun Aug 4 14:50:57 2024 +0900

    Makefile: add $(srctree) to dependency of compile_commands.json target

    When trying to build compile_commands.json for an external module against
    the kernel built in a separate output directory, the following error is
    displayed:

      make[1]: *** No rule to make target 'scripts/clang-tools/gen_compile_commands.py',
      needed by 'compile_commands.json'. Stop.

    This is because gen_compile_commands.py was previously looked up using a
    relative path to $(srctree), but commit b1992c3772e6 ("kbuild: use
    $(src) instead of $(srctree)/$(src) for source directory") stopped
    defining VPATH for external module builds.

    Prefixing gen_compile_commands.py with $(srctree) fixes the problem.

    Fixes: b1992c3772e6 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory")
    Signed-off-by: Alexandre Courbot <gnurou@gmail.com>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:25 -03:00
Herton R. Krzesinski e61bb3a2be kbuild: scripts/gdb: bring the "abspath" back 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit a11aaf6d0bb4282ce1989e388b13f8d87154ba75
Author: Joel Granados <j.granados@samsung.com>
Date:   Wed Jun 26 14:06:16 2024 +0200

    kbuild: scripts/gdb: bring the "abspath" back

    Use the "abspath" call when symlinking the gdb python scripts in
    scripts/gdb/linux. This call is needed to avoid broken links when
    running the scripts_gdb target on a build directory located directly
    under the source tree (e.g., O=builddir).

    Fixes: 659bbf7e1b08 ("kbuild: scripts/gdb: Replace missed $(srctree)/$(src) w/ $(src)")
    Signed-off-by: Joel Granados <j.granados@samsung.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:25 -03:00
Herton R. Krzesinski 80dc8c4911 kbuild: Use $(obj)/%.cc to fix host C++ module builds 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 7ed9d1318c127b3aec77099802a9fdf2480250b4
Author: Nicolas Schier <n.schier@avm.de>
Date:   Mon Jun 24 13:12:14 2024 +0200

    kbuild: Use $(obj)/%.cc to fix host C++ module builds

    Use $(obj)/ instead of $(src)/ prefix when building C++ modules for
    host, as explained in commit b1992c3772e6 ("kbuild: use $(src) instead
    of $(srctree)/$(src) for source directory").  This fixes build failures
    of 'xconfig':

        $ make O=build/ xconfig
        make[1]: Entering directory '/data/linux/kbuild-review/build'
          GEN     Makefile
        make[3]: *** No rule to make target '../scripts/kconfig/qconf-moc.cc', needed by 'scripts/kconfig/qconf-moc.o'.  Stop.

    Fixes: b1992c3772e6 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory")
    Reported-by: Rolf Eike Beer <eb@emlix.com>
    Signed-off-by: Nicolas Schier <n.schier@avm.de>
    Tested-by: Rolf Eike Beer <eb@emlix.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski 4fda0c7e7c kbuild: scripts/gdb: Replace missed $(srctree)/$(src) w/ $(src) 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 659bbf7e1b08267b8e1dd900b316edcb6f6d9e2e
Author: Douglas Anderson <dianders@chromium.org>
Date:   Mon May 20 12:56:52 2024 -0700

    kbuild: scripts/gdb: Replace missed $(srctree)/$(src) w/ $(src)

    Recently we went through the source tree and replaced
    $(srctree)/$(src) w/ $(src). However, the gdb scripts Makefile had a
    hidden $(srctree)/$(src) that looked like this:

      $(abspath $(srctree))/$(src)

    Because we missed that then my installed kernel had symlinks that
    looked like this:

      __init__.py ->
        ${INSTALL_DIR}/$(INSTALL_DIR}/scripts/gdb/linux/__init__.py

    Let's also replace the midden $(abspath $(srctree))/$(src) with
    $(src). Now:

      __init__.py ->
        $(INSTALL_DIR}/scripts/gdb/linux/__init__.py

    Fixes: b1992c3772e6 ("kbuild: use $(src) instead of $(srctree)/$(src) for source directory")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski a1b9805d99 kbuild: use $(src) instead of $(srctree)/$(src) for source directory 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit b1992c3772e69a6fd0e3fc81cd4d2820c8b6eca0
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Apr 27 23:55:02 2024 +0900

    kbuild: use $(src) instead of $(srctree)/$(src) for source directory

    Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
    checked-in source files. It is merely a convention without any functional
    difference. In fact, $(obj) and $(src) are exactly the same, as defined
    in scripts/Makefile.build:

        src := $(obj)

    When the kernel is built in a separate output directory, $(src) does
    not accurately reflect the source directory location. While Kbuild
    resolves this discrepancy by specifying VPATH=$(srctree) to search for
    source files, it does not cover all cases. For example, when adding a
    header search path for local headers, -I$(srctree)/$(src) is typically
    passed to the compiler.

    This introduces inconsistency between upstream and downstream Makefiles
    because $(src) is used instead of $(srctree)/$(src) for the latter.

    To address this inconsistency, this commit changes the semantics of
    $(src) so that it always points to the directory in the source tree.

    Going forward, the variables used in Makefiles will have the following
    meanings:

      $(obj)     - directory in the object tree
      $(src)     - directory in the source tree  (changed by this commit)
      $(objtree) - the top of the kernel object tree
      $(srctree) - the top of the kernel source tree

    Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
    with $(src).

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Conflicts:

There is a extensive list of fixes/conflicts due the amount of files originally
changed by this commit, plus the difference of rhel-9 code against upstream. All
conflicts/differences are listed below:

- Context difference at Documentation/Makefile since RHEL 9 does not have the
  change "docs: allow to pass extra DOCS_CSS themes via make" and later changes.
- Conflict at Documentation/devicetree/bindings/Makefile, patch find_cmd instead
  of find_all_cmd since RHEL-9 doesn't have "dt-bindings: Consider
  DT_SCHEMA_FILES when finding all json-schema", "dt-bindings: kbuild: Split
  targets out to separate rules" and later changes.
- Conflict at Documentation/kbuild/makefiles.rst due different identation since
  RHEL-9 doesn't have the change "docs/kbuild/makefiles: clean up indentation
  and whitespace"
- Patched additional $(srctree)/$(src) references at:
   * arch/arm/mach-davinci/Makefile
   * arch/arm/mach-omap2/Makefile
   * arch/arm/mach-spear/Makefile
   * arch/arm/plat-pxa/Makefile
   * arch/arm/plat-versatile/Makefile
   * arch/ia64/kernel/Makefile
   * arch/nds32/boot/Makefile
   * arch/nds32/kernel/vdso/Makefile
   * drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
   * drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile
   * drivers/staging/rtl8188eu/Makefile
   * drivers/staging/unisys/visorhba/Makefile
   * drivers/staging/unisys/visornic/Makefile
   * scripts/gcc-plugins/Makefile
  Since RHEL-9 does not have later upstream changes that dropped/made those
  references uneeded.
- Conflict at arch/arm/mach-s3c/Makefile since RHEL-9 doesn't have
  "ARM: s3c: remove s3c24xx specific hacks" and related changes. Also,
  extra locations needed patching because of not having the changes
  "ARM: s3c: remove all s3c24xx support" and "ARM: s3c: fix include path".
  Due lacking the last change also arch/arm/mach-s3c/Makefile.s3c64xx needs
  additional two places patched as well.
- Conflict at arch/arm/plat-orion/Makefile since RHEL-9 doesn't have
  the commit "ARM: orion: fix include path" and its previous related
  changes.
- Dropped changes for arch/loongarch since it doesn't exist on rhel-9
- Dropped changes to arch/parisc/kernel/{vdso32,vdso64}/Makefile since RHEL 9
  does not have the change "parisc: Add vDSO support" and later updates to it.
- Dropped change to arch/riscv/kernel/compat_vdso/Makefile since RHEL 9 does
  not have the change "riscv: compat: vdso: Add COMPAT_VDSO base code implementation"
- Dropped change to arch/riscv/kvm/Makefile since there is no KVM support/commits
  in RHEL 9 for riscv.
- Apply change for arch/riscv/kernel/vdso/Makefile in a different place since
  RHEL-9 does not have the change "riscv: explicitly use symbol offsets for VDSO"
  which changed the location of the $(srctree)/$(src) reference
- Dropped change to certs/Makefile related to check-blacklist-hashes.awk since
  that script was only added with commit "certs: Check that builtin blacklist
  hashes are valid" which is not backported/available in RHEL 9 code right now.
- Dropped change to drivers/md/dm-vdo/Makefile since dm-vdo was never backported
  to RHEL-9 main.
- Dropped change to drivers/net/ethernet/fungible/funeth/Makefile since fungible
  ethernet driver/devices code is not available/backported to RHEL-9.
- Fixed conflict at drivers/net/ethernet/hisilicon/hns3/Makefile since RHEL-9
  does not have the change "net: hns3: refactor hns3 makefile to support
  hns3_common module"
- Fixed conflict at drivers/net/wireless/intel/iwlwifi/mvm/Makefile due already
  backported commit "wifi: iwlwifi: mvm: implement link grading"
- Dropped change to init/Makefile since we are not backporting
  "kbuild: build init/built-in.a just once" that introduced the section patched.
- Dropped change to rust/Makefile since there is no rust support backported
  to RHEL-9.
- Fixed conflict at scripts/dtc/Makefile since RHEL-9 does not have the change
  "dt-bindings: kbuild: Use DTB files for validation"
- Dropped change to security/tomoyo/Makefile since it's not needed, it's just
  reverting the change "tomoyo: fix broken dependency on *.conf.default" which
  was never applied to RHEL-9. However, we also bring a different change/patch
  location since RHEL-9 does not have the change "tomoyo: Omit use of bin2c".
- Dropped change to usr/include/Makefile since "kbuild: move headers_check.pl to
  usr/include/" is not being backported to RHEL-9.
- Misc/minor context differences at other places.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski 5332bc5fc0 kbuild: use $(obj)/ instead of $(src)/ for common pattern rules 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 9a0ebe5011f49e932bb0a2cea2034fd65e6e567e
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Apr 27 23:55:01 2024 +0900

    kbuild: use $(obj)/ instead of $(src)/ for common pattern rules

    Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
    checked-in source files. It is merely a convention without any functional
    difference. In fact, $(obj) and $(src) are exactly the same, as defined
    in scripts/Makefile.build:

      src := $(obj)

    Before changing the semantics of $(src) in the next commit, this commit
    replaces $(obj)/ with $(src)/ in pattern rules where the prerequisite
    might be a generated file.

    C, assembly, Rust, and DTS files are sometimes generated by tools, so
    they could be either generated files or real sources. The $(obj)/ prefix
    works for both cases with the help of VPATH.

    As mentioned above, $(obj) and $(src) are the same at this point, hence
    this commit has no functional change.

    I did not modify scripts/Makefile.userprogs because there is no use
    case where userspace C files are generated.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Conflicts:
- scripts/Makefile.lib: since RHEL 9 does not have "dt-bindings: kbuild:
  Use DTB files for validation", we patch the yaml target instead.
- At scripts/Makefile.build:
  * Adjusted $(obj)/%.symversions patching due previously applied RHEL only
    commit "kbuild: expose explicit .symversions targets" and which now
    needs to also be update with this change
  * Dropped patching of some targets (eg. with %.rs) since RHEL 9 does not
    have "Kbuild: add Rust support"

Assisted-by: Patchpal AI
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski 8fb0adb303 kbuild: do not add $(srctree) or $(objtree) to header search paths 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 9dcb47a616d552306a01c2032b81c0c920b06847
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Apr 27 23:55:00 2024 +0900

    kbuild: do not add $(srctree) or $(objtree) to header search paths

    scripts/Makefile.lib is included not only from scripts/Makefile.build
    but also from scripts/Makefile.{vmlinux,modfinal} for building generated
    C files.

    In scripts/Makefile.{vmlinux,modfinal}, $(obj) and $(src) are empty.

    Therefore, the header include paths:

        -I $(srctree)/$(src) -I $(objtree)/$(obj)

    ... become meaningless code:

        -I $(srctree)/ -I $(objtree)/

    Add these paths only when 'obj' and 'src' are defined.

    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/oe-kbuild-all/202404170634.BlqTaYA0-lkp@intel.com/
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nicolas Schier <n.schier@avm.de>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski 20d30d8fa5 arch: use $(obj)/ instead of $(src)/ for preprocessed linker scripts 
JIRA: https://issues.redhat.com/browse/RHEL-107194
Conflicts: dropped changes to parisc from the upstream commit, since
           RHEL 9 does not have "parisc: Add vDSO support" and later
           changes.

commit b957df3b858d16ba3d4291233569bba09cfd08c7
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Apr 27 23:54:59 2024 +0900

    arch: use $(obj)/ instead of $(src)/ for preprocessed linker scripts

    These are generated files. Prefix them with $(obj)/ instead of $(src)/.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Helge Deller <deller@gmx.de>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:24 -03:00
Herton R. Krzesinski 4763b1c733 arm64: vdso32: Remove unused vdso32-offsets.h 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit c7767f5c43df2c453af4651d1f58f489e3eb4ac1
Author: Kevin Brodsky <kevin.brodsky@arm.com>
Date:   Mon Jan 29 15:47:48 2024 +0000

    arm64: vdso32: Remove unused vdso32-offsets.h

    Commit 2d071968a4 ("arm64: compat: Remove 32-bit sigreturn code
    from the vDSO") removed all VDSO_* symbols in the compat vDSO. As a
    result, vdso32-offsets.h is now empty and therefore unused. Time to
    remove it.

    Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
    Link: https://lore.kernel.org/r/20240129154748.1727759-1-kevin.brodsky@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>

Conflicts:
- arch/arm64/kernel/vdso32/Makefile: since RHEL 9 does not have the change
  "arm64: vdso32: rename 32-bit debug vdso to vdso32.so.dbg", the removed
  code is slightly different.

Assisted-by: Patchpal AI
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-19 20:06:03 -03:00
Herton R. Krzesinski be3ddbca06 staging: vc04_services: interface: Drop include Makefile directive 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 2529ca2114028182f3871b2a27143e61de99321e
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Sat Jan 21 01:41:03 2023 +0530

    staging: vc04_services: interface: Drop include Makefile directive

    Drop the include directive. They can break the build, when one only
    wants to build a subdirectory. Replace with "../" for the includes,
    in the interface/ files instead.

    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Link: https://lore.kernel.org/r/20230120201104.606876-6-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:07 -03:00
Herton R. Krzesinski face1fe575 staging: vc04_services: vchiq-mmal: Drop include Makefile directive 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 74d5eb7de9b07e24b5257c6e62e8589f2084f10e
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Sat Jan 21 01:41:02 2023 +0530

    staging: vc04_services: vchiq-mmal: Drop include Makefile directive

    Drop the include directive. They can break the build, when one only
    wants to build a subdirectory. Replace with "../" for the includes,
    in the mmal-vchiq.c instead.

    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Link: https://lore.kernel.org/r/20230120201104.606876-5-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
- drivers/staging/vc04_services/vchiq-mmal/Makefile: keep
  -D__VCCOREVER__=0x04000000 since rhel-9 codebase is different,
  we want to remove only the $(srctree)/$(src) usage

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:07 -03:00
Herton R. Krzesinski 56a0907a08 staging: vc04_services: bcm2835-camera: Drop include Makefile directive 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 5395fb3b39488219984587b99f65f6bda7935df6
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Sat Jan 21 01:41:01 2023 +0530

    staging: vc04_services: bcm2835-camera: Drop include Makefile directive

    Drop the include directive. They can break the build, when one only
    wants to build a subdirectory. Replace with "../" for the includes,
    in the bcm2835-camera files instead.

    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20230120201104.606876-4-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
- drivers/staging/vc04_services/bcm2835-camera/Makefile: keep
  -D__VCCOREVER__=0x04000000 since rhel-9 codebase is different,
  we want to remove only the $(srctree)/$(src) usage

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:07 -03:00
Herton R. Krzesinski 9cdf25af5e staging: vc04_services: bcm2835-audio: Drop include Makefile directive 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 29d49a76c5b2afa6cc1f1d7e48d6f9422055383f
Author: Umang Jain <umang.jain@ideasonboard.com>
Date:   Sat Jan 21 01:41:00 2023 +0530

    staging: vc04_services: bcm2835-audio: Drop include Makefile directive

    Drop the include directive. They can break the build, when one only
    wants to build a subdirectory. Replace with "../" for the includes,
    in the bcm2835.h instead.

    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
    Link: https://lore.kernel.org/r/20230120201104.606876-3-umang.jain@ideasonboard.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
- drivers/staging/vc04_services/bcm2835-audio/Makefile: keep
  -D__VCCOREVER__=0x04000000 since rhel-9 codebase is different,
  we want to remove only the $(srctree)/$(src) usage

Assisted-by: Patchpal AI
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:07 -03:00
Herton R. Krzesinski 09bac63073 certs: check-in the default x509 config file 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit f3a2ba44e93e2c192a872f2705fe66dbf39708d6
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Fri Nov 5 12:59:55 2021 +0900

    certs: check-in the default x509 config file

    When x509.genkey is created, it prints a log:

      Generating X.509 key generation config

    ..., which is not the ordinary Kbuild log style.

    Check-in the default config as certs/default_x509.genkey to make it
    readable, and copy it to certs/x509.genkey if it is not present.

    The log is shown in the Kbuild style.

      COPY    certs/x509.genkey

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski 9326625c25 sparc: move the install rule to arch/sparc/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 87c3cb564f3e34626f1afc0286b864045559b403
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:24:40 2021 +0900

    sparc: move the install rule to arch/sparc/Makefile

    Currently, the install target in arch/sparc/Makefile descends into
    arch/sparc/boot/Makefile to invoke the shell script, but there is no
    good reason to do so.

    arch/sparc/Makefile can run the shell script directly.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski d640891766 riscv: move the (z)install rules to arch/riscv/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 399c1ec8467c563ae9db4c19a40a9d5e728b1e72
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:21:47 2021 +0900

    riscv: move the (z)install rules to arch/riscv/Makefile

    Currently, the (z)install targets in arch/riscv/Makefile descend into
    arch/riscv/boot/Makefile to invoke the shell script, but there is no
    good reason to do so.

    arch/riscv/Makefile can run the shell script directly.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski 725e4bd50f powerpc: move the install rule to arch/powerpc/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 86ff0bce2e9665c8b074930fe6caed615da070c1
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:19:37 2021 +0900

    powerpc: move the install rule to arch/powerpc/Makefile

    Currently, the install target in arch/powerpc/Makefile descends into
    arch/powerpc/boot/Makefile to invoke the shell script, but there is no
    good reason to do so.

    arch/powerpc/Makefile can run the shell script directly.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210729141937.445051-3-masahiroy@kernel.org

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski 265b4ef1b5 powerpc: make the install target not depend on any build artifact 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 9bef456b20581e630ef9a13555ca04fed65a859d
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:19:36 2021 +0900

    powerpc: make the install target not depend on any build artifact

    The install target should not depend on any build artifact.

    The reason is explained in commit 19514fc665 ("arm, kbuild: make
    "make install" not depend on vmlinux").

    Change the PowerPC installation code in a similar way.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210729141937.445051-2-masahiroy@kernel.org

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski a06b3903a8 powerpc: remove unused zInstall target from arch/powerpc/boot/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 156ca4e650bfb9a4259b427069caa11b5a4df3d4
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:19:35 2021 +0900

    powerpc: remove unused zInstall target from arch/powerpc/boot/Makefile

    Commit c913e5f95e ("powerpc/boot: Don't install zImage.* from make
    install") added the zInstall target to arch/powerpc/boot/Makefile,
    but you cannot use it since the corresponding hook is missing in
    arch/powerpc/Makefile.

    It has never worked since its addition. Nobody has complained about
    it for 7 years, which means this code was unneeded.

    With this removal, the install.sh will be passed in with 4 parameters.
    Simplify the shell script.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210729141937.445051-1-masahiroy@kernel.org

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski f40ec0e882 nios2: move the install rule to arch/nios2/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit 89b4db61c76197b899f9dc3dc06ea7c3a60729b8
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 23:07:06 2021 +0900

    nios2: move the install rule to arch/nios2/Makefile

    Currently, the install target in arch/nios2/Makefile descends into
    arch/nios2/boot/Makefile to invoke the shell script, but it is no
    good reason to do so.

    arch/nios2/Makefile can run the shell script directly.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski 72d41aefd4 ARM: 9102/1: move theinstall rules to arch/arm/Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-107194

commit d7bcc5e22967c96685d03dbbd167e1a1ddf9b910
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Jul 29 15:03:51 2021 +0100

    ARM: 9102/1: move theinstall rules to arch/arm/Makefile

    Currently, the (z/u)install targets in arch/arm/Makefile descend into
    arch/arm/boot/Makefile to invoke the shell script, but there is no
    good reason to do so.

    arch/arm/Makefile can run the shell script directly.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-08-18 16:15:06 -03:00
Herton R. Krzesinski bb06ba8b28 redhat: enable test_kmod, test_module and install kmod selftests 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit 88311ff4b85b556cff60da81d1dbe095b2190b8e
Author: Herton R. Krzesinski <herton@redhat.com>
Date:   Fri Jun 6 12:20:59 2025 -0300

    redhat: enable test_kmod, test_module and install kmod selftests

    Tested: installed both -modules-internal and selftests-internal sub
            packages and run the kmod.sh selftest with an unloaded fs module
            chosen with DEFAULT_KMOD_FS variable, with the same kernel build
            booted. Tested on both rawhide and eln.

    To be able to test the module subsystem in the kernel, enable the
    modules used by kmod selftests. Given current filters, those enabled
    modules already land automatically within the modules-internal
    subpackage. Also, install the kmod selftest script used for testing.

    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Conflicts:
- redhat/kernel.spec.template: 1 hunk modified
- as noticed by Jan Stancek we need to splicitly list modules for
  modules-internal subpackage in RHEL 9/CentOS 9, thus added the
  enabled modules in redhat/mod-internal.list

Assisted-by: Patchpal AI
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-23 19:05:45 -03:00
Herton R. Krzesinski a2e1d5dcbf lib/test_kmod: do not hardcode/depend on any filesystem 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit 92f3c5a0051d2b56379651522b587ff7309b2606
Author: Herton R. Krzesinski <herton@redhat.com>
Date:   Fri Apr 18 13:50:47 2025 -0300

    lib/test_kmod: do not hardcode/depend on any filesystem

    Right now test_kmod has hardcoded dependencies on btrfs/xfs.  That is not
    optimal since you end up needing to select/build them, but it is not
    really required since other fs could be selected for the testing.  Also,
    we can't change the default/driver module used for testing on
    initialization.

    Thus make it more generic: introduce two module parameters (start_driver
    and start_test_fs), which allow to select which modules/fs to use for the
    testing on test_kmod initialization.  Then it's up to the user to select
    which modules/fs to use for testing based on his config.  However, keep
    test_module as required default.

    This way, config/modules becomes selectable as when the testing is done
    from selftests (userspace).

    While at it, also change trigger_config_run_type, since at module
    initialization we already set the defaults at __kmod_config_init and
    should not need to do it again in test_kmod_init(), thus we can avoid to
    again set test_driver/test_fs.

    Link: https://lkml.kernel.org/r/20250418165047.702487-1-herton@redhat.com
    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
    Reviewed-by: Luis Chambelrain <mcgrof@kernel.org>
    Cc: Daniel Gomez <da.gomez@samsung.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Petr Pavlu <petr.pavlu@suse.com>
    Cc: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-18 10:38:54 -03:00
Herton R. Krzesinski 9c9c79e468 test_kmod: stop kernel-doc warnings 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit c093a74dac1c008daee92d6d613e9e3fe20b6585
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Jan 2 13:16:05 2023 -0800

    test_kmod: stop kernel-doc warnings

    Use kernel-doc notation to prevent warnings:

    lib/test_kmod.c:58: warning: contents before sections
    lib/test_kmod.c:94: warning: cannot understand function prototype: 'struct kmod_test_device_info '
    lib/test_kmod.c:119: warning: cannot understand function prototype: 'struct kmod_test_device '

    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: linux-modules@vger.kernel.org
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-18 10:38:54 -03:00
Herton R. Krzesinski 6e5f199d80 testing: use the copyleft-next-0.3.1 SPDX tag 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit 6cad1ecd4e3213d892b70afa999a81849d1f0206
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Oct 3 09:58:49 2022 -0700

    testing: use the copyleft-next-0.3.1 SPDX tag

    Two selftests drivers exist under the copyleft-next license.
    These drivers were added prior to SPDX practice taking full swing
    in the kernel. Now that we have an SPDX tag for copyleft-next-0.3.1
    documented, embrace it and remove the boiler plate.

    Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Cc: Kuno Woudt <kuno@frob.nl>
    Cc: Richard Fontana <fontana@sharpeleven.org>
    Cc: copyleft-next@lists.fedorahosted.org
    Cc: Ciaran Farrell <Ciaran.Farrell@suse.com>
    Cc: Christopher De Nicolo <Christopher.DeNicolo@suse.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Thorsten Leemhuis <linux@leemhuis.info>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Tim Bird <tim.bird@sony.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-18 10:38:53 -03:00
Herton R. Krzesinski 5eb4e2dfb0 redhat: spec: refresh the License field 
JIRA: https://issues.redhat.com/browse/RHEL-94010
Upstream Status: RHEL only

We need to refresh the License for the use of copyleft-next-0.3.1 tag, that
will be done when backporting the next change "testing: use the
copyleft-next-0.3.1 SPDX tag". Output of ./redhat/scripts/kspdx-tool/kspdx.py
was used to do it.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-18 10:38:40 -03:00
Herton R. Krzesinski c7f1cce92f LICENSES: Add the copyleft-next-0.3.1 license 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit ad9f64cd2d4a17f0d5ecf04d38170fdc34f21c61
Author: Luis Chamberlain <mcgrof@kernel.org>
Date:   Mon Oct 3 09:58:48 2022 -0700

    LICENSES: Add the copyleft-next-0.3.1 license

    Add the full text of the copyleft-next-0.3.1 license to the kernel
    tree as well as the required tags for reference and tooling.
    The license text was copied directly from the copyleft-next project's
    git tree [0].

    Discussion of using copyleft-next-0.3.1 on Linux started since June,
    2016 [1]. In the end Linus' preference was to have drivers use
    MODULE_LICENSE("GPL") to make it clear that the GPL applies when it
    comes to Linux [2]. Additionally, even though copyleft-next-0.3.1 has
    been found to be to be GPLv2 compatible by three attorneys at SUSE and
    Redhat [3], to err on the side of caution we simply recommend to
    always use the "OR" language for this license [4].

    Even though it has been a goal of the project to be GPL-v2 compatible
    to be certain in 2016 I asked for a clarification about what makes
    copyleft-next GPLv2 compatible and also asked for a summary of
    benefits. This prompted some small minor changes to make compatibility
    even further clear and as of copyleft 0.3.1 compatibility should
    be crystal clear [5].

    The summary of why copyleft-next 0.3.1 is compatible with GPLv2
    is explained as follows:

      Like GPLv2, copyleft-next requires distribution of derivative works
      ("Derived Works" in copyleft-next 0.3.x) to be under the same license.
      Ordinarily this would make the two licenses incompatible. However,
      copyleft-next 0.3.1 says: "If the Derived Work includes material
      licensed under the GPL, You may instead license the Derived Work under
      the GPL." "GPL" is defined to include GPLv2.

    In practice this means copyleft-next code in Linux may be licensed
    under the GPL2, however there are additional obvious gains for
    bringing contributions from Linux outbound where copyleft-next is
    preferred. A summary of benefits why projects outside of Linux might
    prefer to use copyleft-next >= 0.3.1 over GPLv2:

    o It is much shorter and simpler
    o It has an explicit patent license grant, unlike GPLv2
    o Its notice preservation conditions are clearer
    o More free software/open source licenses are compatible
      with it (via section 4)
    o The source code requirement triggered by binary distribution
      is much simpler in a procedural sense
    o Recipients potentially have a contract claim against distributors
      who are noncompliant with the source code requirement
    o There is a built-in inbound=outbound policy for upstream
      contributions (cf. Apache License 2.0 section 5)
    o There are disincentives to engage in the controversial practice
      of copyleft/ proprietary dual-licensing
    o In 15 years copyleft expires, which can be advantageous
      for legacy code
    o There are explicit disincentives to bringing patent infringement
      claims accusing the licensed work of infringement (see 10b)
    o There is a cure period for licensees who are not compliant
      with the license (there is no cure opportunity in GPLv2)
    o copyleft-next has a 'built-in or-later' provision

    The first driver submission to Linux under this dual strategy was
    lib/test_sysctl.c through commit 9308f2f9e7 ("test_sysctl: add
    dedicated proc sysctl test driver") merged in July 2017. Shortly after
    that I also added test_kmod through commit d9c6a72d6f ("kmod: add
    test driver to stress test the module loader") in the same month. These
    two drivers went in just a few months before the SPDX license practice
    kicked in. In 2018 Kuno Woudt went through the process to get SPDX
    identifiers for copyleft-next [6] [7]. Although there are SPDX tags
    for copyleft-next-0.3.0, we only document use in Linux starting from
    copyleft-next-0.3.1 which makes GPLv2 compatibility crystal clear.

    This patch will let us update the two Linux selftest drivers in
    subsequent patches with their respective SPDX license identifiers and
    let us remove repetitive license boiler plate.

    [0] https://github.com/copyleft-next/copyleft-next/blob/master/Releases/copyleft-next-0.3.1
    [1] https://lore.kernel.org/lkml/1465929311-13509-1-git-send-email-mcgrof@kernel.org/
    [2] https://lore.kernel.org/lkml/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aKLsOu0Og@mail.gmail.com/
    [3] https://lore.kernel.org/lkml/20170516232702.GL17314@wotan.suse.de/
    [4] https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com
    [5] https://lists.fedorahosted.org/archives/list/copyleft-next@lists.fedorahosted.org/thread/JTGV56DDADWGKU7ZKTZA4DLXTGTLNJ57/#SQMDIKBRAVDOCT4UVNOOCRGBN2UJIKHZ
    [6] https://spdx.org/licenses/copyleft-next-0.3.0.html
    [7] https://spdx.org/licenses/copyleft-next-0.3.1.html

    Cc: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Cc: Kuno Woudt <kuno@frob.nl>
    Cc: Richard Fontana <fontana@sharpeleven.org>
    Cc: copyleft-next@lists.fedorahosted.org
    Cc: Ciaran Farrell <Ciaran.Farrell@suse.com>
    Cc: Christopher De Nicolo <Christopher.DeNicolo@suse.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Thorsten Leemhuis <linux@leemhuis.info>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Reviewed-by: Tim Bird <tim.bird@sony.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-18 10:35:27 -03:00
Herton R. Krzesinski 746e1a0426 lib/Kconfig.debug: make TEST_KMOD depend on PAGE_SIZE_LESS_THAN_256KB 
JIRA: https://issues.redhat.com/browse/RHEL-94010

commit bbd2e05fad3e692ff2495895975bd0fce02bdbae
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jan 19 18:10:28 2022 -0800

    lib/Kconfig.debug: make TEST_KMOD depend on PAGE_SIZE_LESS_THAN_256KB

    Commit b05fbcc36b ("btrfs: disable build on platforms having page size
    256K") disabled btrfs for configurations that used a 256kB page size.
    However, it did not fully solve the problem because CONFIG_TEST_KMOD
    selects CONFIG_BTRFS, which does not account for the dependency.  This
    results in a Kconfig warning and the failed BUILD_BUG_ON error
    returning.

      WARNING: unmet direct dependencies detected for BTRFS_FS
        Depends on [n]: BLOCK [=y] && !PPC_256K_PAGES && !PAGE_SIZE_256KB [=y]
        Selected by [m]:
        - TEST_KMOD [=m] && RUNTIME_TESTING_MENU [=y] && m && MODULES [=y] && NETDEVICES [=y] && NET_CORE [=y] && INET [=y] && BLOCK [=y]

    To resolve this, add CONFIG_PAGE_SIZE_LESS_THAN_256KB as a dependency of
    CONFIG_TEST_KMOD so there is no more invalid configuration or build
    errors.

    Link: https://lkml.kernel.org/r/20211129230141.228085-4-nathan@kernel.org
    Fixes: b05fbcc36b ("btrfs: disable build on platforms having page size 256K")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Chris Mason <clm@fb.com>
    Cc: David Sterba <dsterba@suse.com>
    Cc: Josef Bacik <josef@toxicpanda.com>
    Cc: Luis Chamberlain <mcgrof@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-06-16 17:07:04 -03:00
Herton R. Krzesinski b6ca54c143 x86/uaccess: Improve performance by aligning writes to 8 bytes in copy_user_generic(), on non-FSRM/ERMS CPUs 
JIRA: https://issues.redhat.com/browse/RHEL-74389

commit b5322b6ec06a6c58650f52abcd2492000396363b
Author: Herton R. Krzesinski <herton@redhat.com>
Date:   Thu Mar 20 11:22:13 2025 -0300

    x86/uaccess: Improve performance by aligning writes to 8 bytes in copy_user_generic(), on non-FSRM/ERMS CPUs

    History of the performance regression:
    ======================================

    Since the following series of user copy updates were merged upstream
    ~2 years ago via:

      a5624566431d ("Merge branch 'x86-rep-insns': x86 user copy clarifications")

    .. copy_user_generic() on x86_64 stopped doing alignment of the
    writes to the destination to a 8 byte boundary for the non FSRM case.

    Previously, this was done through the ALIGN_DESTINATION macro that
    was used in the now removed copy_user_generic_unrolled function.

    Turns out this change causes some loss of performance/throughput on
    some use cases and specific CPU/platforms without FSRM and ERMS.

    Lately I got two reports of performance/throughput issues after a
    RHEL 9 kernel pulled the same upstream series with updates to user
    copy functions. Both reports consisted of running specific
    networking/TCP related testing using iperf3.

    Partial upstream fix
    ====================

    The first report was related to a Linux Bridge testing using VMs on a
    specific machine with an AMD CPU (EPYC 7402), and after a brief
    investigation it turned out that the later change via:

      ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS")

    ... helped/fixed the performance issue.

    However, after the later commit/fix was applied, then I got another
    regression reported in a multistream TCP test on a 100Gbit mlx5 nic, also
    running on an AMD based platform (AMD EPYC 7302 CPU), again that was using
    iperf3 to run the test. That regression was after applying the later
    fix/commit, but only this didn't help in telling the whole history.

    Testing performed to pinpoint residual regression
    =================================================

    So I narrowed down the second regression use case, but running it
    without traffic through a NIC, on localhost, in trying to narrow down
    CPU usage and not being limited by other factor like network bandwidth.
    I used another system also with an AMD CPU (AMD EPYC 7742). Basically,
    I run iperf3 in server and client mode in the same system, for example:

     - Start the server binding it to CPU core/thread 19:
       $ taskset -c 19 iperf3 -D -s -B 127.0.0.1 -p 12000

     - Start the client always binding/running on CPU core/thread 17, using
       perf to get statistics:
       $ perf stat -o stat.txt taskset -c 17 iperf3 -c 127.0.0.1 -b 0/1000 -V \
           -n 50G --repeating-payload -l 16384 -p 12000 --cport 12001 2>&1 \
           > stat-19.txt

    For the client, always running/pinned to CPU 17. But for the iperf3 in
    server mode, I did test runs using CPUs 19, 21, 23 or not pinned to any
    specific CPU. So it basically consisted with four runs of the same
    commands, just changing the CPU which the server is pinned, or without
    pinning by removing the taskset call before the server command. The CPUs
    were chosen based on NUMA node they were on, this is the relevant output
    of lscpu on the system:

      $ lscpu
      ...
        Model name:             AMD EPYC 7742 64-Core Processor
      ...
      Caches (sum of all):
        L1d:                    2 MiB (64 instances)
        L1i:                    2 MiB (64 instances)
        L2:                     32 MiB (64 instances)
        L3:                     256 MiB (16 instances)
      NUMA:
        NUMA node(s):           4
        NUMA node0 CPU(s):      0,1,8,9,16,17,24,25,32,33,40,41,48,49,56,57,64,65,72,73,80,81,88,89,96,97,104,105,112,113,120,121
        NUMA node1 CPU(s):      2,3,10,11,18,19,26,27,34,35,42,43,50,51,58,59,66,67,74,75,82,83,90,91,98,99,106,107,114,115,122,123
        NUMA node2 CPU(s):      4,5,12,13,20,21,28,29,36,37,44,45,52,53,60,61,68,69,76,77,84,85,92,93,100,101,108,109,116,117,124,125
        NUMA node3 CPU(s):      6,7,14,15,22,23,30,31,38,39,46,47,54,55,62,63,70,71,78,79,86,87,94,95,102,103,110,111,118,119,126,127
      ...

    So for the server run, when picking a CPU, I chose CPUs to be not on the same
    node. The reason is with that I was able to get/measure relevant
    performance differences when changing the alignment of the writes to the
    destination in copy_user_generic.

    Testing shows up to +81% performance improvement under iperf3
    =============================================================

    Here's a summary of the iperf3 runs:

      # Vanilla upstream alignment:

                         CPU      RATE          SYS          TIME     sender-receiver
            Server bind   19: 13.0Gbits/sec 28.371851000 33.233499566 86.9%-70.8%
            Server bind   21: 12.9Gbits/sec 28.283381000 33.586486621 85.8%-69.9%
            Server bind   23: 11.1Gbits/sec 33.660190000 39.012243176 87.7%-64.5%
            Server bind none: 18.9Gbits/sec 19.215339000 22.875117865 86.0%-80.5%

      # With the attached patch (aligning writes in non ERMS/FSRM case):

                         CPU      RATE          SYS          TIME     sender-receiver
            Server bind   19: 20.8Gbits/sec 14.897284000 20.811101382 75.7%-89.0%
            Server bind   21: 20.4Gbits/sec 15.205055000 21.263165909 75.4%-89.7%
            Server bind   23: 20.2Gbits/sec 15.433801000 21.456175000 75.5%-89.8%
            Server bind none: 26.1Gbits/sec 12.534022000 16.632447315 79.8%-89.6%

    So I consistently got better results when aligning the write. The
    results above were run on 6.14.0-rc6/rc7 based kernels. The sys is sys
    time and then the total time to run/transfer 50G of data. The last
    field is the CPU usage of sender/receiver iperf3 process. It's also
    worth to note that each pair of iperf3 runs may get slightly different
    results on each run, but I always got consistent higher results with
    the write alignment for this specific test of running the processes
    on CPUs in different NUMA nodes.

    Linus Torvalds helped/provided this version of the patch. Initially I
    proposed a version which aligned writes for all cases in
    rep_movs_alternative, however it used two extra registers and thus
    Linus provided an enhanced version that only aligns the write on the
    large_movsq case, which is sufficient since the problem happens only
    on those AMD CPUs like ones mentioned above without ERMS/FSRM, and
    also doesn't require using extra registers. Also, I validated that
    aligning only on large_movsq case is really enough for getting the
    performance back.

    I also tested this patch on an old Intel based non-ERMS/FRMS system
    (with Xeon E5-2667 - Sandy Bridge based) and didn't get any problems:
    no performance enhancement but also no regression either, using the
    same iperf3 based benchmark. Also newer Intel processors after
    Sandy Bridge usually have ERMS and should not be affected by this change.

    [ mingo: Updated the changelog. ]

    Fixes: ca96b162bfd2 ("x86: bring back rep movsq for user access on CPUs without ERMS")
    Fixes: 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function")
    Reported-by: Ondrej Lichtner <olichtne@redhat.com>
    Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20250320142213.2623518-1-herton@redhat.com

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-04-04 15:51:50 -03:00
Herton R. Krzesinski c1ba18a0fc x86: bring back rep movsq for user access on CPUs without ERMS 
JIRA: https://issues.redhat.com/browse/RHEL-74389

commit ca96b162bfd21a5d55e3cd6099e4ee357a0eeb68
Author: Mateusz Guzik <mjguzik@gmail.com>
Date:   Wed Aug 30 16:03:15 2023 +0200

    x86: bring back rep movsq for user access on CPUs without ERMS

    Intel CPUs ship with ERMS for over a decade, but this is not true for
    AMD.  In particular one reasonably recent uarch (EPYC 7R13) does not
    have it (or at least the bit is inactive when running on the Amazon EC2
    cloud -- I found rather conflicting information about AMD CPUs vs the
    extension).

    Hand-rolled mov loops executing in this case are quite pessimal compared
    to rep movsq for bigger sizes.  While the upper limit depends on uarch,
    everyone is well south of 1KB AFAICS and sizes bigger than that are
    common.

    While technically ancient CPUs may be suffering from rep usage, gcc has
    been emitting it for years all over kernel code, so I don't think this
    is a legitimate concern.

    Sample result from read1_processes from will-it-scale (4KB reads/s):

      before:   1507021
      after:    1721828 (+14%)

    Note that the cutoff point for rep usage is set to 64 bytes, which is
    way too conservative but I'm sticking to what was done in 47ee3f1dd93b
    ("x86: re-introduce support for ERMS copies for user space accesses").
    That is to say *some* copies will now go slower, which is fixable but
    beyond the scope of this patch.

    Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-04-04 15:50:29 -03:00
Herton R. Krzesinski b5e48a96a5 lazy tlb: fix hotplug exit race with MMU_LAZY_TLB_SHOOTDOWN 
JIRA: https://issues.redhat.com/browse/RHEL-82922

commit 21641bd9a7a7ce0360106a5a8e5b89a4fc74529d
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Mon Nov 4 11:23:18 2024 -0300

    lazy tlb: fix hotplug exit race with MMU_LAZY_TLB_SHOOTDOWN

    CPU unplug first calls __cpu_disable(), and that's where powerpc calls
    cleanup_cpu_mmu_context(), which clears this CPU from mm_cpumask() of all
    mms in the system.

    However this CPU may still be using a lazy tlb mm, and its mm_cpumask bit
    will be cleared from it.  The CPU does not switch away from the lazy tlb
    mm until arch_cpu_idle_dead() calls idle_task_exit().

    If that user mm exits in this window, it will not be subject to the lazy
    tlb mm shootdown and may be freed while in use as a lazy mm by the CPU
    that is being unplugged.

    cleanup_cpu_mmu_context() could be moved later, but it looks better to
    move the lazy tlb mm switching earlier.  The problem with doing the lazy
    mm switching in idle_task_exit() is explained in commit bf2c59fce4
    ("sched/core: Fix illegal RCU from offline CPUs"), which added a wart to
    switch away from the mm but leave it set in active_mm to be cleaned up
    later.

    So instead, switch away from the lazy tlb mm at sched_cpu_wait_empty(),
    which is the last hotplug state before teardown
    (CPUHP_AP_SCHED_WAIT_EMPTY).  This CPU will never switch to a user thread
    from this point, so it has no chance to pick up a new lazy tlb mm.  This
    removes the lazy tlb mm handling wart in CPU unplug.

    With this, idle_task_exit() is not needed anymore and can be cleaned up.
    This leaves the prototype alone, to be cleaned after this change.

    herton: took the suggestions from https://lore.kernel.org/all/87jzvyprsw.ffs@tglx/
    and made adjustments on the initial patch proposed by Nicholas.

    Link: https://lkml.kernel.org/r/20230524060455.147699-1-npiggin@gmail.com
    Link: https://lore.kernel.org/all/20230525205253.E2FAEC433EF@smtp.kernel.org/
    Link: https://lkml.kernel.org/r/20241104142318.3295663-1-herton@redhat.com
    Fixes: 2655421ae69f ("lazy tlb: shoot lazies, non-refcounting lazy tlb mm reference handling scheme")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-03-13 17:06:59 -03:00
Herton R. Krzesinski 32eb146a51 Revert "x86: bring back rep movsq for user access on CPUs without ERMS" 
JIRA: https://issues.redhat.com/browse/RHEL-79780
Upstream Status: RHEL Only

This reverts commit 4c7f1f18c7.

The change "x86: bring back rep movsq for user access", while aiming at
fixing a performance regression reported at RHEL-74389, unfortunately
brought another regression on lnst mlx5 multistream tcp test. This is like
a short blanket problem where looks like we fix one case in detriment of
other. It appears some AMD Zen processors without advertising ERMS/FSRM
looks to be problematic regarding memory copy and rep movs usage
(and I guess probably they are not advertising/supporting it in some
systems as probably they know it's not behaving well with rep movs).

Lets revert the change for now, until we can find an way to fix the
original issue reported at RHEL-74389 without bringing another regression
with it.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-02-19 16:26:50 -03:00
Herton R. Krzesinski 4c7f1f18c7 x86: bring back rep movsq for user access on CPUs without ERMS 
JIRA: https://issues.redhat.com/browse/RHEL-74389

commit ca96b162bfd21a5d55e3cd6099e4ee357a0eeb68
Author: Mateusz Guzik <mjguzik@gmail.com>
Date:   Wed Aug 30 16:03:15 2023 +0200

    x86: bring back rep movsq for user access on CPUs without ERMS

    Intel CPUs ship with ERMS for over a decade, but this is not true for
    AMD.  In particular one reasonably recent uarch (EPYC 7R13) does not
    have it (or at least the bit is inactive when running on the Amazon EC2
    cloud -- I found rather conflicting information about AMD CPUs vs the
    extension).

    Hand-rolled mov loops executing in this case are quite pessimal compared
    to rep movsq for bigger sizes.  While the upper limit depends on uarch,
    everyone is well south of 1KB AFAICS and sizes bigger than that are
    common.

    While technically ancient CPUs may be suffering from rep usage, gcc has
    been emitting it for years all over kernel code, so I don't think this
    is a legitimate concern.

    Sample result from read1_processes from will-it-scale (4KB reads/s):

      before:   1507021
      after:    1721828 (+14%)

    Note that the cutoff point for rep usage is set to 64 bytes, which is
    way too conservative but I'm sticking to what was done in 47ee3f1dd93b
    ("x86: re-introduce support for ERMS copies for user space accesses").
    That is to say *some* copies will now go slower, which is fixable but
    beyond the scope of this patch.

    Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2025-01-23 18:16:34 -03:00
Herton R. Krzesinski 3fc226e412 mm: resolve faulty mmap_region() error path behaviour 
JIRA: https://issues.redhat.com/browse/RHEL-68912
CVE: CVE-2024-53096
Conflicts: this is a backport from v6.6 LTS branch, commit bdc136e2b05f
           at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

commit 5de195060b2e251a835f622759550e6202167641
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:58 2024 +0000

    mm: resolve faulty mmap_region() error path behaviour

    [ Upstream commit 5de195060b2e251a835f622759550e6202167641 ]

    The mmap_region() function is somewhat terrifying, with spaghetti-like
    control flow and numerous means by which issues can arise and incomplete
    state, memory leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    Taking advantage of previous patches in this series we move a number of
    checks earlier in the code, simplifying things by moving the core of the
    logic into a static internal function __mmap_region().

    Doing this allows us to perform a number of checks up front before we do
    any real work, and allows us to unwind the writable unmap check
    unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
    validation unconditionally also.

    We move a number of things here:

    1. We preallocate memory for the iterator before we call the file-backed
       memory hook, allowing us to exit early and avoid having to perform
       complicated and error-prone close/free logic. We carefully free
       iterator state on both success and error paths.

    2. The enclosing mmap_region() function handles the mapping_map_writable()
       logic early. Previously the logic had the mapping_map_writable() at the
       point of mapping a newly allocated file-backed VMA, and a matching
       mapping_unmap_writable() on success and error paths.

       We now do this unconditionally if this is a file-backed, shared writable
       mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
       doing so does not invalidate the seal check we just performed, and we in
       any case always decrement the counter in the wrapper.

       We perform a debug assert to ensure a driver does not attempt to do the
       opposite.

    3. We also move arch_validate_flags() up into the mmap_region()
       function. This is only relevant on arm64 and sparc64, and the check is
       only meaningful for SPARC with ADI enabled. We explicitly add a warning
       for this arch if a driver invalidates this check, though the code ought
       eventually to be fixed to eliminate the need for this.

    With all of these measures in place, we no longer need to explicitly close
    the VMA on error paths, as we place all checks which might fail prior to a
    call to any driver mmap hook.

    This eliminates an entire class of errors, makes the code easier to reason
    about and more robust.

    Link: https://lkml.kernel.org/r/6e0becb36d2f5472053ac5d544c0edfe9b899e25.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Tested-by: Mark Brown <broonie@kernel.org>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:39:45 -03:00
Herton R. Krzesinski 30fd4705e8 mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling 
JIRA: https://issues.redhat.com/browse/RHEL-68912
Conflicts: small context differences in headers inclusion and because
           we do not have "mm: mmap: map MAP_STACK to VM_NOHUGEPAGE"
           applied

commit 5baf8b037debf4ec60108ccfeccb8636d1dbad81
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Tue Oct 29 18:11:47 2024 +0000

    mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling

    Currently MTE is permitted in two circumstances (desiring to use MTE
    having been specified by the VM_MTE flag) - where MAP_ANONYMOUS is
    specified, as checked by arch_calc_vm_flag_bits() and actualised by
    setting the VM_MTE_ALLOWED flag, or if the file backing the mapping is
    shmem, in which case we set VM_MTE_ALLOWED in shmem_mmap() when the mmap
    hook is activated in mmap_region().

    The function that checks that, if VM_MTE is set, VM_MTE_ALLOWED is also
    set is the arm64 implementation of arch_validate_flags().

    Unfortunately, we intend to refactor mmap_region() to perform this check
    earlier, meaning that in the case of a shmem backing we will not have
    invoked shmem_mmap() yet, causing the mapping to fail spuriously.

    It is inappropriate to set this architecture-specific flag in general mm
    code anyway, so a sensible resolution of this issue is to instead move the
    check somewhere else.

    We resolve this by setting VM_MTE_ALLOWED much earlier in do_mmap(), via
    the arch_calc_vm_flag_bits() call.

    This is an appropriate place to do this as we already check for the
    MAP_ANONYMOUS case here, and the shmem file case is simply a variant of
    the same idea - we permit RAM-backed memory.

    This requires a modification to the arch_calc_vm_flag_bits() signature to
    pass in a pointer to the struct file associated with the mapping, however
    this is not too egregious as this is only used by two architectures anyway
    - arm64 and parisc.

    So this patch performs this adjustment and removes the unnecessary
    assignment of VM_MTE_ALLOWED in shmem_mmap().

    [akpm@linux-foundation.org: fix whitespace, per Catalin]
    Link: https://lkml.kernel.org/r/ec251b20ba1964fb64cf1607d2ad80c47f3873df.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:34 -03:00
Herton R. Krzesinski d26e403dfa parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards 
JIRA: https://issues.redhat.com/browse/RHEL-68912

commit 5d698966fa7b452035c44c937d704910bf3440dd
Author: Helge Deller <deller@kernel.org>
Date:   Sun Sep 8 20:51:17 2024 +0200

    parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards

    When userspace allocates memory with mmap() in order to be used for stack,
    allow this memory region to automatically expand upwards up until the
    current maximum process stack size.
    The fault handler checks if the VM_GROWSUP bit is set in the vm_flags field
    of a memory area before it allows it to expand.
    This patch modifies the parisc specific code only.
    A RFC for a generic patch to modify mmap() for all architectures was sent
    to the mailing list but did not get enough Acks.

    Reported-by: Camm Maguire <camm@maguirefamily.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org      # v5.10+

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:34 -03:00
Herton R. Krzesinski b20a7c8f16 prctl: generalize PR_SET_MDWE support check to be per-arch 
JIRA: https://issues.redhat.com/browse/RHEL-68912

commit d5aad4c2ca057e760a92a9a7d65bd38d72963f27
Author: Zev Weiss <zev@bewilderbeest.net>
Date:   Mon Feb 26 17:35:41 2024 -0800

    prctl: generalize PR_SET_MDWE support check to be per-arch

    Patch series "ARM: prctl: Reject PR_SET_MDWE where not supported".

    I noticed after a recent kernel update that my ARM926 system started
    segfaulting on any execve() after calling prctl(PR_SET_MDWE).  After some
    investigation it appears that ARMv5 is incapable of providing the
    appropriate protections for MDWE, since any readable memory is also
    implicitly executable.

    The prctl_set_mdwe() function already had some special-case logic added
    disabling it on PARISC (commit 793838138c15, "prctl: Disable
    prctl(PR_SET_MDWE) on parisc"); this patch series (1) generalizes that
    check to use an arch_*() function, and (2) adds a corresponding override
    for ARM to disable MDWE on pre-ARMv6 CPUs.

    With the series applied, prctl(PR_SET_MDWE) is rejected on ARMv5 and
    subsequent execve() calls (as well as mmap(PROT_READ|PROT_WRITE)) can
    succeed instead of unconditionally failing; on ARMv6 the prctl works as it
    did previously.

    [0] https://lore.kernel.org/all/2023112456-linked-nape-bf19@gregkh/

    This patch (of 2):

    There exist systems other than PARISC where MDWE may not be feasible to
    support; rather than cluttering up the generic code with additional
    arch-specific logic let's add a generic function for checking MDWE support
    and allow each arch to override it as needed.

    Link: https://lkml.kernel.org/r/20240227013546.15769-4-zev@bewilderbeest.net
    Link: https://lkml.kernel.org/r/20240227013546.15769-5-zev@bewilderbeest.net
    Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
    Acked-by: Helge Deller <deller@gmx.de>  [parisc]
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Florent Revest <revest@chromium.org>
    Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Mike Rapoport (IBM) <rppt@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Ondrej Mosnacek <omosnace@redhat.com>
    Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
    Cc: Russell King (Oracle) <linux@armlinux.org.uk>
    Cc: Sam James <sam@gentoo.org>
    Cc: Stefan Roesch <shr@devkernel.io>
    Cc: Yang Shi <yang@os.amperecomputing.com>
    Cc: Yin Fengwei <fengwei.yin@intel.com>
    Cc: <stable@vger.kernel.org>    [6.3+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:34 -03:00
Herton R. Krzesinski 78adbc699e prctl: Disable prctl(PR_SET_MDWE) on parisc 
JIRA: https://issues.redhat.com/browse/RHEL-68912

commit 793838138c157d4c49f4fb744b170747e3dabf58
Author: Helge Deller <deller@gmx.de>
Date:   Sat Nov 18 19:33:35 2023 +0100

    prctl: Disable prctl(PR_SET_MDWE) on parisc

    systemd-254 tries to use prctl(PR_SET_MDWE) for it's MemoryDenyWriteExecute
    functionality, but fails on parisc which still needs executable stacks in
    certain combinations of gcc/glibc/kernel.

    Disable prctl(PR_SET_MDWE) by returning -EINVAL for now on parisc, until
    userspace has catched up.

    Signed-off-by: Helge Deller <deller@gmx.de>
    Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Sam James <sam@gentoo.org>
    Closes: https://github.com/systemd/systemd/issues/29775
    Tested-by: Sam James <sam@gentoo.org>
    Link: https://lore.kernel.org/all/875y2jro9a.fsf@gentoo.org/
    Cc: <stable@vger.kernel.org> # v6.3+

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:34 -03:00
Herton R. Krzesinski a8c1cf1061 mm: refactor map_deny_write_exec() 
JIRA: https://issues.redhat.com/browse/RHEL-68912
Conflicts: this is a straight backport from v6.6 LTS branch, commit 3a6d8d3f1998
           at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

commit 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:56 2024 +0000

    mm: refactor map_deny_write_exec()

    [ Upstream commit 0fb4a7ad270b3b209e510eb9dc5b07bf02b7edaf ]

    Refactor the map_deny_write_exec() to not unnecessarily require a VMA
    parameter but rather to accept VMA flags parameters, which allows us to
    use this function early in mmap_region() in a subsequent commit.

    While we're here, we refactor the function to be more readable and add
    some additional documentation.

    Link: https://lkml.kernel.org/r/6be8bb59cd7c68006ebb006eb9d8dc27104b1f70.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:34 -03:00
Herton R. Krzesinski 30d48cc977 mm: unconditionally close VMAs on error 
JIRA: https://issues.redhat.com/browse/RHEL-68912
Conflicts: this is a straight backport from v6.6 LTS branch, commit a97fe6889b25
           at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

commit 4080ef1579b2413435413988d14ac8c68e4d42c8
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:55 2024 +0000

    mm: unconditionally close VMAs on error

    [ Upstream commit 4080ef1579b2413435413988d14ac8c68e4d42c8 ]

    Incorrect invocation of VMA callbacks when the VMA is no longer in a
    consistent state is bug prone and risky to perform.

    With regards to the important vm_ops->close() callback We have gone to
    great lengths to try to track whether or not we ought to close VMAs.

    Rather than doing so and risking making a mistake somewhere, instead
    unconditionally close and reset vma->vm_ops to an empty dummy operations
    set with a NULL .close operator.

    We introduce a new function to do so - vma_close() - and simplify existing
    vms logic which tracked whether we needed to close or not.

    This simplifies the logic, avoids incorrect double-calling of the .close()
    callback and allows us to update error paths to simply call vma_close()
    unconditionally - making VMA closure idempotent.

    Link: https://lkml.kernel.org/r/28e89dda96f68c505cb6f8e9fc9b57c3e9f74b42.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:33 -03:00
Herton R. Krzesinski 8891da5c62 mm: avoid unsafe VMA hook invocation when error arises on mmap hook 
JIRA: https://issues.redhat.com/browse/RHEL-68912
Conflicts: this is a straight backport from v6.6 LTS branch, commit cd3ed99fca8c
           at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

commit 3dd6ed34ce1f2356a77fb88edafb5ec96784e3cf
Author: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date:   Fri Nov 15 12:41:54 2024 +0000

    mm: avoid unsafe VMA hook invocation when error arises on mmap hook

    [ Upstream commit 3dd6ed34ce1f2356a77fb88edafb5ec96784e3cf ]

    Patch series "fix error handling in mmap_region() and refactor
    (hotfixes)", v4.

    mmap_region() is somewhat terrifying, with spaghetti-like control flow and
    numerous means by which issues can arise and incomplete state, memory
    leaks and other unpleasantness can occur.

    A large amount of the complexity arises from trying to handle errors late
    in the process of mapping a VMA, which forms the basis of recently
    observed issues with resource leaks and observable inconsistent state.

    This series goes to great lengths to simplify how mmap_region() works and
    to avoid unwinding errors late on in the process of setting up the VMA for
    the new mapping, and equally avoids such operations occurring while the
    VMA is in an inconsistent state.

    The patches in this series comprise the minimal changes required to
    resolve existing issues in mmap_region() error handling, in order that
    they can be hotfixed and backported.  There is additionally a follow up
    series which goes further, separated out from the v1 series and sent and
    updated separately.

    This patch (of 5):

    After an attempted mmap() fails, we are no longer in a situation where we
    can safely interact with VMA hooks.  This is currently not enforced,
    meaning that we need complicated handling to ensure we do not incorrectly
    call these hooks.

    We can avoid the whole issue by treating the VMA as suspect the moment
    that the file->f_ops->mmap() function reports an error by replacing
    whatever VMA operations were installed with a dummy empty set of VMA
    operations.

    We do so through a new helper function internal to mm - mmap_file() -
    which is both more logically named than the existing call_mmap() function
    and correctly isolates handling of the vm_op reassignment to mm.

    All the existing invocations of call_mmap() outside of mm are ultimately
    nested within the call_mmap() from mm, which we now replace.

    It is therefore safe to leave call_mmap() in place as a convenience
        function (and to avoid churn).  The invokers are:

         ovl_file_operations -> mmap -> ovl_mmap() -> backing_file_mmap()
        coda_file_operations -> mmap -> coda_file_mmap()
         shm_file_operations -> shm_mmap()
    shm_file_operations_huge -> shm_mmap()
                dma_buf_fops -> dma_buf_mmap_internal -> i915_dmabuf_ops
                                -> i915_gem_dmabuf_mmap()

    None of these callers interact with vm_ops or mappings in a problematic
    way on error, quickly exiting out.

    Link: https://lkml.kernel.org/r/cover.1730224667.git.lorenzo.stoakes@oracle.com
    Link: https://lkml.kernel.org/r/d41fd763496fd0048a962f3fd9407dc72dd4fd86.1730224667.git.lorenzo.stoakes@oracle.com
    Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails")
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Reported-by: Jann Horn <jannh@google.com>
    Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
    Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: Jann Horn <jannh@google.com>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Helge Deller <deller@gmx.de>
    Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2024-12-09 16:30:33 -03:00
Herton R. Krzesinski a9fc6882c8 redhat: do not compress the full kernel changelog in the src.rpm 
Bugzilla: INTERNAL
Upstream Status: RHEL only
commit d5862d7fec0a13869649f1286088c01c0f2a029d

By default redhat/scripts/expand_srpm.sh adds a .gitignore entry excluding any
*.xz file in dist-git, since those are usually tarballs which can get very large.

The problem is that kernel.changelog.xz file recently added gets excluded and
can't be commited to dist-git due that.

To avoid it, since src.rpm and git can compress contents and the updates
are incremental, just use the uncompressed contents when adding it to
the src.rpm, and only compress the file when providing it to the
kernel-doc package.

This fixes commit "redhat: ship all the changelog from source git into kernel-doc"
recently merged into kernel-ark.

Reported-by: Justin Forbes <jforbes@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-12-22 10:29:12 -03:00
Herton R. Krzesinski 5d1976deca redhat: ship all the changelog from source git into kernel-doc 
Bugzilla: INTERNAL
Upstream Status: RHEL only
commit 62e43932298ba88e66458dbf9dc99d36fb79a739

In the previous change, the rpm changelog will be trimmed due size
for each rpm binary on each minor release bump. However, someone may
still want to see the full changelog since the start of a given stream,
thus provide it in the src.rpm and through kernel-doc.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-12-22 10:29:12 -03:00
Herton R. Krzesinski d9935c2d8c redhat: create an empty changelog file when changing its name 
Bugzilla: INTERNAL
Upstream Status: RHEL only
Conflicts: adjusted the changes and commit message since the Makefile
           and other details differs from the current kernel-ark.
commit 9be0f5f3edfb9e5ed37d0c4b6c6cdcb4044ff78a

Up until now, if we rename the spec package name or bump the rhel major
or minor versions, we used to copy the previous changelog file if it
exists into the new one. However, this makes the changelog grow
indefinitely since a stream start, and it starts to get very big. We
do not need to keep the entire history at each new changelog file,
because eg. in a stream life, we always keep the older changelog files
in the git tree.

Thus, instead of copying the old changelog, just create a new empty
file. This also makes sure we trim the rpm changelog at each new minor
release, since it's used as the source of the rpm package changelog
content. And that's another intention with this change: to avoid having
the rpm changelog contents to grow too big, as reported by Brian Masney.

With this there is some simplification as well and we can remove the
CHANGELOG_PREV variable.

Also, trim current kernel.changelog-* files that already exist in the
Centos/RHEL-9 tree since we are adding this change in the middle of the
already ongoing rhel-9 existance, and remove the uneeded/unused
kernel.changelog-9.99 file. The "END OF CHANGELOG" marker is deleted
as well from all files as it's not used anymore since the change
"redhat: always add a rebase entry when ark merges from upstream".

Reported-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-12-22 10:29:08 -03:00
Herton R. Krzesinski 3c8c801dd9 redhat: fix bug/zjira sort in the changelog 
JIRA: INTERNAL
Upstream Status: RHEL only

Another small issue which I noted, even if it should become more rare as
time passes with Jira usage, is that if you have a mix of bugzilla and
jiras, it can list ystream bugs before zstream Jira issues.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-10-23 17:07:37 -03:00
Herton R. Krzesinski aa628b72c8 redhat: list Z-Jiras in the changelog before Y-Jiras 
Bugzilla: INTERNAL
Upstream Status: RHEL only

A while back Scott Weaver reported that when you have a zstream backport
referencing both y-stream and z-stream Jira issues, it would list in
them in the reverse order of what happens with bugzilla entries, eg.:

[2216500 2160149]
[RHEL-2160149 RHEL-2216500]

Thus keep the same behaviour as before, we list first the z-stream
tickets and then the related y-stream tickets in the kernel changelog.

Reported-by: Scott Weaver <scweaver@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-23 21:25:48 -03:00
Herton R. Krzesinski c6cee3b5a6 [redhat] kernel-5.14.0-354.el9 
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:17:48 +00:00
Herton R. Krzesinski 2b9026a7e7 Merge: Backport fixes for qcom-snps-femto-v2 PHY driver 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2887

JIRA: https://issues.redhat.com/browse/RHEL-1019

Backport fixes for qcom-snps-femto-v2 PHY driver

Signed-off-by: Adrien Thierry <athierry@redhat.com>

Approved-by: Eric Chanudet <echanude@redhat.com>
Approved-by: John B. Wyatt IV <jwyatt@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:16:42 +00:00
Herton R. Krzesinski 04711ea044 Merge: ext4: Fix generic/622 failure 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2884

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2228888
Tested: xfstests

Ext4 lazytime updates fail if the FS is mounted with i_version. Due recent updates
on ext4, making i_version enabled by default, generic/622 now fails on common tests
Fix this

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>

Approved-by: Pavel Reichl <preichl@redhat.com>
Approved-by: Bill O'Donnell <bodonnel@redhat.com>
Approved-by: Andrey Albershteyn <aalbersh@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:16:10 +00:00
Herton R. Krzesinski c05955eacf Merge: netfilter: nf_tables: Support resetting state in rules and set elements 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2864

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1925492
Upstream Status: all upstream in linus.git

Rule resetting code is in patch 2, it requires patch 1 as preliminary work.

Set element resetting code is in patch 6. It is useable by itself, but caused
some context conflicts. Backporting patches 3 and 4 avoids those, both are
useful and rather simple. Patch 5 is a fixup of patch 4.
    
Signed-off-by: Phil Sutter <psutter@redhat.com>

Approved-by: Florian Westphal <fwestpha@redhat.com>
Approved-by: Guillaume Nault <gnault@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:14:39 +00:00
Herton R. Krzesinski 39a0b866f9 Merge: Enable Nvidia backlight EC support to resolve backlight control issues 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2857

The backlight of the laptop equipped with Nvidia hybrid graphic can't be
configured and the user got a black screen when the system resumes working
from the suspend mode. To resolve this, the Nvidia backlight EC driver
should be backported to rhel from the upstream kernel. Dell had tested on
Precision 7780 and reported the backport worked.

A patch of filter_module.sh from Fedora was picked to avoid the dependency
problem while compiling the kernel. The ACPI_VIDEO module has a dependency
on the symbol wmi_evaluate_method. It needs to be added to otherwise it will
cause compile errors.

Build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=54324872

Tested: Dell partner tested it on Dell Precision 7780

The system configurations are:
- BIOS: 1.4.0
- Display mode: Hybrid Mode
- Nvidia driver: 525.116.04

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2185526

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2221211

Signed-off-by: Kate Hsuan <hpa@redhat.com>

Approved-by: Prarit Bhargava <prarit@redhat.com>
Approved-by: David Arcari <darcari@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:13:59 +00:00
Herton R. Krzesinski e5d248c4c6 Merge: mm/nvdimm: fix failure to install os on some ppc systems 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2836

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2217652

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>

Approved-by: Prarit Bhargava <prarit@redhat.com>
Approved-by: Rafael Aquini <aquini@redhat.com>
Approved-by: Chris von Recklinghausen <crecklin@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:12:45 +00:00
Herton R. Krzesinski fbe450b04b Merge: net: Enable HSR and PRP 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2590

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2177256

Enable hsr as a module to support the protocols HSR and PRP. Also add
relevant patches that were added since the release of kernel 5.14
upstream. The code required to use it is already in iproute.

Signed-off-by: Felix Maurer <fmaurer@redhat.com>

Approved-by: Hangbin Liu <haliu@redhat.com>
Approved-by: Paolo Abeni <pabeni@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-10 17:11:52 +00:00
Herton R. Krzesinski 62f30b9883 [redhat] kernel-5.14.0-353.el9 
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:38:26 +00:00
Herton R. Krzesinski eb87a6fb41 Merge: rbd: exclusive lock blocklisting and osd_request_timeout handling fixes 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2889

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2229303

Signed-off-by: Ilya Dryomov <idryomov@redhat.com>

Approved-by: Xiubo Li <xiubli@redhat.com>
Approved-by: Milind Changire <mchangir@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:36:32 +00:00
Herton R. Krzesinski 590f00e53b Merge: pinctrl: tegra: Add Tegra234 pinctrl driver to RHEL9 kernel 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2869

Tested: Booted kernel on Orin AGX. Files in /sys/kernel/debug/pinctrl/c360000.pmc/
indicated that the pins showed up

These patches add the Tegra234 pinctrl driver to the RHEL9 kernel

Signed-off-by: Joel Slebodnick <jslebodn@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2222432

Approved-by: David Arcari <darcari@redhat.com>
Approved-by: Steve Best <sbest@redhat.com>
Approved-by: Craig Magina <cmagina@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:35:30 +00:00
Herton R. Krzesinski ae7ee4a1ff Merge: KEYS: use kfree_sensitive with key 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2866

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2223719
Upstream Status: merged into herbert/cryptodev-2.6.git

Temporary values used for the integrity test for asymmetric
keys should be zeroized, which is required by FIPS 140-3.
See: https://issues.redhat.com/browse/FIPS-174

Signed-off-by: Vladis Dronov <vdronov@redhat.com>

Approved-by: Clemens Lang <cllang@redhat.com>
Approved-by: Herbert Xu <zxu@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:34:49 +00:00
Herton R. Krzesinski aeb01e4839 Merge: virtio_transport: temporarily do not depend on ANY_LAYOUT support 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2863

After commit 71dc9ec9ac7d (merged with !2602), the virtio-vsock
driver switched to a single descriptor for each RX packet.
This causes problems with other devices that did not exactly meet
the VIRTIO specification and relied on this implementation detail.

In particular, Amazon's nitro enclaves backend is broken completely
and the parent kernel hangs as soon as an enclave is started.
Deploying the fix to the whole EC2 fleet might or might not be
done in time for the 9.3 release.

This is RHEL only because the upstream maintainer @mstredhat
wants spec bugs to be fixed by the side that broke the spec.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2227177

Approved-by: Stefano Garzarella <sgarzare@redhat.com>
Approved-by: MST <mst@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:34:04 +00:00
Herton R. Krzesinski f364e0c1e8 Merge: i40e: Wait for pending VF reset in VF set callbacks 
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2849

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2215498
Tested: Using reproducer described in bugzilla

Commits:
df84f0ce569d ("i40e: Add helper for VF inited state check with timeout")
efb6f4a35954 ("i40e: Wait for pending VF reset in VF set callbacks")

Signed-off-by: Ivan Vecera <ivecera@redhat.com>

Approved-by: Corinna Vinschen <vinschen@redhat.com>
Approved-by: Michal Schmidt <mschmidt@redhat.com>
Approved-by: José Ignacio Tornos Martínez <jtornosm@redhat.com>

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>
 2023-08-09 16:32:55 +00:00