1. 03 Apr, 2008 6 commits
  2. 02 Apr, 2008 13 commits
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · e1ec1b8c
      David S. Miller authored
      Conflicts:
      
      	drivers/net/s2io.c
      e1ec1b8c
    • Denis V. Lunev's avatar
    • Denis V. Lunev's avatar
      [NETNS]: Remove ifdef CONFIG_NET braces in fs/proc/proc_net.c. · 856f6ff7
      Denis V. Lunev authored
      
      
      They are redundant as this file is linked in iff CONFIG_NET is turned
      on.
      Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      856f6ff7
    • Denis V. Lunev's avatar
    • 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
    • Leonardo Potenza's avatar
      [ATM] drivers/atm/iphase.c: compilation warning fix · a22eb6fa
      Leonardo Potenza authored
      
      
      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: default avatarLeonardo Potenza <lpotenza@inwind.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a22eb6fa
    • 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
  3. 01 Apr, 2008 21 commits