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-next>] [day] [month] [year] [list]
Message-ID: <20171201122605.GD1612@linutronix.de>
Date:   Fri, 1 Dec 2017 13:26:05 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Daniel Wagner <wagi@...om.org>, linux-rt-users@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Null pointer 4.14.1-rt3

On 2017-11-30 11:35:33 [-0500], Steven Rostedt wrote:
> Hmm, I'm not sure I tested this on a UP machine. Perhaps I should boot
> with CPUs=1

It does not crash everywhere. For instance Dra7x, imx6 do not crash
because they have GICv3 which does set required SMP function even on UP
systems. BBB which uses the ti,am33xx-intc / INTC does not and here we
boom.
>From what I see (in qemu) it won't explode on a x86-SMP config with one
CPU either because it sets that function, too (on APIC).

For RT it is enough to start one cyclictest. For !RT it looks to be
enough to enable SW-Watchdog and RCU boosting and I see 
	pull_rt_task() -> tell_cpu_to_push -> irq_work_queue_on()
on v4.14.2 with "sched/rt: Simplify the IPI based RT balancing logic"

Now, what do we do about it?
- does it make sense to tell tell_cpu_to_push() to not do anything if
  the target CPU is the same as the current?

- irq_work_queue() uses arch_irq_work_raise() which has a check (on ARM)
  and uses it only if it is really on SMP. The other user of
  arch_send_call_function_single_ipi() is generic_exec_single() and this
  one skips the invocation if target CPU == current CPU and invokes the
  function directly. We could invoke arch_irq_work_raise() instead for
  "local" case.

- disable RT_PUSH_IPI if booted on UP. After all there is not much
  benefit here, is there?

- make a requirement for working arch_send_call_function_single_ipi()
  but I guess invoking code for no reason make no sense.

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ