linux-kernel - Re: [GIT PULL rcu/next] rcu commits for 2.6.40

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: <20110513150744.GE32688@elte.hu>
Date:	Fri, 13 May 2011 17:07:44 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Yinghai Lu <yinghai@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL rcu/next] rcu commits for 2.6.40


* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:

> On Fri, May 13, 2011 at 03:12:18PM +0200, Ingo Molnar wrote:
> > 
> > * Ingo Molnar <mingo@...e.hu> wrote:
> > 
> > > I started bisecting this, and the two relevant endpoints:
> > > 
> > >   bad: 11c476f: net,rcu: convert call_rcu(prl_entry_destroy_rcu) to kfree
> > >  good: 0ee5623f: Linux 2.6.39-rc6
> > > 
> > > very clearly indicate that this is an RCU regression.
> > 
> > This might be the same one Yinghai found:
> > 
> >  e59fb3120bec: rcu: Decrease memory-barrier usage based on semi-formal proof
> > 
> > So with the config i sent it's definitely reproducible.
> > 
> > At first sight couldnt this be related not to barriers, but to not setting 
> > need_resched() like we did before?
> 
> Thank you both!!!  I had inspected the commit, but missed the fact that
> the new version refuses to call set_need_resched() if irqs are enabled.  :-(
> The following (untested) patch restores the set_need_resched() operation.

Btw., in hindsight, e59fb3120bec was a tad big, which made analysis harder.

Would it have been possible to split it in two, one for the movement of the 
notifiers, the other for the barrier changes?

That way the bisection would have fingered the movement commit. Or so.

> Does this help?

No, unfortunately not, the long delay is still there:

device: 'ttyS0': device_add
PM: Adding info for No Bus:ttyS0
INFO: rcu_sched_state detected stalls on CPUs/tasks: { 0} (detected by 1, t=6002 jiffies)

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/