1. 20 10月, 2009 2 次提交
    • D
      bluetooth: static lock key fix · 45054dc1
      Dave Young 提交于
      When shutdown ppp connection, lockdep waring about non-static key
      will happen, it is caused by the lock is not initialized properly
      at that time.
      
      Fix with tuning the lock/skb_queue_head init order
      
      [   94.339261] INFO: trying to register non-static key.
      [   94.342509] the code is fine but needs lockdep annotation.
      [   94.342509] turning off the locking correctness validator.
      [   94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
      [   94.342509] Call Trace:
      [   94.342509]  [<c0248fbe>] register_lock_class+0x58/0x241
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c024ab34>] __lock_acquire+0xac/0xb73
      [   94.342509]  [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
      [   94.342509]  [<c024b662>] lock_acquire+0x67/0x84
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
      [   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
      [   94.342509]  [<c04cd1eb>] skb_dequeue+0x15/0x41
      [   94.342509]  [<c054a648>] ? _read_unlock+0x1d/0x20
      [   94.342509]  [<c04cd641>] skb_queue_purge+0x14/0x1b
      [   94.342509]  [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
      [   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
      [   94.342509]  [<c0249c04>] ? mark_lock+0x1e/0x1c7
      [   94.342509]  [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
      [   94.342509]  [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
      [   94.342509]  [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
      [   94.342509]  [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
      [   94.342509]  [<c02302c4>] tasklet_action+0x69/0xc1
      [   94.342509]  [<c022fbef>] __do_softirq+0x94/0x11e
      [   94.342509]  [<c022fcaf>] do_softirq+0x36/0x5a
      [   94.342509]  [<c022fe14>] irq_exit+0x35/0x68
      [   94.342509]  [<c0204ced>] do_IRQ+0x72/0x89
      [   94.342509]  [<c02038ee>] common_interrupt+0x2e/0x34
      [   94.342509]  [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
      [   94.342509]  [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
      [   94.342509]  [<c049d238>] cpuidle_idle_call+0x5c/0x94
      [   94.342509]  [<c02023f8>] cpu_idle+0x4e/0x6f
      [   94.342509]  [<c0534153>] rest_init+0x53/0x55
      [   94.342509]  [<c0781894>] start_kernel+0x2f0/0x2f5
      [   94.342509]  [<c0781091>] i386_start_kernel+0x91/0x96
      Reported-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Tested-by: NOliver Hartkopp <oliver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45054dc1
    • D
      bluetooth: scheduling while atomic bug fix · f74c77cb
      Dave Young 提交于
      Due to driver core changes dev_set_drvdata will call kzalloc which should be
      in might_sleep context, but hci_conn_add will be called in atomic context
      
      Like dev_set_name move dev_set_drvdata to work queue function.
      
      oops as following:
      
      Oct  2 17:41:59 darkstar kernel: [  438.001341] BUG: sleeping function called from invalid context at mm/slqb.c:1546
      Oct  2 17:41:59 darkstar kernel: [  438.001345] in_atomic(): 1, irqs_disabled(): 0, pid: 2133, name: sdptool
      Oct  2 17:41:59 darkstar kernel: [  438.001348] 2 locks held by sdptool/2133:
      Oct  2 17:41:59 darkstar kernel: [  438.001350]  #0:  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.+.}, at: [<faa1d2f5>] lock_sock+0xa/0xc [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001360]  #1:  (&hdev->lock){+.-.+.}, at: [<faa20e16>] l2cap_sock_connect+0x103/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001371] Pid: 2133, comm: sdptool Not tainted 2.6.31-mm1 #2
      Oct  2 17:41:59 darkstar kernel: [  438.001373] Call Trace:
      Oct  2 17:41:59 darkstar kernel: [  438.001381]  [<c022433f>] __might_sleep+0xde/0xe5
      Oct  2 17:41:59 darkstar kernel: [  438.001386]  [<c0298843>] __kmalloc+0x4a/0x15a
      Oct  2 17:41:59 darkstar kernel: [  438.001392]  [<c03f0065>] ? kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001396]  [<c03f0065>] kzalloc+0xb/0xd
      Oct  2 17:41:59 darkstar kernel: [  438.001400]  [<c03f04ff>] device_private_init+0x15/0x3d
      Oct  2 17:41:59 darkstar kernel: [  438.001405]  [<c03f24c5>] dev_set_drvdata+0x18/0x26
      Oct  2 17:41:59 darkstar kernel: [  438.001414]  [<fa51fff7>] hci_conn_init_sysfs+0x40/0xd9 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001422]  [<fa51cdc0>] ? hci_conn_add+0x128/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001429]  [<fa51ce0f>] hci_conn_add+0x177/0x186 [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001437]  [<fa51cf8a>] hci_connect+0x3c/0xfb [bluetooth]
      Oct  2 17:41:59 darkstar kernel: [  438.001442]  [<faa20e87>] l2cap_sock_connect+0x174/0x26b [l2cap]
      Oct  2 17:41:59 darkstar kernel: [  438.001448]  [<c04c8df5>] sys_connect+0x60/0x7a
      Oct  2 17:41:59 darkstar kernel: [  438.001453]  [<c024b703>] ? lock_release_non_nested+0x84/0x1de
      Oct  2 17:41:59 darkstar kernel: [  438.001458]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001462]  [<c028804b>] ? might_fault+0x47/0x81
      Oct  2 17:41:59 darkstar kernel: [  438.001468]  [<c033361f>] ? __copy_from_user_ll+0x11/0xce
      Oct  2 17:41:59 darkstar kernel: [  438.001472]  [<c04c9419>] sys_socketcall+0x82/0x17b
      Oct  2 17:41:59 darkstar kernel: [  438.001477]  [<c020329d>] syscall_call+0x7/0xb
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f74c77cb
  2. 01 10月, 2009 1 次提交
  3. 17 9月, 2009 1 次提交
  4. 16 9月, 2009 1 次提交
  5. 12 9月, 2009 1 次提交
    • M
      net: Add DEVTYPE support for Ethernet based devices · 384912ed
      Marcel Holtmann 提交于
      The Ethernet framing is used for a lot of devices these days. Most
      prominent are WiFi and WiMAX based devices. However for userspace
      application it is important to classify these devices correctly and
      not only see them as Ethernet devices. The daemons like HAL, DeviceKit
      or even NetworkManager with udev support tries to do the classification
      in userspace with a lot trickery and extra system calls. This is not
      good and actually reaches its limitations. Especially since the kernel
      does know the type of the Ethernet device it is pretty stupid.
      
      To solve this problem the underlying device type needs to be set and
      then the value will be exported as DEVTYPE via uevents and available
      within udev.
      
        # cat /sys/class/net/wlan0/uevent
        DEVTYPE=wlan
        INTERFACE=wlan0
        IFINDEX=5
      
      This is similar to subsystems like USB and SCSI that distinguish
      between hosts, devices, disks, partitions etc.
      
      The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
      device type. All device types are free form, but for convenience the
      same strings as used with RFKILL are choosen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      384912ed
  6. 01 9月, 2009 1 次提交
  7. 26 8月, 2009 3 次提交
  8. 25 8月, 2009 1 次提交
  9. 24 8月, 2009 2 次提交
  10. 23 8月, 2009 21 次提交
  11. 06 8月, 2009 1 次提交
  12. 04 8月, 2009 1 次提交
  13. 06 7月, 2009 1 次提交
  14. 18 6月, 2009 1 次提交
  15. 14 6月, 2009 1 次提交
  16. 08 6月, 2009 1 次提交