1. 09 4月, 2008 6 次提交
  2. 05 4月, 2008 3 次提交
  3. 04 4月, 2008 14 次提交
  4. 03 4月, 2008 7 次提交
  5. 02 4月, 2008 10 次提交
    • P
      [VLAN]: Proc entry is not renamed when vlan device name changes. · 802fb176
      Pavel Emelyanov 提交于
      This may lead to situations, when each of two proc entries produce
      data for the other's device.
      
      Looks like a BUG, so this patch is for net-2.6. It will not apply to
      net-2.6.26 since dev->nd_net access is replaced with dev_net(dev)
      one.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      802fb176
    • H
      [IPV6]: Fix ICMP relookup error path dst leak · f32c5f2c
      Herbert Xu 提交于
      When we encounter an error while looking up the dst the second
      time we need to drop the first dst.  This patch is pretty much
      the same as the one for IPv4.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f32c5f2c
    • 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
    • Y
      f0bdb7ba
    • 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
    • L
      mac80211: use a struct for bss->mesh_config · 6c4711b4
      Luis Carlos Cobo 提交于
      This allows cleaner code when accesing bss->mesh_config components.
      Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6c4711b4
    • L