1. 10 2月, 2016 1 次提交
  2. 10 12月, 2015 1 次提交
    • J
      ipmi: move timer init to before irq is setup · 27f972d3
      Jan Stancek 提交于
      We encountered a panic on boot in ipmi_si on a dell per320 due to an
      uninitialized timer as follows.
      
      static int smi_start_processing(void       *send_info,
                                      ipmi_smi_t intf)
      {
              /* Try to claim any interrupts. */
              if (new_smi->irq_setup)
                      new_smi->irq_setup(new_smi);
      
       --> IRQ arrives here and irq handler tries to modify uninitialized timer
      
          which triggers BUG_ON(!timer->function) in __mod_timer().
      
       Call Trace:
         <IRQ>
         [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
         [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
         [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
         [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
         [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
         [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
         [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
         [<ffffffff8100fc59>] handle_irq+0x49/0xa0
         [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
         [<ffffffff8100ba53>] ret_from_intr+0x0/0x11
      
              /* Set up the timer that drives the interface. */
              setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);
      
      The following patch fixes the problem.
      
      To: Openipmi-developer@lists.sourceforge.net
      To: Corey Minyard <minyard@acm.org>
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NTony Camuso <tcamuso@redhat.com>
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before
      27f972d3
  3. 16 11月, 2015 4 次提交
  4. 09 11月, 2015 6 次提交
  5. 28 10月, 2015 1 次提交
  6. 25 10月, 2015 1 次提交
  7. 20 10月, 2015 4 次提交
  8. 19 10月, 2015 11 次提交
  9. 18 10月, 2015 1 次提交
    • P
      tty: Remove ASYNC_CLOSING checks in open()/hangup() methods · fef062cb
      Peter Hurley 提交于
      Since at least before 2.6.30, tty drivers that do not drop the tty lock
      while closing cannot observe ASYNC_CLOSING set while holding the
      tty lock; this includes the tty driver's open() and hangup() methods,
      since the tty core calls these methods holding the tty lock.
      
      For these drivers, waiting for ASYNC_CLOSING to clear while opening
      is not required, since this condition cannot occur. Similarly, even
      when the open() method drops and reacquires the tty lock after
      blocking, ASYNC_CLOSING cannot be set (again, for drivers that
      do not drop the tty lock while closing).
      
      Now that tty port drivers no longer drop the tty lock while closing
      (since 'tty: Remove tty_wait_until_sent_from_close()'), the same
      conditions apply: waiting for ASYNC_CLOSING to clear while opening
      is not required, nor is re-checking ASYNC_CLOSING after dropping and
      reacquiring the tty lock while blocking (eg., in *_block_til_ready()).
      
      Note: The ASYNC_CLOSING flag state is still maintained since several
      bitrotting drivers use it for (dubious) other purposes.
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fef062cb
  10. 15 10月, 2015 1 次提交
  11. 14 10月, 2015 1 次提交
  12. 08 10月, 2015 2 次提交
  13. 02 10月, 2015 1 次提交
  14. 21 9月, 2015 5 次提交