linux-kernel - Re: [GIT pull] irq updates for 4.13

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: <20170717062150.GD10026@atomide.com>
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