1. 08 Apr, 2008 1 commit
  2. 05 Apr, 2008 3 commits
  3. 03 Apr, 2008 14 commits
  4. 02 Apr, 2008 15 commits
    • YOSHIFUJI Hideaki's avatar
    • YOSHIFUJI Hideaki's avatar
      [IPV6]: Unify ip6_onlink() and ipip6_onlink(). · 52eeeb84
      YOSHIFUJI Hideaki authored
      Both are identical, let's create ipv6_chk_prefix() and use it
      in both places.
      52eeeb84
    • YOSHIFUJI Hideaki's avatar
    • YOSHIFUJI Hideaki's avatar
    • YOSHIFUJI Hideaki's avatar
    • YOSHIFUJI Hideaki's avatar
      [IPV6] SIT: Fix locking issues in PRL management. · 3fcfa129
      YOSHIFUJI Hideaki authored
      
      
      To protect PRL list, use ipip6_lock.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      3fcfa129
    • Templin, Fred L's avatar
      [IPV6] SIT: Add PRL management for ISATAP. · fadf6bf0
      Templin, Fred L authored
      
      
      This patch updates the Linux the Intra-Site Automatic Tunnel Addressing
      Protocol (ISATAP) implementation. It places the ISATAP potential router
      list (PRL) in the kernel and adds three new private ioctls for PRL
      management.
      
      [Add several changes of structure name, constant names etc. - yoshfuji]
      Signed-off-by: default avatarFred L. Templin <fred.l.templin@boeing.com>
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      fadf6bf0
    • Pavel Emelyanov's avatar
      [VLAN]: Proc entry is not renamed when vlan device name changes. · 802fb176
      Pavel Emelyanov authored
      
      
      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: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      802fb176
    • Herbert Xu's avatar
      [IPV6]: Fix ICMP relookup error path dst leak · f32c5f2c
      Herbert Xu authored
      
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f32c5f2c
    • Benoit Boissinot's avatar
      IPv6: do not create temporary adresses with too short preferred lifetime · eac55bf9
      Benoit Boissinot authored
      
      
      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: default avatarBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eac55bf9
    • Benoit Boissinot's avatar
      IPv6: only update the lifetime of the relevant temporary address · c6fbfac2
      Benoit Boissinot authored
      
      
      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: default avatarBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6fbfac2
    • Dave Young's avatar
      bluetooth : __rfcomm_dlc_close lock fix · 1905f6c7
      Dave Young authored
      
      
      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: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1905f6c7
    • Dave Young's avatar
      bluetooth : use lockdep sub-classes for diffrent bluetooth protocol · 68845cb2
      Dave Young authored
      
      
      '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: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68845cb2
    • YOSHIFUJI Hideaki's avatar
      f0bdb7ba
    • Jarek Poplawski's avatar
      [ROSE/AX25] af_rose: rose_release() fix · 4965291a
      Jarek Poplawski authored
      
      
      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: default avatarJarek Poplawski <jarkao2@gmail.com>
      Reported-and-tested-by: default avatarBernard Pidoux <bpidoux@free.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4965291a
  5. 01 Apr, 2008 7 commits