linux-kernel - Re: Make kstat_incr_irqs_this_cpu() called when an irq is actually being handled

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: <CAH3Oq6QxFmtTuZSdF=95FPugwu1AzMgHm650qmNUwsdLr9O8Rg@mail.gmail.com>
Date:	Fri, 1 Jun 2012 13:20:02 +0800
From:	Ning Jiang <ning.n.jiang@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Make kstat_incr_irqs_this_cpu() called when an irq is actually
 being handled

2012/6/1 Thomas Gleixner <tglx@...utronix.de>:
> On Thu, 31 May 2012, Ning Jiang wrote:
>> kstat_incr_irqs_this_cpu() is supposed to record the irq number
>> that is actually taken by a certain cpu. But it failed to do so
>> in its current form.
>
> It exactly counts the number of interrupts which are delivered to and
> handled by a CPU. That includes interrupts which are delivered in a
> state where the device handler cannot be called. And this is on
> purpose. We want to see the real number of interruptions not the
> number of calls to a device handler.
>
>> For level irq, if its disabled or no action available, we'll skip
>> irq handling. When it is enabled later, the irq will be retriggered
>> and kstat_incr_irqs_this_cpu() will be counted twice for this
>> single irq.
>
> This counts the number of interrupts arrived at the CPU and therefor
> it counts TWO in this situation. The CPU is interrupted twice, not
> once.
>

I've got your point. For level irq, no problem. But how do you account
for edge irq in my comments?

For edge irq, we'll not have the same problem as level irq because
kstat_incr_irqs_this_cpu() is placed after status checking for
disable or no action. But it has its own problem. Suppose a second
irq happens when the first is being handled, it will mark itself
pending and quit, then it will be handled in the same loop after the
first one has been handled. Thus kstat_incr_irqs_this_cpu() will
only be counted once for two irqs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/