linux-kernel - Re: [clocksource] 8c30ace35d: WARNING:at_kernel/time/clocksource.c:#clocksource

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: <20210429230411.GK4032392@tassilo.jf.intel.com>
Date:   Thu, 29 Apr 2021 16:04:11 -0700
From:   Andi Kleen <ak@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     paulmck@...nel.org, Feng Tang <feng.tang@...el.com>,
        kernel test robot <oliver.sang@...el.com>,
        0day robot <lkp@...el.com>,
        John Stultz <john.stultz@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Mark Rutland <Mark.Rutland@....com>,
        Marc Zyngier <maz@...nel.org>,
        Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        kernel-team@...com, neeraju@...eaurora.org,
        zhengjun.xing@...el.com, x86@...nel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [clocksource]  8c30ace35d:
 WARNING:at_kernel/time/clocksource.c:#clocksource_watchdog

> > The idea is to leave the watchdog code in kernel/time/clocksource.c,
> > but to move the fault injection into kernel/time/clocksourcefault.c or
> > some such.  In this new file, new clocksource structures are created that
> > use some existing timebase/clocksource under the covers.  These then
> > inject delays based on module parameters (one senstive to CPU number,
> > the other unconditional).  They register these clocksources using the
> > normal interfaces, and verify that they are eventually marked unstable
> > when the fault-injection parameters warrant it.  This is combined with
> > the usual checking of the console log.
> >
> > Or am I missing your point?
> 
> That's what I meant.

I still think all this stuff should be in the fault injection framework,
like other fault injections, to have a consistent discoverable interface. 

I actually checked now and the standard fault injection supports boot arguments,
so needing it at boot time shouldn't be a barrier.

-Andi