From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751421AbdINF1c (ORCPT ); Thu, 14 Sep 2017 01:27:32 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36920 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbdINF13 (ORCPT ); Thu, 14 Sep 2017 01:27:29 -0400 X-Google-Smtp-Source: AOwi7QD0ths4MVRDNxvaHdvIZb4jR55W8qQ0lS53rpdCXjxX91bGj92f98lgPEDd9c5jpRMQf4i23w== Date: Thu, 14 Sep 2017 07:27:25 +0200 From: Ingo Molnar To: Don Zickus Cc: Thomas Gleixner , LKML , Peter Zijlstra , Borislav Petkov , Andrew Morton , Sebastian Siewior , Nicholas Piggin , Chris Metcalf , Ulrich Obergfell Subject: Re: [patch V2 00/29] lockup_detector: Cure hotplug deadlocks and replace duct tape Message-ID: <20170914052725.hbtmsgrf7ri6x5v5@gmail.com> References: <20170912193654.321505854@linutronix.de> <20170913180642.ywrszlfziobv7yiu@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170913180642.ywrszlfziobv7yiu@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Don Zickus wrote: > On Tue, Sep 12, 2017 at 09:36:54PM +0200, Thomas Gleixner wrote: > > The lockup detector is broken is several ways: > > > > - It's deadlock prone vs. CPU hotplug in various ways. Some of these > > are due to recursive cpus_read_lock() others are due to > > cpus_read_lock() from CPU hotplug callbacks which immediately lock > > the machine because cpus are write locked. > > > > - The handling of the cpu hotplug threads happens sideways to the > > smpboot thread infrastructure, which is racy and pointless > > > > - The handling of the user space sysctl interface is a complete > > trainwreck as it fiddles directly with variables which can be > > modified or evaluated by the running watchdogs. > > > > - The perf event initialization is a trainwreck as it tries to create > > perf events over and over even if perf is not functional (no > > hardware, ....). To avoid excessive dmesg spam it contains magic > > printk ratelimiting along with either wrong or useless messages. > > > > - The code structure is horrible as ifdef sections are scattered all > > over the place which makes it unreadable > > > > - There is more wreckage, but see the changelogs for the ugly details. > > > > Aside from the simple compile issue in patch 25. I have no issues with this > patchset. Thanks Thomas! > > Reviewed-by: Don Zickus Thanks guys! I've applied the series and will push it out after some testing. Thanks, Ingo