linux-kernel - Re: 'global' rq->clock

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]

Date:	Sun, 4 May 2008 01:38:25 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	benh@...nel.crashing.org, a.p.zijlstra@...llo.nl, efault@....de,
	elendil@...net.nl, parag.warudkar@...il.com,
	linux-kernel@...r.kernel.org, guichaz@...oo.fr, andi@...stfloor.org
Subject: Re: 'global' rq->clock


* David Miller <davem@...emloft.net> wrote:

> From: David Miller <davem@...emloft.net>
> Date: Sat, 03 May 2008 16:04:08 -0700 (PDT)
> 
> > From: Ingo Molnar <mingo@...e.hu>
> > Date: Sun, 4 May 2008 00:38:44 +0200
> > 
> > > the same bug existed on x86 too: that too does a few IPIs without 
> > > irq_enter/irq_exit. We now removed the softlockup dependency so it 
> > > should not be required to do an irq_enter()/exit anymore - unless the 
> > > code that the IPI uses accesses jiffies. (but that would be unusual)
> > 
> > That move doesn't solve the problem, I'm strongly certain
> > arch's still need to add the irq_{enter,exit}().
> > 
> > I'll revert the irq_{enter,exit}() changes on one of my
> > sparc64 boxes to validate this later today.
> 
> False alarm, which is good news, thanks Ingo.  I can revert the 
> following it seems:
> 
> commit 2664ef44cf5053d2b7dff01cecac70bc601a5f68
> Author: David S. Miller <davem@...emloft.net>
> Date:   Fri Apr 25 03:11:37 2008 -0700
> 
>     [SPARC64]: Wrap SMP IPIs with irq_enter()/irq_exit().

ah, good! It really looks like unnecessary overhead for the "simple 
IPIs". But ... i'm wondering ... what about softirq processing? Do these 
IPIs process softirqs on the way out? In that case the non-processed 
jiffies might be a problem.

it's all a bit messy. I wish we could start turning jiffies into a 
function (which would just read GTOD and estimate jiffies from there), 
but i fear we are not there yet ...

	Ingo
--
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/