1. 20 Feb, 2014 10 commits
  2. 13 Feb, 2014 1 commit
    • Thomas Gleixner's avatar
      tick: Clear broadcast pending bit when switching to oneshot · dd5fd9b9
      Thomas Gleixner authored
      
      
      AMD systems which use the C1E workaround in the amd_e400_idle routine
      trigger the WARN_ON_ONCE in the broadcast code when onlining a CPU.
      
      The reason is that the idle routine of those AMD systems switches the
      cpu into forced broadcast mode early on before the newly brought up
      CPU can switch over to high resolution / NOHZ mode. The timer related
      CPU1 bringup looks like this:
      
        clockevent_register_device(local_apic);
        tick_setup(local_apic);
        ...
        idle()
      	tick_broadcast_on_off(FORCE);
      	tick_broadcast_oneshot_control(ENTER)
      	  cpumask_set(cpu, broadcast_oneshot_mask);
      	halt();
      
      Now the broadcast interrupt on CPU0 sets CPU1 in the
      broadcast_pending_mask and wakes CPU1. So CPU1 continues:
      
      	local_apic_timer_interrupt()
      	   tick_handle_periodic();
      	   softirq()
      	     tick_init_highres();
      	       cpumask_clr(cpu, broadcast_oneshot_mask);
      	
      	tick_broadcast_oneshot_control(ENTER)
      	   WARN_ON(cpumask_test(cpu, broadcast_pending_mask);
      
      So while we remove CPU1 from the broadcast_oneshot_mask when we switch
      over to highres mode, we do not clear the pending bit, which then
      triggers the warning when we go back to idle.
      
      The reason why this is only visible on C1E affected AMD systems is
      that the other machines enter the deep sleep states via
      acpi_idle/intel_idle and exit the broadcast mode before executing the
      remote triggered local_apic_timer_interrupt. So the pending bit is
      already cleared when the switch over to highres mode is clearing the
      oneshot mask.
      
      The solution is simple: Clear the pending bit together with the mask
      bit when we switch over to highres mode.
      
      Stanislaw came up independently with the same patch by enforcing the
      C1E workaround and debugging the fallout. I picked mine, because mine
      has a changelog :)
      Reported-by: default avatarpoma <pomidorabelisima@gmail.com>
      Debugged-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Olaf Hering <olaf@aepfle.de>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Justin M. Forbes <jforbes@redhat.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1402111434180.21991@ionos.tec.linutronix.de
      
      
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      dd5fd9b9
  3. 11 Feb, 2014 2 commits
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Fix first commit on sub-buffer having non-zero delta · d651aa1d
      Steven Rostedt (Red Hat) authored
      Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on
      that page use a 27 bit delta against that timestamp in order to save on
      bits written to the ring buffer. If the time between events is larger than
      what the 27 bits can hold, a "time extend" event is added to hold the
      entire 64 bit timestamp again and the events after that hold a delta from
      that timestamp.
      
      As a "time extend" is always paired with an event, it is logical to just
      allocate the event with the time extend, to make things a bit more efficient.
      
      Unfortunately, when the pairing code was written, it removed the "delta = 0"
      from the first commit on a page, causing the events on the page to be
      slightly skewed.
      
      Fixes: 69d1b839
      
       "ring-buffer: Bind time extend and data events together"
      Cc: stable@vger.kernel.org # 2.6.37+
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      d651aa1d
    • Paul Gortmaker's avatar
      genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ=n · 2c45aada
      Paul Gortmaker authored
      In allmodconfig builds for sparc and any other arch which does
      not set CONFIG_SPARSE_IRQ, the following will be seen at modpost:
      
        CC [M]  lib/cpu-notifier-error-inject.o
        CC [M]  lib/pm-notifier-error-inject.o
      ERROR: "irq_to_desc" [drivers/gpio/gpio-mcp23s08.ko] undefined!
      make[2]: *** [__modpost] Error 1
      
      This happens because commit 3911ff30
      
       ("genirq: export
      handle_edge_irq() and irq_to_desc()") added one export for it, but
      there were actually two instances of it, in an if/else clause for
      CONFIG_SPARSE_IRQ.  Add the second one.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: stable@vger.kernel.org	# 3.4+
      Link: http://lkml.kernel.org/r/1392057610-11514-1-git-send-email-paul.gortmaker@windriver.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      2c45aada
  4. 09 Feb, 2014 1 commit
  5. 06 Feb, 2014 1 commit
  6. 05 Feb, 2014 2 commits
    • Linus Torvalds's avatar
      execve: use 'struct filename *' for executable name passing · c4ad8f98
      Linus Torvalds authored
      
      
      This changes 'do_execve()' to get the executable name as a 'struct
      filename', and to free it when it is done.  This is what the normal
      users want, and it simplifies and streamlines their error handling.
      
      The controlled lifetime of the executable name also fixes a
      use-after-free problem with the trace_sched_process_exec tracepoint: the
      lifetime of the passed-in string for kernel users was not at all
      obvious, and the user-mode helper code used UMH_WAIT_EXEC to serialize
      the pathname allocation lifetime with the execve() having finished,
      which in turn meant that the trace point that happened after
      mm_release() of the old process VM ended up using already free'd memory.
      
      To solve the kernel string lifetime issue, this simply introduces
      "getname_kernel()" that works like the normal user-space getname()
      function, except with the source coming from kernel memory.
      
      As Oleg points out, this also means that we could drop the tcomm[] array
      from 'struct linux_binprm', since the pathname lifetime now covers
      setup_new_exec().  That would be a separate cleanup.
      Reported-by: default avatarIgor Zhbanov <i.zhbanov@samsung.com>
      Tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c4ad8f98
    • Nitin A Kamble's avatar
      genirq: Generic irq chip requires IRQ_DOMAIN · 923fa4ea
      Nitin A Kamble authored
      
      
      The generic_chip.c uses interfaces from irq_domain.c which is
      controlled by the IRQ_DOMAIN config option, but there is no Kconfig
      dependency so the build can fail:
      
      linux/kernel/irq/generic-chip.c:400:11: error:
      'irq_domain_xlate_onetwocell' undeclared here (not in a function)
      
      Select IRQ_DOMAIN when GENERIC_IRQ_CHIP is selected.
      Signed-off-by: default avatarNitin A Kamble <nitin.a.kamble@intel.com>
      Link: http://lkml.kernel.org/r/1391129410-54548-2-git-send-email-nitin.a.kamble@intel.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org # 3.11+
      923fa4ea
  7. 31 Jan, 2014 2 commits
  8. 28 Jan, 2014 6 commits
  9. 25 Jan, 2014 4 commits
  10. 24 Jan, 2014 10 commits
  11. 23 Jan, 2014 1 commit