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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Dec 2020 15:30:54 +0100 From: Frederic Weisbecker <frederic@...nel.org> To: Qais Yousef <qais.yousef@....com> Cc: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, Tony Luck <tony.luck@...el.com>, Vasily Gorbik <gor@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Paul Mackerras <paulus@...ba.org>, Christian Borntraeger <borntraeger@...ibm.com>, Fenghua Yu <fenghua.yu@...el.com>, Heiko Carstens <hca@...ux.ibm.com> Subject: Re: [PATCH 4/5] irqtime: Move irqtime entry accounting after irq offset incrementation On Tue, Dec 29, 2020 at 02:12:31PM +0000, Qais Yousef wrote: > On 12/29/20 14:41, Frederic Weisbecker wrote: > > > > -void vtime_account_irq(struct task_struct *tsk) > > > > +void vtime_account_irq(struct task_struct *tsk, unsigned int offset) > > > > { > > > > - if (hardirq_count()) { > > > > + unsigned int pc = preempt_count() - offset; > > > > + > > > > + if (pc & HARDIRQ_OFFSET) { > > > > > > Shouldn't this be HARDIRQ_MASK like above? > > > > In the rare cases of nested hardirqs happening with broken drivers, Only the outer hardirq > > does matter. All the time spent in the inner hardirqs is included in the outer > > one. > > Ah I see. The original code was doing hardirq_count(), which apparently wasn't > right either. > > Shouldn't it be pc == HARDIRQ_OFFSET then? All odd nest counts will trigger > this otherwise, and IIUC we want this to trigger once on first entry only. Right but we must also handle hardirqs interrupting either preempt disabled sections or softirq servicing/disabled section. 3 stacking hardirqs should be rare enough that we don't really care. In the worst case we are going to account the third IRQ seperately. Not a correctness issue, just a rare unoptimized case. > > Thanks > > -- > Qais Yousef
Powered by blists - more mailing lists