1. 02 4月, 2008 10 次提交
    • L
      [ATM] drivers/atm/iphase.c: compilation warning fix · a22eb6fa
      Leonardo Potenza 提交于
      Removed the warning messages:
      drivers/atm/iphase.c:961: warning: 'tcnter' defined but not used
      drivers/atm/iphase.c:963: warning: 'xdump' defined but not used
      
      tcnter and xdump() are used only in debug build
      Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a22eb6fa
    • B
      IPv6: do not create temporary adresses with too short preferred lifetime · eac55bf9
      Benoit Boissinot 提交于
      From RFC341:
      A temporary address is created only if this calculated Preferred
      Lifetime is greater than REGEN_ADVANCE time units.  In particular, an
      implementation must not create a temporary address with a zero
      Preferred Lifetime.
      Signed-off-by: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eac55bf9
    • B
      IPv6: only update the lifetime of the relevant temporary address · c6fbfac2
      Benoit Boissinot 提交于
      When receiving a prefix information from a routeur, only update the
      lifetimes of the temporary address associated with that prefix.
      
      Otherwise if one deprecated prefix is advertized, all your temporary
      addresses will become deprecated.
      Signed-off-by: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6fbfac2
    • D
      bluetooth : __rfcomm_dlc_close lock fix · 1905f6c7
      Dave Young 提交于
      Lockdep warning will be trigged while rfcomm connection closing.
      
      The locks taken in rfcomm_dev_add:
      rfcomm_dev_lock --> d->lock
      
      In __rfcomm_dlc_close:
      d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change)
      
      There's two way to fix it, one is in rfcomm_dev_add we first locking
      d->lock then the rfcomm_dev_lock
      
      The other (in this patch), remove the locking of d->lock for
      rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;"
      is enough.
      
      [  295.002046] =======================================================
      [  295.002046] [ INFO: possible circular locking dependency detected ]
      [  295.002046] 2.6.25-rc7 #1
      [  295.002046] -------------------------------------------------------
      [  295.002046] krfcommd/2705 is trying to acquire lock:
      [  295.002046]  (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] but task is already holding lock:
      [  295.002046]  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] which lock already depends on the new lock.
      [  295.002046] 
      [  295.002046] 
      [  295.002046] the existing dependency chain (in reverse order) is:
      [  295.002046] 
      [  295.002046] -> #1 (&d->lock){--..}:
      [  295.002046]        [<c0149b23>] check_prev_add+0xd3/0x200
      [  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]        [<c03d6b99>] _spin_lock+0x39/0x80
      [  295.002046]        [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm]
      [  295.002046]        [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm]
      [  295.002046]        [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm]
      [  295.002046]        [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm]
      [  295.002046]        [<c0363d38>] sock_ioctl+0x118/0x240
      [  295.002046]        [<c0194196>] vfs_ioctl+0x76/0x90
      [  295.002046]        [<c0194446>] do_vfs_ioctl+0x56/0x140
      [  295.002046]        [<c0194569>] sys_ioctl+0x39/0x60
      [  295.002046]        [<c0104faa>] syscall_call+0x7/0xb
      [  295.002046]        [<ffffffff>] 0xffffffff
      [  295.002046] 
      [  295.002046] -> #0 (rfcomm_dev_lock){-.--}:
      [  295.002046]        [<c0149a84>] check_prev_add+0x34/0x200
      [  295.002046]        [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]        [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]        [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]        [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]        [<c03d6639>] _read_lock+0x39/0x80
      [  295.002046]        [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]        [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
      [  295.002046]        [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
      [  295.002046]        [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
      [  295.002046]        [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
      [  295.002046]        [<c013c18c>] kthread+0x5c/0xa0
      [  295.002046]        [<c0105c07>] kernel_thread_helper+0x7/0x10
      [  295.002046]        [<ffffffff>] 0xffffffff
      [  295.002046] 
      [  295.002046] other info that might help us debug this:
      [  295.002046] 
      [  295.002046] 2 locks held by krfcommd/2705:
      [  295.002046]  #0:  (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm]
      [  295.002046]  #1:  (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm]
      [  295.002046] 
      [  295.002046] stack backtrace:
      [  295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1
      [  295.002046]  [<c0128a38>] ? printk+0x18/0x20
      [  295.002046]  [<c014927f>] print_circular_bug_tail+0x6f/0x80
      [  295.002046]  [<c0149a84>] check_prev_add+0x34/0x200
      [  295.002046]  [<c0149ce5>] check_prevs_add+0x95/0xe0
      [  295.002046]  [<c0149f6f>] validate_chain+0x23f/0x320
      [  295.002046]  [<c014b7b1>] __lock_acquire+0x1c1/0x760
      [  295.002046]  [<c014c349>] lock_acquire+0x79/0xb0
      [  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<c03d6639>] _read_lock+0x39/0x80
      [  295.002046]  [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm]
      [  295.002046]  [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm]
      [  295.002046]  [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm]
      [  295.002046]  [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm]
      [  295.002046]  [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130
      [  295.002046]  [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70
      [  295.002046]  [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm]
      [  295.002046]  [<c03d4559>] ? __sched_text_start+0x229/0x4c0
      [  295.002046]  [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30
      [  295.002046]  [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm]
      [  295.002046]  [<c013c18c>] kthread+0x5c/0xa0
      [  295.002046]  [<c013c130>] ? kthread+0x0/0xa0
      [  295.002046]  [<c0105c07>] kernel_thread_helper+0x7/0x10
      [  295.002046]  =======================
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1905f6c7
    • D
      bluetooth : use lockdep sub-classes for diffrent bluetooth protocol · 68845cb2
      Dave Young 提交于
      'rfcomm connect' will trigger lockdep warnings which is caused by
      locking diffrent kinds of bluetooth sockets at the same time.
      
      So using sub-classes per AF_BLUETOOTH sub-type for lockdep.
      
      Thanks for the hints from dave jones.
      
      ---
      > From: Dave Jones <davej@codemonkey.org.uk>
      > Date: Thu, 27 Mar 2008 12:21:56 -0400
      >
      > > Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1
      > > Mar 27 08:10:57 localhost kernel:  [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11
      > > Mar 27 08:10:57 localhost kernel:  [sched_clock+8/11] ? sched_clock+0x8/0xb
      > > Mar 27 08:10:57 localhost kernel:  [lock_acquire+106/144] lock_acquire+0x6a/0x90
      > > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap]
      > > Mar 27 08:10:57 localhost kernel:  [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6
      > > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap]
      > > Mar 27 08:10:57 localhost kernel:  [security_socket_post_create+22/27] ? security_socket_post_create+0x16/0x1b
      > > Mar 27 08:10:57 localhost kernel:  [__sock_create+388/472] ? __sock_create+0x184/0x1d8
      > > Mar 27 08:10:57 localhost kernel:  [<f8bd9321>] l2cap_sock_bind+0x29/0x108 [l2cap]
      > > Mar 27 08:10:57 localhost kernel:  [kernel_bind+10/13] kernel_bind+0xa/0xd
      > > Mar 27 08:10:57 localhost kernel:  [<f8dad3d7>] rfcomm_dlc_open+0xc8/0x294 [rfcomm]
      > > Mar 27 08:10:57 localhost kernel:  [lock_sock_nested+187/198] ? lock_sock_nested+0xbb/0xc6
      > > Mar 27 08:10:57 localhost kernel:  [<f8dae18c>] rfcomm_sock_connect+0x8b/0xc2 [rfcomm]
      > > Mar 27 08:10:57 localhost kernel:  [sys_connect+96/125] sys_connect+0x60/0x7d
      > > Mar 27 08:10:57 localhost kernel:  [__lock_acquire+1370/3089] ? __lock_acquire+0x55a/0xc11
      > > Mar 27 08:10:57 localhost kernel:  [sys_socketcall+140/392] sys_socketcall+0x8c/0x188
      > > Mar 27 08:10:57 localhost kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
      ---
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68845cb2
    • J
      [ROSE/AX25] af_rose: rose_release() fix · 4965291a
      Jarek Poplawski 提交于
      rose_release() doesn't release sockets properly, e.g. it skips
      sock_orphan(), so OOPSes are triggered in sock_def_write_space(),
      which was observed especially while ROSE skbs were kfreed from
      ax25_frames_acked(). There is also sock_hold() and lock_sock() added -
      similarly to ax25_release(). Thanks to Bernard Pidoux for substantial
      help in debugging this problem.
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Reported-and-tested-by: NBernard Pidoux <bpidoux@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4965291a
    • V
      mac80211: correct use_short_preamble handling · d43c7b37
      Vladimir Koutny 提交于
      ERP IE bit for preamble mode is 0 for short and 1 for long, not the other
      way around. This fixes the value reported to the driver via
      bss_conf->use_short_preamble field.
      Signed-off-by: NVladimir Koutny <vlado@ksp.sk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d43c7b37
    • M
      b43: Fix PCMCIA IRQ routing · e6458901
      Michael Buesch 提交于
      This fixes the IRQ routing on PCMCIA devices.
      With this patch the card will finally be able to receive IRQs.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e6458901
    • M
      b43: Add DMA mapping failure messages · 539e6f8c
      Michael Buesch 提交于
      This adds messages for some DMA mapping failures.
      These are useful for debugging DMA address problems, as they appear
      on x86_64 machines with IOMMU enabled.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      539e6f8c
    • J
      mac80211: trigger ieee80211_sta_work after opening interface · 64f851e4
      Jan Niehusmann 提交于
      ieee80211_sta_work is disabled while network interface
      is down. Therefore, if you configure wireless parameters
      before bringing the interface up, these configurations are
      not yet effective and association fails.
      
      A workaround from userspace is calling a command like
      'iwconfig wlan0 ap any' after the interface is brought up.
      
      To fix this behaviour, trigger execution of ieee80211_sta_work from
      ieee80211_open when in STA or IBSS mode.
      Signed-off-by: NJan Niehusmann <jan@gondor.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64f851e4
  2. 01 4月, 2008 6 次提交
  3. 29 3月, 2008 21 次提交
  4. 28 3月, 2008 3 次提交