linux-kernel - Re: [PATCH 2/2] rcutorture: Nudge ksoftirqd priority for RCU boost testing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87mtpw9kiz.mognet@arm.com>
Date:   Thu, 05 Aug 2021 12:51:48 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     paulmck@...nel.org
Cc:     linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
        linux-rt-users@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Frederic Weisbecker <frederic@...nel.org>,
        Josh Triplett <josh@...htriplett.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH 2/2] rcutorture: Nudge ksoftirqd priority for RCU boost testing

On 04/08/21 15:53, Paul E. McKenney wrote:
> On Wed, Aug 04, 2021 at 11:18:11AM +0100, Valentin Schneider wrote:
>>
>> Hm so v5.13-rt1 has this commit:
>>
>>   5e59fba573e6 ("rcutorture: Fix testing of RCU priority boosting")
>>
>> which gates RCU boost torture testing under CONFIG_PREEMPT_RT. Now, AFAICT
>> the TIMER_SOFTIRQ priority problem is there regardless of
>> CONFIG_PREEMPT_RT, so this patch would (should?) make sense even on
>> !CONFIG_PREEMPT_RT.
>
> What rcutorture scenario TREE03 does is to boot with tree.use_softirq=0
> and threadirqs.  I see your point about timers and softirq, but this
> does run reliably for me.
>
> Ah, I see why.  Commit ea6d962e80b6 ("rcutorture: Judge RCU priority
> boosting on grace periods, not callbacks") includes boosting the priority
> of the ksoftirqd kthreads.  But only when running rcutorture builtin,
> not as a module.  Here is the code in rcu_torture_init():
>
>               // Testing RCU priority boosting requires rcutorture do
>               // some serious abuse.  Counter this by running ksoftirqd
>               // at higher priority.
>               if (IS_BUILTIN(CONFIG_RCU_TORTURE_TEST)) {
>                       for_each_online_cpu(cpu) {
>                               struct sched_param sp;
>                               struct task_struct *t;
>
>                               t = per_cpu(ksoftirqd, cpu);
>                               WARN_ON_ONCE(!t);
>                               sp.sched_priority = 2;
>                               sched_setscheduler_nocheck(t, SCHED_FIFO, &sp);
>                       }
>               }
>
> I take it that you were running rcutorture as a module?
>
> This describes how to run it built-in, if that works for you:
>
> https://paulmck.livejournal.com/61432.html
>
> More specifically: https://paulmck.livejournal.com/57769.html
>
> Alternatively, the "IS_BUILTIN(CONFIG_RCU_TORTURE_TEST)" check could be
> removed in the above code, and the ksoftirqd kthreads could have their
> original priority restored in rcu_torture_cleanup().
>
> Thoughts?
>

I actually run rcutorture as a builtin, but from what I can tell the above
patch came in v5.14-rc1, and ofc I'm running my tests on v5.13-rt1... I
should have paid closer attention to what was in the latest mainline,
apologies for the noise. 

FWIW tweaking ksoftirqd priority only when the torture module is builtin
makes sense to me.