1. 23 8月, 2008 2 次提交
  2. 21 7月, 2008 1 次提交
    • A
      tty: Ldisc revamp · a352def2
      Alan Cox 提交于
      Move the line disciplines towards a conventional ->ops arrangement.  For
      the moment the actual 'tty_ldisc' struct in the tty is kept as part of
      the tty struct but this can then be changed if it turns out that when it
      all settles down we want to refcount ldiscs separately to the tty.
      
      Pull the ldisc code out of /proc and put it with our ldisc code.
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a352def2
  3. 15 7月, 2008 1 次提交
  4. 10 7月, 2008 1 次提交
  5. 03 7月, 2008 1 次提交
  6. 21 6月, 2008 1 次提交
  7. 11 6月, 2008 1 次提交
  8. 03 5月, 2008 1 次提交
  9. 30 4月, 2008 2 次提交
  10. 20 4月, 2008 2 次提交
  11. 08 3月, 2008 1 次提交
  12. 06 3月, 2008 1 次提交
  13. 13 2月, 2008 1 次提交
    • D
      hci_ldisc: fix null pointer deref · 3611f4d2
      David Newall 提交于
      Arjan:
      
        With the help of kerneloops.org I've spotted a nice little interaction
        between the TTY layer and the bluetooth code, however the tty layer is not
        something I'm all too familiar with so I rather ask than brute-force fix the
        code incorrectly.
      
        The raw details are at:
        http://www.kerneloops.org/search.php?search=uart_flush_buffer
      
        What happens is that, on closing the bluetooth tty, the tty layer goes
        into the release_dev() function, which first does a bunch of stuff, then
        sets the file->private_data to NULL, does some more stuff and then calls the
        ldisc close function.  Which in this case, is hci_uart_tty_close().
      
        Now, hci_uart_tty_close() calls hci_uart_close() which clears some
        internal bit, and then calls hci_uart_flush()...  which calls back to the
        tty layers' uart_flush_buffer() function.  (in drivers/bluetooth/hci_tty.c
        around line 194) Which then WARN_ON()'s because that's not allowed/supposed
        to be called this late in the shutdown of the port....
      
        Should the bluetooth driver even call this flush function at all??
      
      David:
      
        This seems to be what happens: Hci_uart_close() flushes using
        hci_uart_flush().  Subsequently, in hci_dev_do_close(), (one step in
        hci_unregister_dev()), hci_uart_flush() is called again.  The comment in
        uart_flush_buffer(), relating to the WARN_ON(), indicates you can't flush
        after the port is closed; which sounds reasonable.  I think hci_uart_close()
        should set hdev->flush to NULL before returning.  Hci_dev_do_close() does
        check for this.  The code path is rather involved and I'm not entirely clear
        of all steps, but I think that's what should be done.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3611f4d2
  14. 06 2月, 2008 1 次提交
  15. 05 2月, 2008 3 次提交
  16. 03 2月, 2008 1 次提交
  17. 11 1月, 2008 1 次提交
  18. 22 10月, 2007 6 次提交
  19. 09 9月, 2007 1 次提交
  20. 11 7月, 2007 2 次提交
  21. 24 5月, 2007 1 次提交
  22. 11 5月, 2007 3 次提交
  23. 05 5月, 2007 2 次提交
  24. 26 4月, 2007 2 次提交
  25. 27 2月, 2007 1 次提交