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: Sun, 16 Jul 2017 23:21:50 -0700 From: Tony Lindgren <tony@...mide.com> To: Pavel Machek <pavel@....cz> Cc: Sebastian Reichel <sebastian.reichel@...labora.co.uk>, Thomas Gleixner <tglx@...x.de>, Linus Torvalds <torvalds@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Linus Walleij <linus.walleij@...aro.org>, Grygorii Strashko <grygorii.strashko@...com> Subject: Re: [GIT pull] irq updates for 4.13 * Pavel Machek <pavel@....cz> [170715 13:24]: > Hi! > > > > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote: > > > > [...] > > > > > > > > Here is a revised version of the previous patch with the conditional > > > > locking removed and a bunch of comments added. > > > > > > That one also fixes Droid 4 boot. > > > > > > Tested-by: Sebastian Reichel <sebastian.reichel@...labora.co.uk> > > > > Sill works for me too: > > > > Tested-by: Tony Lindgren <tony@...mide.com> > > I seen the announcement > > Date: Wed, 12 Jul 2017 01:18:50 -0700 > From: tip-bot for Thomas Gleixner <tipbot@...or.com> > To: linux-tip-commits@...r.kernel.org > Subject: [tip:irq/urgent] genirq: Keep chip buslock across > irq_request/release_resources() > > But I don't see the commit in 4.13-rc0. Could we get it in now, so > that problem is fixed in -rc1? Seems we missed that for -rc1. In general, I've noticed that the rule of having code sit in next before the merge window really helps preventing regressions during the merge window. That is as long people keep testing next on almost daily basis and report regressions promptly.. and I do just to avoid chasing regressions during the -rc cycle. And the real reason why I think catching the regressions in next helps is the fact that people react to regressions much faster to revert patches compared to after things get merged into the mainline kernel :p In this case Thomas reacted within hours and fixed the issue, so no issues there and thanks for doing that. But we still got -rc1 with a regression that probably could have been prevented with enough time in next. So maybe we should be more strict with the next requirement? Just sayin. Tony
Powered by blists - more mailing lists