linux-kernel - Re: [patch 17/29] lockup_detector: Get rid of the thread teardown/setup dance

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 1 Sep 2017 21:45:07 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Don Zickus <dzickus@...hat.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        Sebastian Siewior <bigeasy@...utronix.de>,
        Nicholas Piggin <npiggin@...il.com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Ulrich Obergfell <uobergfe@...hat.com>
Subject: Re: [patch 17/29] lockup_detector: Get rid of the thread teardown/setup
 dance

On Fri, 1 Sep 2017, Don Zickus wrote:
> On Thu, Aug 31, 2017 at 09:16:15AM +0200, Thomas Gleixner wrote:
> > The lockup detector reconfiguration tears down all watchdog threads when
> > the watchdog is disabled and sets them up again when its enabled.
> > 
> > That's a pointless exercise. The watchdog threads are not consuming an
> > insane amount of resources, so it's enough to set them up at init time and
> > keep them in parked position when the watchdog is disabled and unpark them
> > when it is reenabled. The smpboot thread infrastructure takes care of
> > keeping the force parked threads in place even across cpu hotplug.
> 
> The original reasoning for implementing this complexity was we were worried
> about catching kthread_[un]park errors.  It was thought in the rare case if
> it failed, we would hang.  Perhaps we misunderstood the kthread_[un]park
> code.

park is waiting for the thread to reach park position. So if this fails,
then the thread which invoked the parking will be stuck forever.

the unpark is async, i.e. it just kicks the thread out of park position and
let it run.

So you cannot catch anything with your open coding as it just uses the same
mechanisms as the smpboot infrastructure does.

Thanks,

	tglx