linux-kernel - Re: [RFC] Make need_resched() return true when rcu_urgent

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: <1531313902.8759.48.camel@infradead.org>
Date:   Wed, 11 Jul 2018 13:58:22 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     paulmck@...ux.vnet.ibm.com
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Hillenbrand, Marius" <mhillenb@...zon.com>
Subject: Re: [RFC] Make need_resched() return true when rcu_urgent_qs
 requested

On Wed, 2018-07-11 at 05:51 -0700, Paul E. McKenney wrote:
> 
> Interesting.  (I am assuming that the guest is printing these messages,
> not the host, but please let me know if my assumption is incorrect.)

No, this is all in the host. When the VMM (qemu, etc.) opens more files
and has to expand its fd_table, the threads which are currently in
KVM's vcpu_run() are making synchronize_sched() take multiple seconds.

> Are the CPUs saturated?  If so, could you please try booting with
> rcutree.kthread_prio=2?  If that prevents the messages from happening,
> then I need to put some work into guaranteeing forward progress.
> Otherwise, I need to figure out why the setting of rcu_urgent_qs is
> being ignored.

The CPUs shouldn't be saturated. The guest is fairly much idle. I can
best reproduce this by starting up the guest and then assigning a new
PCI device. At that point fairly much nothing is happening at all.

> I will assume the latter for the moment and see if I can spot the
> problem.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)