1. 07 Jun, 2014 10 commits
    • Thomas Gleixner's avatar
      clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup · 35c726c1
      Thomas Gleixner authored
      commit 30ccf03b upstream.
      
      The starting cpu is not yet in the online mask so irq_set_affinity()
      fails which results in per cpu timers for this cpu ending up on some
      other online cpu, ususally cpu 0.
      
      Use irq_force_affinity() which disables the online mask check and
      makes things work.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Link: http://lkml.kernel.org/r/20140416143316.106665251@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      35c726c1
    • Thomas Gleixner's avatar
      genirq: Allow forcing cpu affinity of interrupts · 8f141082
      Thomas Gleixner authored
      commit 01f8fa4f upstream.
      
      The current implementation of irq_set_affinity() refuses rightfully to
      route an interrupt to an offline cpu.
      
      But there is a special case, where this is actually desired. Some of
      the ARM SoCs have per cpu timers which require setting the affinity
      during cpu startup where the cpu is not yet in the online mask.
      
      If we can't do that, then the local timer interrupt for the about to
      become online cpu is routed to some random online cpu.
      
      The developers of the affected machines tried to work around that
      issue, but that results in a massive mess in that timer code.
      
      We have a yet unused argument in the set_affinity callbacks of the irq
      chips, which I added back then for a similar reason. It was never
      required so it got not used. But I'm happy that I never removed it.
      
      That allows us to implement a sane handling of the above scenario. So
      the affected SoC drivers can add the required force handling to their
      interrupt chip, switch the timer code to irq_force_affinity() and
      things just work.
      
      This does not affect any existing user of irq_set_affinity().
      
      Tagged for stable to allow a simple fix of the affected SoC clock
      event drivers.
      Reported-and-tested-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f141082
    • Thomas Gleixner's avatar
      irqchip: Gic: Support forced affinity setting · ddd07396
      Thomas Gleixner authored
      commit ffde1de6 upstream.
      
      To support the affinity setting of per cpu timers in the early startup
      of a not yet online cpu, implement the force logic, which disables the
      cpu online check.
      
      Tagged for stable to allow a simple fix of the affected SoC clock
      event drivers.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Link: http://lkml.kernel.org/r/20140416143315.916984416@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ddd07396
    • Rob Herring's avatar
      of/irq: do irq resolution in platform_get_irq · 274eb7bf
      Rob Herring authored
      commit 9ec36caf upstream.
      
      Currently we get the following kind of errors if we try to use interrupt
      phandles to irqchips that have not yet initialized:
      
      irq: no irq domain found for /ocp/pinmux@48002030 !
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
      (show_stack+0x14/0x1c)
      (dump_stack+0x6c/0xa0)
      (warn_slowpath_common+0x64/0x84)
      (warn_slowpath_null+0x1c/0x24)
      (of_device_alloc+0x144/0x184)
      (of_platform_device_create_pdata+0x44/0x9c)
      (of_platform_bus_create+0xd0/0x170)
      (of_platform_bus_create+0x12c/0x170)
      (of_platform_populate+0x60/0x98)
      
      This is because we're wrongly trying to populate resources that are not
      yet available. It's perfectly valid to create irqchips dynamically, so
      let's fix up the issue by resolving the interrupt resources when
      platform_get_irq is called.
      
      And then we also need to accept the fact that some irqdomains do not
      exist that early on, and only get initialized later on. So we can
      make the current WARN_ON into just into a pr_debug().
      
      We still attempt to populate irq resources when we create the devices.
      This allows current drivers which don't use platform_get_irq to continue
      to function. Once all drivers are fixed, this code can be removed.
      Suggested-by: default avatarRussell King <linux@arm.linux.org.uk>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      274eb7bf
    • Steven Rostedt (Red Hat)'s avatar
      ftrace/module: Hardcode ftrace_module_init() call into load_module() · d9550cf7
      Steven Rostedt (Red Hat) authored
      commit a949ae56 upstream.
      
      A race exists between module loading and enabling of function tracer.
      
      	CPU 1				CPU 2
      	-----				-----
        load_module()
         module->state = MODULE_STATE_COMING
      
      				register_ftrace_function()
      				 mutex_lock(&ftrace_lock);
      				 ftrace_startup()
      				  update_ftrace_function();
      				   ftrace_arch_code_modify_prepare()
      				    set_all_module_text_rw();
      				   <enables-ftrace>
      				    ftrace_arch_code_modify_post_process()
      				     set_all_module_text_ro();
      
      				[ here all module text is set to RO,
      				  including the module that is
      				  loading!! ]
      
         blocking_notifier_call_chain(MODULE_STATE_COMING);
          ftrace_init_module()
      
           [ tries to modify code, but it's RO, and fails!
             ftrace_bug() is called]
      
      When this race happens, ftrace_bug() will produces a nasty warning and
      all of the function tracing features will be disabled until reboot.
      
      The simple solution is to treate module load the same way the core
      kernel is treated at boot. To hardcode the ftrace function modification
      of converting calls to mcount into nops. This is done in init/main.c
      there's no reason it could not be done in load_module(). This gives
      a better control of the changes and doesn't tie the state of the
      module to its notifiers as much. Ftrace is special, it needs to be
      treated as such.
      
      The reason this would work, is that the ftrace_module_init() would be
      called while the module is in MODULE_STATE_UNFORMED, which is ignored
      by the set_all_module_text_ro() call.
      
      Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.comReported-by: default avatarTakao Indoh <indou.takao@jp.fujitsu.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9550cf7
    • Thomas Gleixner's avatar
      rtmutex: Fix deadlock detector for real · bb4d8694
      Thomas Gleixner authored
      commit 397335f0 upstream.
      
      The current deadlock detection logic does not work reliably due to the
      following early exit path:
      
      	/*
      	 * Drop out, when the task has no waiters. Note,
      	 * top_waiter can be NULL, when we are in the deboosting
      	 * mode!
      	 */
      	if (top_waiter && (!task_has_pi_waiters(task) ||
      			   top_waiter != task_top_pi_waiter(task)))
      		goto out_unlock_pi;
      
      So this not only exits when the task has no waiters, it also exits
      unconditionally when the current waiter is not the top priority waiter
      of the task.
      
      So in a nested locking scenario, it might abort the lock chain walk
      and therefor miss a potential deadlock.
      
      Simple fix: Continue the chain walk, when deadlock detection is
      enabled.
      
      We also avoid the whole enqueue, if we detect the deadlock right away
      (A-A). It's an optimization, but also prevents that another waiter who
      comes in after the detection and before the task has undone the damage
      observes the situation and detects the deadlock and returns
      -EDEADLOCK, which is wrong as the other task is not in a deadlock
      situation.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb4d8694
    • Leif Lindholm's avatar
      mips: dts: Fix missing device_type="memory" property in memory nodes · d2790a6a
      Leif Lindholm authored
      commit dfc44f80 upstream.
      
      A few platforms lack a 'device_type = "memory"' for their memory
      nodes, relying on an old ppc quirk in order to discover its memory.
      Add the missing data so that all parsing code can find memory nodes
      correctly.
      Signed-off-by: default avatarLeif Lindholm <leif.lindholm@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: devicetree@vger.kernel.org
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarJohn Crispin <blogic@openwrt.org>
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d2790a6a
    • Aaro Koskinen's avatar
      MIPS/loongson2_cpufreq: Fix CPU clock rate setting · 4236d29b
      Aaro Koskinen authored
      commit 8e8acb32 upstream.
      
      Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
      been unnoticed, as loongson2_cpufreq was the only place where the rate
      was set/get. After commit 652ed95d
      (cpufreq: introduce cpufreq_generic_get() routine) things however broke,
      and now loops_per_jiffy adjustments are incorrect (1000 times too long).
      The patch fixes this by changing cpu_clk rate to Hz.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: cpufreq@vger.kernel.org
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Patchwork: https://patchwork.linux-mips.org/patch/6678/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4236d29b
    • Thomas Gleixner's avatar
      futex: Prevent attaching to kernel threads · 7c3b5654
      Thomas Gleixner authored
      commit f0d71b3d upstream.
      
      We happily allow userspace to declare a random kernel thread to be the
      owner of a user space PI futex.
      
      Found while analysing the fallout of Dave Jones syscall fuzzer.
      
      We also should validate the thread group for private futexes and find
      some fast way to validate whether the "alleged" owner has RW access on
      the file which backs the SHM, but that's a separate issue.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Clark Williams <williams@redhat.com>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Carlos ODonell <carlos@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c3b5654
    • Thomas Gleixner's avatar
      futex: Add another early deadlock detection check · efcd089d
      Thomas Gleixner authored
      commit 866293ee upstream.
      
      Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
      detection code of rtmutex:
        http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com
      
      That underlying issue has been fixed with a patch to the rtmutex code,
      but the futex code must not call into rtmutex in that case because
          - it can detect that issue early
          - it avoids a different and more complex fixup for backing out
      
      If the user space variable got manipulated to 0x80000000 which means
      no lock holder, but the waiters bit set and an active pi_state in the
      kernel is found we can figure out the recursive locking issue by
      looking at the pi_state owner. If that is the current task, then we
      can safely return -EDEADLK.
      
      The check should have been added in commit 59fa6245 (futex: Handle
      futex_pi OWNER_DIED take over correctly) already, but I did not see
      the above issue caused by user space manipulation back then.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Clark Williams <williams@redhat.com>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Carlos ODonell <carlos@redhat.com>
      Cc: Jakub Jelinek <jakub@redhat.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      efcd089d
  2. 31 May, 2014 30 commits