linux-kernel - Re: [tip:core/rcu] rcu: Fix holdoff for accelerated GPs for last non-dynticked CPU

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: <20100316110036.GA4554@elte.hu>
Date:	Tue, 16 Mar 2010 12:00:36 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	mingo@...hat.com, hpa@...or.com, paulmck@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/rcu] rcu: Fix holdoff for accelerated GPs for last
 non-dynticked CPU


* tip-bot for Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:

> Commit-ID:  622ea685f1fafdf84d612440535c84341f0860b8
> Gitweb:     http://git.kernel.org/tip/622ea685f1fafdf84d612440535c84341f0860b8
> Author:     Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> AuthorDate: Sat, 27 Feb 2010 14:53:07 -0800
> Committer:  Ingo Molnar <mingo@...e.hu>
> CommitDate: Sun, 28 Feb 2010 09:17:42 +0100
> 
> rcu: Fix holdoff for accelerated GPs for last non-dynticked CPU
> 
> Make the holdoff only happen when the full number of attempts
> have been made.

hm, i started seeing boot crashes on a testbox, and bisected it back to:

| 622ea685f1fafdf84d612440535c84341f0860b8 is the first bad commit
| commit 622ea685f1fafdf84d612440535c84341f0860b8
| Author: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
| Date:   Sat Feb 27 14:53:07 2010 -0800
|
|     rcu: Fix holdoff for accelerated GPs for last non-dynticked CPU

Config attached. I have no bootlog, unfortunately.

Unfortunately #2: reverting the commit still causes a crash - so it could be a 
combination bug and a mis-bisection ...

(the bisection itself was an automated run)

Any ideas?
  
	Ingo

View attachment "config" of type "text/plain" (68542 bytes)