linux-kernel - Re: [PATCH] interrupt: discover and disable very frequent interrupts

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: <87tu4dhhh2.wl-maz@kernel.org>
Date:   Sun, 09 Oct 2022 03:13:29 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     "Zhang Xincheng" <zhangxincheng@...ontech.com>
Cc:     "tglx" <tglx@...utronix.de>,
        "linux-kernel" <linux-kernel@...r.kernel.org>,
        "oleksandr" <oleksandr@...alenko.name>,
        "Hans de Goede" <hdegoede@...hat.com>,
        "bigeasy" <bigeasy@...utronix.de>,
        "mark.rutland" <mark.rutland@....com>,
        "michael" <michael@...le.cc>
Subject: Re: [PATCH] interrupt: discover and disable very frequent interrupts

On Sun, 09 Oct 2022 02:31:36 +0100,
"=?utf-8?B?WmhhbmcgWGluY2hlbmc=?=" <zhangxincheng@...ontech.com> wrote:
> 
> > Again: what makes you think that it is better to kill the interrupt
> > than suffering a RCU stall? Yes, that's a lot of interrupts. But
> > killing it and risking the whole system isn't an acceptable outcome.
> 
> It's really not good to kill interrupts directly.

I'm glad you finally agree, (202210081220.9da0a329-yujie.liu@...el.com
has a good example of a perfectly working machine that your patch
kills for no reason).

> Perhaps a better way is
> to report it and let the system administrator decide what to do with it.
> 
> + if((desc->gap_count & 0xffff0000) == 0)
> + desc->gap_time = get_jiffies_64();
> +
> + desc->gap_count ++;
> +
> + if((desc->gap_count & 0x0000ffff) >= 2000) {
> + if((get_jiffies_64() - desc->gap_time) < HZ) {
> + desc->gap_count += 0x00010000;
> + desc->gap_count &= 0xffff0000;
> + } else {
> + desc->gap_count = 0;
> + }
> +
> + if((desc->gap_count >> 16) > 30) {
> + __report_bad_irq(desc, action_ret, KERN_ERR "irq %d: triggered too frequently\n");
> + }
> + }
> +

I don't think this is much better. You hardcode values that only make
sense on your HW, and for nobody else. And what can the user do with
this message? Nothing at all. The message itself only contributes to
problem. As it is, this patch is only a nuisance.

As I said before, this would be much better as a rate-limiter, with
configurable limits, and behind a debug option.

	M.

-- 
Without deviation from the norm, progress is not possible.