1. 25 7月, 2012 1 次提交
  2. 01 6月, 2012 1 次提交
  3. 25 5月, 2012 1 次提交
  4. 24 5月, 2012 1 次提交
    • O
      genirq: reimplement exit_irq_thread() hook via task_work_add() · 4d1d61a6
      Oleg Nesterov 提交于
      exit_irq_thread() and task->irq_thread are needed to handle the unexpected
      (and unlikely) exit of irq-thread.
      
      We can use task_work instead and make this all private to
      kernel/irq/manage.c, cleanup plus micro-optimization.
      
      1. rename exit_irq_thread() to irq_thread_dtor(), make it
         static, and move it up before irq_thread().
      
      2. change irq_thread() to do task_work_add(irq_thread_dtor)
         at the start and task_work_cancel() before return.
      
         tracehook_notify_resume() can never play with kthreads,
         only do_exit()->exit_task_work() can call the callback
         and this is what we want.
      
      3. remove task_struct->irq_thread and the special hook
         in do_exit().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alexander Gordeev <agordeev@redhat.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Smith <dsmith@redhat.com>
      Cc: "Frank Ch. Eigler" <fche@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4d1d61a6
  5. 22 5月, 2012 1 次提交
  6. 19 4月, 2012 2 次提交
    • T
      genirq: Be more informative on irq type mismatch · f5d89470
      Thomas Gleixner 提交于
      We require that shared interrupts agree on a few flag settings. Right
      now we silently return with an error code without giving any hint why
      we reject it.
      
      Make the printout unconditionally and actually useful by printing the
      flags of the new and the already registered action.
      
      Convert all printks to pr_* and use a proper prefix while at it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f5d89470
    • T
      genirq: Reject bogus threaded irq requests · 1c6c6952
      Thomas Gleixner 提交于
      Requesting a threaded interrupt without a primary handler and without
      IRQF_ONESHOT set is dangerous.
      
      The core will use the default primary handler for it, which merily
      wakes the thread. For a level type interrupt this results in an
      interrupt storm, because the interrupt line is reenabled after the
      primary handler runs. The device has still the line asserted, which
      brings us back into the primary handler.
      
      While this works for edge type interrupts, we play it safe and reject
      unconditionally because we can't say for sure which type this
      interrupt really has. The type flags are unreliable as the underlying
      chip implementation can override them. And we cannot assume that
      developers using that interface know what they are doing.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1c6c6952
  7. 29 3月, 2012 2 次提交
  8. 16 3月, 2012 1 次提交
  9. 14 3月, 2012 1 次提交
    • I
      genirq: Flush the irq thread on synchronization · 7140ea19
      Ido Yariv 提交于
      The current implementation does not always flush the threaded handler
      when disabling the irq. In case the irq handler was called, but the
      threaded handler hasn't started running yet, the interrupt will be
      flagged as pending, and the handler will not run. This implementation
      has some issues:
      
      First, if the interrupt is a wake source and flagged as pending, the
      system will not be able to suspend.
      
      Second, when quickly disabling and re-enabling the irq, the threaded
      handler might continue to run after the irq is re-enabled without the
      irq handler being called first. This might be an unexpected behavior.
      
      In addition, it might be counter-intuitive that the threaded handler
      will not be called even though the irq handler was called and returned
      IRQ_WAKE_THREAD.
      
      Fix this by always waiting for the threaded handler to complete in
      synchronize_irq().
      
      [ tglx: Massaged comments, added WARN_ONs and the missing
        	IRQTF_RUNTHREAD check in exit_irq_thread() ]
      Signed-off-by: NIdo Yariv <ido@wizery.com>
      Link: http://lkml.kernel.org/r/1322843052-7166-1-git-send-email-ido@wizery.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      7140ea19
  10. 10 3月, 2012 4 次提交
  11. 07 3月, 2012 1 次提交
  12. 15 2月, 2012 1 次提交
  13. 02 12月, 2011 1 次提交
    • I
      genirq: Fix race condition when stopping the irq thread · 550acb19
      Ido Yariv 提交于
      In irq_wait_for_interrupt(), the should_stop member is verified before
      setting the task's state to TASK_INTERRUPTIBLE and calling schedule().
      In case kthread_stop sets should_stop and wakes up the process after
      should_stop is checked by the irq thread but before the task's state
      is changed, the irq thread might never exit:
      
      kthread_stop                    irq_wait_for_interrupt
      ------------                    ----------------------
      
                                       ...
      ...                              while (!kthread_should_stop()) {
      kthread->should_stop = 1;
      wake_up_process(k);
      wait_for_completion(&kthread->exited);
      ...
                                           set_current_state(TASK_INTERRUPTIBLE);
      
                                           ...
      
                                           schedule();
                                       }
      
      Fix this by checking if the thread should stop after modifying the
      task's state.
      
      [ tglx: Simplified it a bit ]
      Signed-off-by: NIdo Yariv <ido@wizery.com>
      Link: http://lkml.kernel.org/r/1322740508-22640-1-git-send-email-ido@wizery.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@kernel.org
      550acb19
  14. 18 11月, 2011 1 次提交
  15. 30 10月, 2011 1 次提交
  16. 05 10月, 2011 1 次提交
  17. 03 10月, 2011 2 次提交
    • M
      genirq: percpu: allow interrupt type to be set at enable time · 1e7c5fd2
      Marc Zyngier 提交于
      As request_percpu_irq() doesn't allow for a percpu interrupt to have
      its type configured (it is generally impossible to configure it on all
      CPUs at once), add a 'type' argument to enable_percpu_irq().
      
      This allows some low-level, board specific init code to be switched to
      a generic API.
      
      [ tglx: Added WARN_ON argument ]
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1e7c5fd2
    • M
      genirq: Add support for per-cpu dev_id interrupts · 31d9d9b6
      Marc Zyngier 提交于
      The ARM GIC interrupt controller offers per CPU interrupts (PPIs),
      which are usually used to connect local timers to each core. Each CPU
      has its own private interface to the GIC, and only sees the PPIs that
      are directly connect to it.
      
      While these timers are separate devices and have a separate interrupt
      line to a core, they all use the same IRQ number.
      
      For these devices, request_irq() is not the right API as it assumes
      that an IRQ number is visible by a number of CPUs (through the
      affinity setting), but makes it very awkward to express that an IRQ
      number can be handled by all CPUs, and yet be a different interrupt
      line on each CPU, requiring a different dev_id cookie to be passed
      back to the handler.
      
      The *_percpu_irq() functions is designed to overcome these
      limitations, by providing a per-cpu dev_id vector:
      
      int request_percpu_irq(unsigned int irq, irq_handler_t handler,
      		   const char *devname, void __percpu *percpu_dev_id);
      void free_percpu_irq(unsigned int, void __percpu *);
      int setup_percpu_irq(unsigned int irq, struct irqaction *new);
      void remove_percpu_irq(unsigned int irq, struct irqaction *act);
      void enable_percpu_irq(unsigned int irq);
      void disable_percpu_irq(unsigned int irq);
      
      The API has a number of limitations:
      - no interrupt sharing
      - no threading
      - common handler across all the CPUs
      
      Once the interrupt is requested using setup_percpu_irq() or
      request_percpu_irq(), it must be enabled by each core that wishes its
      local interrupt to be delivered.
      
      Based on an initial patch by Thomas Gleixner.
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1316793788-14500-2-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      31d9d9b6
  18. 12 9月, 2011 1 次提交
  19. 24 8月, 2011 1 次提交
    • L
      Revert "irq: Always set IRQF_ONESHOT if no primary handler is specified" · 69dd3d8e
      Linus Torvalds 提交于
      This reverts commit f3637a5f.
      
      It turns out that this breaks several drivers, one example being OMAP
      boards which use the on-board OMAP UARTs and the omap-serial driver that
      will not boot to userspace after the commit.
      
      Paul Walmsley reports that enabling CONFIG_DEBUG_SHIRQ reveals 'IRQ
      handler type mismatch' errors:
      
        IRQ handler type mismatch for IRQ 74
        current handler: serial idle
        ...
      
      and the reason is that setting IRQF_ONESHOT will now result in those
      interrupt handlers having different IRQF flags, and thus being
      unsharable.  So the commit log in the reverted commit:
      
                                  "Since it is required for those users and
          there is no difference for others it makes sense to add this flag
          unconditionally."
      
      is simply not true: there may not be any difference from a "actions at
      irq time", but there is a *big* difference wrt this flag testing irq
      management (see __setup_irq() in kernel/irq/manage.c).
      
      One solution may be to stop verifying IRQF_ONESHOT in __setup_irq(), but
      right now the safe course of action is to revert the change.  Let's
      revisit this in a later merge window.
      Reported-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Requested-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69dd3d8e
  20. 28 7月, 2011 2 次提交
  21. 10 6月, 2011 1 次提交
  22. 03 6月, 2011 1 次提交
  23. 23 4月, 2011 1 次提交
  24. 03 4月, 2011 1 次提交
  25. 29 3月, 2011 4 次提交
  26. 28 3月, 2011 1 次提交
  27. 27 3月, 2011 1 次提交
    • D
      genirq: Split irq_set_affinity() so it can be called with lock held. · c2d0c555
      David Daney 提交于
      The .irq_cpu_online() and .irq_cpu_offline() functions may need to
      adjust affinity, but they are called with the descriptor lock held.
      Create __irq_set_affinity_locked() which is called with the lock held.
      Make irq_set_affinity() just a wrapper that acquires the lock.
      
      [ tglx: Changed the argument to irq_data, added a !desc check and
              moved the !irq_set_affinity check where it belongs ]
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Cc: ralf@linux-mips.org
      LKML-Reference: <1301081931-11240-4-git-send-email-ddaney@caviumnetworks.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      c2d0c555
  28. 17 3月, 2011 1 次提交
  29. 26 2月, 2011 2 次提交
    • T
      genirq: Provide forced interrupt threading · 8d32a307
      Thomas Gleixner 提交于
      Add a commandline parameter "threadirqs" which forces all interrupts except
      those marked IRQF_NO_THREAD to run threaded. That's mostly a debug option to
      allow retrieving better debug data from crashing interrupt handlers. If
      "threadirqs" is not enabled on the kernel command line, then there is no
      impact in the interrupt hotpath.
      
      Architecture code needs to select CONFIG_IRQ_FORCED_THREADING after
      marking the interrupts which cant be threaded IRQF_NO_THREAD. All
      interrupts which have IRQF_TIMER set are implict marked
      IRQF_NO_THREAD. Also all PER_CPU interrupts are excluded.
      
      Forced threading hard interrupts also forces all soft interrupt
      handling into thread context.
      
      When enabled it might slow down things a bit, but for debugging problems in
      interrupt code it's a reasonable penalty as it does not immediately
      crash and burn the machine when an interrupt handler is buggy.
      
      Some test results on a Core2Duo machine:
      
      Cache cold run of:
       # time git grep irq_desc
      
            non-threaded       threaded
       real 1m18.741s          1m19.061s
       user 0m1.874s           0m1.757s
       sys  0m5.843s           0m5.427s
      
       # iperf -c server
      non-threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   933 Mbits/sec
      threaded
      [  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   934 Mbits/sec
      [  3]  0.0-10.0 sec  1.09 GBytes   937 Mbits/sec
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.772668648@linutronix.de>
      8d32a307
    • T
      genirq: Allow shared oneshot interrupts · 9d591edd
      Thomas Gleixner 提交于
      Support ONESHOT on shared interrupts, if all drivers agree on it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <20110223234956.483640430@linutronix.de>
      9d591edd