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: <20190206012214.GA25642@x220>
Date:   Wed, 6 Feb 2019 09:22:14 +0800
From:   tomli@...li.me
To:     Aaro Koskinen <aaro.koskinen@....fi>,
        "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")

> 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.
> 
> A.

Now it's an interesting case. Because on my machine, the problem I
encountered seems to be the identical one of the original thread,
disabling preempting can effectively solve the lockup. Also, my
issue is not only occuring on 4.20-rc1, but also on earlier kernels,
with a lower probability.

But on your machine, you have another non-identical, but closely-
related issue. It seems the timing-dependent lockup of i8259 PIC can
be triggered in different ways.

The conclusion is clear though, there's a real lockup condition in
i8259 PIC driver, and it's causing real issues.  Aaro, have you tried
submitting your i8259 patch to the mainline? Despite your concerns
about its underlying cause, I think a fix should be submitted. If there
are no objections from the maintainers, I suggest submitting it to the
mainline upstream, and send it to linux-stable, requesting it to be
applied on 3.16, 4.4, 4.9, 4.14, 4.19, 4.20 stable branches. If you
are busy, I can help submitting.

Tom Li

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ