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  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

Powered by blists - more mailing lists