linux-kernel - Re: [RFC GIT Pull V2] core watchdog sanitizing

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] [day] [month] [year] [list]

Date:   Sun, 8 Oct 2017 11:40:44 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Don Zickus <dzickus@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [RFC GIT Pull V2] core watchdog sanitizing

On Fri, Oct 06, 2017 at 12:06:42AM +0200, Thomas Gleixner wrote:
> Linus,
> 
> please consider to pull the latest core-watchdog-for-linus git tree from:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-watchdog-for-linus
> 
> The watchdog (hard/softlockup detector) code is pretty much broken in its
> current state. The patch series addresses this by removing all duct tape
> and refactoring it into a workable state.
> 
> The reasons why I ask for inclusion that late in the cycle are:
> 
>   1) The code causes lockdep splats vs. hotplug locking which get reported
>      over and over. Unfortunately there is no easy fix.
> 
>   2) The risk of breakage is minimal because it's already broken
> 
>   3) As 4.14 is a long term stable kernel, I prefer to have working
>      watchdog code in that and the lockdep issues resolved. I wouldn't ask
>      you to pull if 4.14 wouldn't be a LTS kernel or if the solution would
>      be easy to backport.

{sigh}

This is exactly what I did _NOT_ want to ever see happen when I did the
"let's announce the LTS kernels ahead of time" :(

I think I have to go back to the "announce them after the fact", as
pushing crap in before it is really ready is not acceptable.

I'd rather take "much more difficult to backport" issue than this "cram
it in now as we have a deadline to make".

We've been down this path before, and it was not good, there's a reason
our every 2-3 month release cycle works, and it is not because we take
stuff before it really is ready.

thanks,

greg k-h