linux-kernel - Interrupt synchronisation questions for SMP experts

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>] [day] [month] [year] [list]

Message-ID: <20090211181431.47f42dde@xilun.lan.proformatique.com>
Date:	Wed, 11 Feb 2009 18:14:31 +0100
From:	Guillaume Knispel <gknispel@...formatique.com>
To:	<linux-kernel@...r.kernel.org>
Subject: Interrupt synchronisation questions for SMP experts

Hi,

1. Imagine an interrupt storm from an evil device on an evil SMP
machine, is there any guarantee that if the ISR call
disable_irq_nosync() on its own irq it won't be called again just after
it returns?  I feel this could be a reasonable expectation while i fail
to see anything that could provide it in the for (;;) loop of
__do_IRQ().

2. Does using synchronizing functions like disable_irq(),
tasklet_kill(), or del_timer_sync() provide sequentiality between the
effects of the end of the interrupt servicing code and the effects of
the code immediately after the call to the synchronizing function?

3. Consider this:

(a initially set to 0)
  CPU 1.          CPU 2.

  z = 3;          while (!a) barrier();
  smp_wmb();      smp_mb();
  a = 1;          z = 42;

Does the semantic of smp_mb() and smp_wmb() guarantee that the final
value of z will be 42?  (This has something to do with 2.)

Cheers,
Guillaume KNISPEL
--
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/