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
| ||
|
Date: Mon, 16 May 2011 09:08:08 +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: > > 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. > > In hindsight, that certainly would have been better. This is the Linux kernel and we *can* turn back the clock! > I was afraid of that... > > On the off-chance that moving the memory barriers was at fault, the following > patch restores all of them that don't have in situ replacements. Grasping at > straws, admittedly. Well, the nice thing is that we really do not have to grasp at straws, and even while we have no good ideas we can debug this *much* better. Could you please do a simple test-tree that does has 3 commits: first one reverts the offending commit second one applies the barrier part of it this one applies the need_resched part of it ( You can do even more finegrained steps, if you find harmless-looking bits of it that can be applied separately! ) Note, the important thing is that the tree should be a 'null pull' - i.e. the revert plus the patches applied will not change anything in core/rcu. Obviously it would be nice if each step built fine - no need to boot test each step as long as you are reasonably sure it will boot fine. Then i could take my reproducer and come up with a very precise bisection result for you, with just a couple of minutes time spent on testing. One of the commits after the revert will trigger the hang/slowdown. My prediction is that we will be much wiser after that! :-) 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/
Powered by blists - more mailing lists