1. 06 12月, 2008 1 次提交
  2. 05 12月, 2008 12 次提交
  3. 04 12月, 2008 11 次提交
  4. 03 12月, 2008 2 次提交
    • W
      xfrm: Cleanup for unlink SPD entry · 29fa0b30
      Wei Yongjun 提交于
      Used __xfrm_policy_unlink() to instead of the dup codes when unlink
      SPD entry.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29fa0b30
    • W
      xfrm: Fix kernel panic when flush and dump SPD entries · d5654efd
      Wei Yongjun 提交于
      After flush the SPD entries, dump the SPD entries will cause kernel painc.
      
      Used the following commands to reproduct:
      
      - echo 'spdflush;' | setkey -c
      - echo 'spdadd 3ffe:501:ffff:ff01::/64 3ffe:501:ffff:ff04::/64  any -P out ipsec \
        ah/tunnel/3ffe:501:ffff:ff00:200:ff:fe00:b0b0-3ffe:501:ffff:ff02:200:ff:fe00:a1a1/require;\
        spddump;' | setkey -c
      - echo 'spdflush; spddump;' | setkey -c
      - echo 'spdadd 3ffe:501:ffff:ff01::/64 3ffe:501:ffff:ff04::/64  any -P out ipsec \
        ah/tunnel/3ffe:501:ffff:ff00:200:ff:fe00:b0b0-3ffe:501:ffff:ff02:200:ff:fe00:a1a1/require;\
        spddump;' | setkey -c
      
      This is because when flush the SPD entries, the SPD entry is not remove
      from the list.
      
      This patch fix the problem by remove the SPD entry from the list.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5654efd
  5. 02 12月, 2008 7 次提交
  6. 30 11月, 2008 6 次提交
    • M
      Bluetooth: Fix RFCOMM release oops when device is still in use · 9a5df923
      Marcel Holtmann 提交于
      It turns out that the following sequence of actions will reproduce the
      oops:
      
        1. Create a new RFCOMM device (using RFCOMMCREATEDEV ioctl)
        2. (Try to) open the device
        3. Release the RFCOMM device (using RFCOMMRELEASEDEV ioctl)
      
      At this point, the "/dev/rfcomm*" device is still in use, but it is gone
      from the internal list, so the device id can be reused.
      
        4. Create a new RFCOMM device with the same device id as before
      
      And now kobject will complain that the TTY already exists.
      
      (See http://lkml.org/lkml/2008/7/13/89 for a reproducible test-case.)
      
      This patch attempts to correct this by only removing the device from the
      internal list of devices at the final unregister stage, so that the id
      won't get reused until the device has been completely destructed.
      
      This should be safe as the RFCOMM_TTY_RELEASED bit will be set for the
      device and prevent the device from being reopened after it has been
      released.
      
      Based on a report from Vegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9a5df923
    • M
      Bluetooth: Fix format arguments warning · 2e792995
      Marcel Holtmann 提交于
      Newer GCC versions are a little bit picky about how to deal with format
      arguments:
      
      net/bluetooth/hci_sysfs.c: In function ‘hci_register_sysfs’:
      net/bluetooth/hci_sysfs.c:418: warning: format not a string literal and no format arguments
      
      It is simple enough to fix and makes the compiler happy.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2e792995
    • M
      Bluetooth: Enable per-module dynamic debug messages · a418b893
      Marcel Holtmann 提交于
      With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to
      allow debugging without having to recompile the kernel. This patch turns
      all BT_DBG() calls into pr_debug() to support dynamic debug messages.
      
      As a side effect all CONFIG_BT_*_DEBUG statements are now removed and
      some broken debug entries have been fixed.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a418b893
    • M
      Bluetooth: Send HCI Reset command by default on device initialization · 7a9d4020
      Marcel Holtmann 提交于
      The Bluetooth subsystem was not using the HCI Reset command when doing
      device initialization. The Bluetooth 1.0b specification was ambiguous
      on how the device firmware was suppose to handle it. Almost every device
      was triggering a transport reset at the same time. In case of USB this
      ended up in disconnects from the bus.
      
      All modern Bluetooth dongles handle this perfectly fine and a lot of
      them actually require that HCI Reset is sent. If not then they are
      either stuck in their HID Proxy mode or their internal structures for
      inquiry and paging are not correctly setup.
      
      To handle old and new devices smoothly the Bluetooth subsystem contains
      a quirk to force the HCI Reset on initialization. However maintaining
      such a quirk becomes more and more complicated. This patch turns the
      logic around and lets the old devices disable the HCI Reset command.
      
      The only device where the HCI_QUIRK_NO_RESET is still needed are the
      original Digianswer devices and dongles with an early CSR firmware.
      
      CSR reported that they fixed this for version 12 firmware. The last
      official release of version 11 firmware is build ID 115. The first
      version 12 candidate was build ID 117.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      7a9d4020
    • M
      Bluetooth: Fix warnings for bt_key_strings and bt_slock_key_strings · db7aa1c2
      Marcel Holtmann 提交于
      After adding proper lockdep annotations for Bluetooth protocols the case
      when lockdep is disabled produced two compiler warnings:
      
      net/bluetooth/af_bluetooth.c:60: warning: ‘bt_key_strings’ defined but not used
      net/bluetooth/af_bluetooth.c:71: warning: ‘bt_slock_key_strings’ defined but not used
      
      Fix both of them by adding a CONFIG_DEBUG_LOCK_ALLOC conditional around
      them and re-arranging the code a little bit.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      db7aa1c2
    • V
      Bluetooth: Fix leak of uninitialized data to userspace · c6bf514c
      Vegard Nossum 提交于
          struct hci_dev_list_req {
                  __u16  dev_num;
                  struct hci_dev_req dev_req[0];  /* hci_dev_req structures */
          };
      
      sizeof(struct hci_dev_list_req) == 4, so the two bytes immediately
      following "dev_num" will never be initialized. When this structure
      is copied to userspace, these uninitialized bytes are leaked.
      
      Fix by using kzalloc() instead of kmalloc(). Found using kmemcheck.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c6bf514c
  7. 28 11月, 2008 1 次提交