linux-kernel - Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")

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: <20190205185914.GB16356@darkstar.musicnaut.iki.fi>
Date:   Tue, 5 Feb 2019 20:59:14 +0200
From:   Aaro Koskinen <aaro.koskinen@....fi>
To:     Tom Li <tomli@...li.me>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Ville Syrjälä 
        <ville.syrjala@...ux.intel.com>
Cc:     ak@...ux.intel.com, bp@...en8.de, hpa@...or.com,
        linux-kernel@...r.kernel.org, mingo@...hat.com, rjw@...ysocki.net,
        viresh.kumar@...aro.org, linux-mips@...r.kernel.org
Subject: Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API
 in terms of RCU for Tree RCU PREEMPT builds")

Hi,

On Tue, Feb 05, 2019 at 09:05:59PM +0800, Tom Li wrote:
> On Tue, Feb 05, 2019 at 11:58:09AM +0200, Aaro Koskinen wrote:
> > Can you try below fix? It works on my Loongson.
> 
> Hello Aaro, thanks for your response. But in case you've missed
> the original thread, please check it at:
> 
> https://lkml.org/lkml/2018/11/13/857

OK, thanks. This looks slightly different from the Loongson problem:

- In Loongson, we don't get stuck in RCU, but in
  cpufreq_dbs_governor_stop -> irq_work_sync(). 

- I run non-preemptible kernel, and my system still gets stuck.

What is common is that it's UP with i8259 PIC.

> My problem is NOT about how to fix the problem on Loongson (or
> x86): the patch in the original thread (only has one-line-of-code,
> simply changes timing of cpufreq_core_init), or your patch, is
> indeed working. But they are workarounds, the real issue is the race
> condition in cpufreq.

Looking at irq_work_sync(), I cannot think how it could work on UP
machine with interrupts disabled.

A.