Re: [lkp-robot] [sched/fair] fbd5188493: WARNING:inconsistent_lock_state

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

On 07/05/2018 10:58 AM, Dietmar Eggemann wrote:
> Hi,
> 
> On 07/05/2018 10:02 AM, kernel test robot wrote:
>>
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: fbd51884933192c9cada60628892024495942482 ("[PATCH] sched/fair: Avoid divide by zero when rebalancing domains")
>> url: https://github.com/0day-ci/linux/commits/Matt-Fleming/sched-fair-Avoid-divide-by-zero-when-rebalancing-domains/20180705-024633
>>
>>
>> in testcase: trinity
>> with following parameters:
>>
>> 	runtime: 300s
>>
>> test-description: Trinity is a linux system call fuzz tester.
>> test-url: http://codemonkey.org.uk/projects/trinity/
>>
>>
>> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
> 
> [...]
> 
>> [    0.335612] WARNING: inconsistent lock state
> 
> I get the same on arm64 (juno r0) during boot consistently:

Moving the code from _nohz_idle_balance to nohz_idle_balance let it disappear:

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 02be51c9dcc1..070924f07c68 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9596,16 +9596,6 @@ static bool _nohz_idle_balance(struct rq *this_rq, unsigned int flags,
         */
        smp_mb();
 
-       /*
-        * Ensure this_rq's clock and load are up-to-date before we
-        * rebalance since it's possible that they haven't been
-        * updated for multiple schedule periods, i.e. many seconds.
-        */
-       raw_spin_lock_irq(&this_rq->lock);
-       update_rq_clock(this_rq);
-       cpu_load_update_idle(this_rq);
-       raw_spin_unlock_irq(&this_rq->lock);
-
        for_each_cpu(balance_cpu, nohz.idle_cpus_mask) {
                if (balance_cpu == this_cpu || !idle_cpu(balance_cpu))
                        continue;
@@ -9701,6 +9691,16 @@ static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
        if (!(flags & NOHZ_KICK_MASK))
                return false;
 
+       /*
+        * Ensure this_rq's clock and load are up-to-date before we
+        * rebalance since it's possible that they haven't been
+        * updated for multiple schedule periods, i.e. many seconds.
+        */
+       raw_spin_lock_irq(&this_rq->lock);
+       update_rq_clock(this_rq);
+       cpu_load_update_idle(this_rq);
+       raw_spin_unlock_irq(&this_rq->lock);
+
        _nohz_idle_balance(this_rq, flags, idle);
 
        return true;