1. 21 2月, 2008 8 次提交
  2. 20 2月, 2008 2 次提交
    • D
      veth: fix dev refcount race · c15853f2
      Daniel Lezcano 提交于
      When deleting the veth driver, veth_close calls netif_carrier_off
      for the two extremities of the network device. netif_carrier_off on
      the peer device will fire an event and hold a reference on the peer
      device. Just after, the peer is unregistered taking the rtnl_lock while
      the linkwatch_event is scheduled. If __linkwatch_run_queue does not
      occurs before the unregistering, unregister_netdevice will wait for
      the dev refcount to reach zero holding the rtnl_lock and linkwatch_event
      will wait for the rtnl_lock and hold the dev refcount.
      Signed-off-by: NDaniel Lezcano <dlezcano@fr.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15853f2
    • M
      [NIU]: More BMAC alt MAC address fixes. · fa907895
      Matheos Worku 提交于
      From: Matheos Worku <Matheos.Worku@Sun.COM>
      
      1) niu_enable_alt_mac() needs to be adjusted so that the mask
         is computed properly for the BMAC case.
      
      2) BMAC has 6 alt MAC addresses available, not 7.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa907895
  3. 19 2月, 2008 2 次提交
  4. 16 2月, 2008 17 次提交
  5. 15 2月, 2008 8 次提交
  6. 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
  7. 12 2月, 2008 2 次提交
    • L
      WMI: initialize wmi_blocks.list even if ACPI is disabled · 96b5a46e
      Linus Torvalds 提交于
      Even if we don't want to register the WMI driver, we should initialize
      the wmi_blocks list to be empty, since we don't want the wmi helper
      functions to oops just because that basic list has not even been set up.
      
      With this, "find_guid()" will happily return "not found" rather than
      oopsing all over the place, and the callers will then just automatically
      return false or AE_NOT_FOUND as appropriate.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96b5a46e
    • O
      mlx4_core: Fix build break (missing include) · 29c27112
      Olof Johansson 提交于
      Commit 313abe55 ("mlx4_core: For 64-bit systems, vmap() kernel queue
      buffers") caused this to pop up on powerpc allyesconfig, looks like a
      missing include file:
      
          drivers/net/mlx4/alloc.c: In function 'mlx4_buf_alloc':
          drivers/net/mlx4/alloc.c:162: error: implicit declaration of function 'vmap'
          drivers/net/mlx4/alloc.c:162: error: 'VM_MAP' undeclared (first use in this function)
          drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported only once
          drivers/net/mlx4/alloc.c:162: error: for each function it appears in.)
          drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer without a cast
          drivers/net/mlx4/alloc.c: In function 'mlx4_buf_free':
          drivers/net/mlx4/alloc.c:187: error: implicit declaration of function 'vunmap'
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      29c27112