1. 06 3月, 2008 10 次提交
    • D
      bluetooth: hci_core: defer hci_unregister_sysfs() · 147e2d59
      Dave Young 提交于
      Alon Bar-Lev reports:
      
       Feb 16 23:41:33 alon1 usb 3-1: configuration #1 chosen from 1 choice
      Feb 16 23:41:33 alon1 BUG: unable to handle kernel NULL pointer  
      dereference at virtual address 00000008
      Feb 16 23:41:33 alon1 printing eip: c01b2db6 *pde = 00000000
      Feb 16 23:41:33 alon1 Oops: 0000 [#1] PREEMPT
      Feb 16 23:41:33 alon1 Modules linked in: ppp_deflate zlib_deflate  
      zlib_inflate bsd_comp ppp_async rfcomm l2cap hci_usb vmnet(P)  
      vmmon(P) tun radeon drm autofs4 ipv6 aes_generic crypto_algapi  
      ieee80211_crypt_ccmp nf_nat_irc nf_nat_ftp nf_conntrack_irc  
      nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT  
      xt_tcpudp ipt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_conntrack  
      iptable_filter ip_tables x_tables snd_pcm_oss snd_mixer_oss  
      snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device  
      bluetooth ppp_generic slhc ioatdma dca cfq_iosched cpufreq_powersave  
      cpufreq_ondemand cpufreq_conservative acpi_cpufreq freq_table uinput  
      fan af_packet nls_cp1255 nls_iso8859_1 nls_utf8 nls_base pcmcia  
      snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm nsc_ircc snd_timer  
      ipw2200 thinkpad_acpi irda snd ehci_hcd yenta_socket uhci_hcd  
      psmouse ieee80211 soundcore intel_agp hwmon rsrc_nonstatic pcspkr  
      e1000 crc_ccitt snd_page_alloc i2c_i801 ieee80211_crypt pcmcia_core  
      agpgart thermal bat!
      tery nvram rtc sr_mod ac sg firmware_class button processor cdrom  
      unix usbcore evdev ext3 jbd ext2 mbcache loop ata_piix libata sd_mod  
      scsi_mod
      Feb 16 23:41:33 alon1
      Feb 16 23:41:33 alon1 Pid: 4, comm: events/0 Tainted: P         
      (2.6.24-gentoo-r2 #1)
      Feb 16 23:41:33 alon1 EIP: 0060:[<c01b2db6>] EFLAGS: 00010282 CPU: 0
      Feb 16 23:41:33 alon1 EIP is at sysfs_get_dentry+0x26/0x80
      Feb 16 23:41:33 alon1 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX:  
      f48a2210
      Feb 16 23:41:33 alon1 ESI: f72eb900 EDI: f4803ae0 EBP: f4803ae0 ESP:  
      f7c49efc
      Feb 16 23:41:33 alon1 hcid[7004]: HCI dev 0 registered
      Feb 16 23:41:33 alon1 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Feb 16 23:41:33 alon1 Process events/0 (pid: 4, ti=f7c48000  
      task=f7c3efc0 task.ti=f7c48000)
      Feb 16 23:41:33 alon1 Stack: f7cb6140 f4822668 f7e71e10 c01b304d  
      ffffffff ffffffff fffffffe c030ba9c
      Feb 16 23:41:33 alon1 f7cb6140 f4822668 f6da6720 f7cb6140 f4822668  
      f6da6720 c030ba8e c01ce20b
      Feb 16 23:41:33 alon1 f6e9dd00 c030ba8e f6da6720 f6e9dd00 f6e9dd00  
      00000000 f4822600 00000000
      Feb 16 23:41:33 alon1 Call Trace:
      Feb 16 23:41:33 alon1 [<c01b304d>] sysfs_move_dir+0x3d/0x1f0
      Feb 16 23:41:33 alon1 [<c01ce20b>] kobject_move+0x9b/0x120
      Feb 16 23:41:33 alon1 [<c0241711>] device_move+0x51/0x110
      Feb 16 23:41:33 alon1 [<f9aaed80>] del_conn+0x0/0x70 [bluetooth]
      Feb 16 23:41:33 alon1 [<f9aaed99>] del_conn+0x19/0x70 [bluetooth]
      Feb 16 23:41:33 alon1 [<c012c1a1>] run_workqueue+0x81/0x140
      Feb 16 23:41:33 alon1 [<c02c0c88>] schedule+0x168/0x2e0
      Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50
      Feb 16 23:41:33 alon1 [<c012c9cb>] worker_thread+0x9b/0xf0
      Feb 16 23:41:33 alon1 [<c012fc70>] autoremove_wake_function+0x0/0x50
      Feb 16 23:41:33 alon1 [<c012c930>] worker_thread+0x0/0xf0
      Feb 16 23:41:33 alon1 [<c012f962>] kthread+0x42/0x70
      Feb 16 23:41:33 alon1 [<c012f920>] kthread+0x0/0x70
      Feb 16 23:41:33 alon1 [<c0104c2f>] kernel_thread_helper+0x7/0x18
      Feb 16 23:41:33 alon1 =======================
      Feb 16 23:41:33 alon1 Code: 26 00 00 00 00 57 89 c7 a1 50 1b 3a c0  
      56 53 8b 70 38 85 f6 74 08 8b 0e 85 c9 74 58 ff 06 8b 56 50 39 fa 74  
      47 89 fb eb 02 89 c3 <8b> 43 08 39 c2 75 f7 8b 46 08 83 c0 68 e8 98  
      e7 10 00 8b 43 10
      Feb 16 23:41:33 alon1 EIP: [<c01b2db6>] sysfs_get_dentry+0x26/0x80  
      SS:ESP 0068:f7c49efc
      Feb 16 23:41:33 alon1 ---[ end trace aae864e9592acc1d ]---
      
      Defer hci_unregister_sysfs because hci device could be destructed
      while hci conn devices still there.
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Tested-by: NStefan Seyfried <seife@suse.de>
      Acked-by: NAlon Bar-Lev <alon.barlev@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      147e2d59
    • S
      bluetooth: CONWISE Technology based adapters with buggy SCO support (bugzilla #9027) · 09a76031
      SDiZ 提交于
      From: SDiZ <sdiz@sdiz.net>
      
      Fix the CONWISE Technology based adapters with buggy SCO support issue
      (bugzilla #9027)
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09a76031
    • J
      [PPPOL2TP]: Fix SMP issues in skb reorder queue handling · e653181d
      James Chapman 提交于
      When walking a session's packet reorder queue, use
      skb_queue_walk_safe() since the list could be modified inside the
      loop.
      
      Rearrange the unlinking skbs from the reorder queue such that it is
      done while the queue lock is held in pppol2tp_recv_dequeue() when
      walking the skb list.
      
      A version of this patch was suggested by Jarek Poplawski.
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e653181d
    • J
      [PPPOL2TP]: Make locking calls softirq-safe · cf3752e2
      James Chapman 提交于
      Fix locking issues in the pppol2tp driver which can cause a kernel
      crash on SMP boxes. There were two problems:-
      
      1. The driver was violating read_lock() and write_lock() scheduling
         rules because it wasn't using softirq-safe locks in softirq
         contexts. So we now consistently use the _bh variants of the lock
         functions.
      
      2. The driver was calling sk_dst_get() in pppol2tp_xmit() which was
         taking sk_dst_lock in softirq context. We now call __sk_dst_get().
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf3752e2
    • H
      atm: replace remaining __FUNCTION__ occurrences · 5a346a10
      Harvey Harrison 提交于
      __FUNCTION__ is gcc-specific, use __func__
      Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a346a10
    • H
    • H
    • H
      dfec7228
    • N
      [SCTP]: Bring MAX_BURST socket option into ietf API extension compliance · 219b99a9
      Neil Horman 提交于
      Brings max_burst socket option set/get into line with the latest ietf
      socket extensions api draft, while maintaining backwards
      compatibility.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      219b99a9
    • G
      SCTP: Fix chunk parameter processing bug · 140ee960
      Gui Jianfeng 提交于
      If an address family is not listed in "Supported Address Types"
      parameter(INIT Chunk), but the packet is sent by that family, this
      address family should be considered as supported by peer.  Otherwise,
      an error condition will occur. For instance, if kernel receives an
      IPV6 SCTP INIT chunk with "Support Address Types" parameter which
      indicates just supporting IPV4 Address family. Kernel will reply an
      IPV6 SCTP INIT ACK packet, but the source ipv6 address in ipv6 header
      will be vacant. This is not correct.
      
      refer to RFC4460 as following:
            IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
            Address Types' parameter either IPv4 or IPv6, but uses the other
            family for sending the packet containing the INIT chunk, or if it
            also lists addresses of the other family in the INIT chunk, then
            the address family that is not listed in the 'Supported Address
            Types' parameter SHOULD also be considered as supported by the
            receiver of the INIT chunk.  The receiver of the INIT chunk SHOULD
            NOT respond with any kind of error indication.
      
      Here is a fix to comply to RFC.
      Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      140ee960
  2. 05 3月, 2008 24 次提交
  3. 04 3月, 2008 6 次提交